So schützen Sie private Kubernetes-Dienste hinter einem GitHub-Login mit oauth2_proxy

Einführung

Kubernetesingresses machen es einfach, Webdienste dem Internet zugänglich zu machen. Wenn es jedoch um private Dienste geht, möchten Sie wahrscheinlich einschränken, wer Zugriff darauf hat. oauth2_proxy können als Barriere zwischen dem öffentlichen Internet und privaten Diensten dienen. oauth2_proxy ist ein Reverseproxy und Server, der die Authentifizierung mit verschiedenen Anbietern wie GitHub bereitstellt und Benutzer anhand ihrer E-Mail-Adresse oder anderer Eigenschaften überprüft.

In diesem Tutorial verwenden Sie oauth2_proxy mit GitHub, um Ihre Dienste zu schützen. Wenn Sie fertig sind, verfügen Sie über ein Autorisierungssystem, das dem in der folgenden Abbildung entspricht:

A diagram of a request flow end-result

Voraussetzungen

Um dieses Tutorial abzuschließen, benötigen Sie:

[[Schritt 1 - Konfigurieren Ihrer Domänen]] == Schritt 1 - Konfigurieren Ihrer Domänen

Nachdem Sie dem im Abschnitt Voraussetzungen verlinkten Lernprogramm gefolgt sind, werden in Ihrem Cluster zwei Webdienste ausgeführt:echo1 undecho2. Sie haben auch einen Eingang, derecho1.your_domain undecho2.your_domain den entsprechenden Diensten zuordnet.

In diesem Tutorial verwenden wir die folgenden Konventionen:

  • Alle privaten Dienste fallen unter die Subdomain.int.your_domain, wieservice.int.your_domain. Das Gruppieren privater Dienste unter einer Subdomain ist ideal, da das Authentifizierungscookie für alle Subdomains von*.int.your_domainfreigegeben wird.

  • Das Anmeldeportal wird aufauth.int.your_domain bereitgestellt.

[.note] #Note: Stellen Sie sicher, dass Sieyour_domain durch Ihren eigenen Domainnamen ersetzen, wo immer dies in diesem Lernprogramm angezeigt wird.
#

Aktualisieren Sie zunächst die vorhandene Eingangsdefinition, um die Diensteecho1 undecho2unter.int.your_domain zu verschieben. Öffnen Sieecho_ingress.yaml in Ihrem Texteditor, damit Sie die Domänen ändern können:

nano echo_ingress.yaml

Benennen Sie alle Instanzen vonecho1.your_domain inecho1.int.your_domain um und ersetzen Sie alle Instanzen vonecho2.your_domain durchecho2.int.your_domain:

echo_ingress.yaml

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: echo-ingress
  annotations:
    kubernetes.io/ingress.class: nginx
    certmanager.k8s.io/cluster-issuer: letsencrypt-prod
spec:
  tls:
  - hosts:
    - echo1.int.your_domain
    - echo2.int.your_domain
    secretName: letsencrypt-prod
  rules:
  - host: echo1.int.your_domain
    http:
      paths:
      - backend:
          serviceName: echo1
          servicePort: 80
  - host: echo2.int.your_domain
    http:
      paths:
      - backend:
          serviceName: echo2
          servicePort: 80

Speichern Sie die Datei und übernehmen Sie die Änderungen:

kubectl apply -f echo_ingress.yaml

Dadurch werden auch die TLS-Zertifikate für Ihre Diensteecho1 undecho2aktualisiert.

Aktualisieren Sie nun Ihre DNS-Konfiguration, um die von Ihnen vorgenommenen Änderungen widerzuspiegeln. Überprüfen Sie zunächst die IP-Adresse Ihres Nginx-Eingangs, indem Sie den folgenden Befehl ausführen, um dessen Details zu drucken:

kubectl get svc --namespace=ingress-nginx

Sie sehen die IP-Adresse unterEXTERNAL-IP in der Ausgabe:

OutputNAME            TYPE           CLUSTER-IP      EXTERNAL-IP       PORT(S)                      AGE
ingress-nginx   LoadBalancer   10.245.247.67   203.0.113.0   80:32486/TCP,443:32096/TCP   20h

Kopieren Sie die externe IP-Adresse in Ihre Zwischenablage. Navigieren Sie zu Ihrem DNS-Verwaltungsdienst und suchen Sie dieA-Datensätze fürecho1-2.your_domain, um auf diese externe IP-Adresse zu verweisen. Wenn Sie Ihre DNS-Einträge mit DigitalOcean verwalten, finden Sie Anweisungen inHow to Manage DNS Records.

Löschen Sie die Datensätze fürecho1 undecho2. Fügen Sie einen neuenA-Datensatz für den Hostnamen*.int.your_domain hinzu und verweisen Sie ihn auf die externe IP-Adresse des Eingangs.

Jetzt wird jede Anforderung an eine Subdomain unter*.int.your_domain an den Nginx-Eingang weitergeleitet, sodass Sie diese Subdomains in Ihrem Cluster verwenden können.

Als Nächstes konfigurieren Sie GitHub als Ihren Anmeldeanbieter.

[[Schritt-2 - Erstellen einer Github-Oauth-Anwendung]] == Schritt 2 - Erstellen einer GitHub-OAuth-Anwendung

oauth2_proxy unterstützt verschiedene Login-Anbieter. In diesem Tutorial verwenden Sie den GitHub-Anbieter. Erstellen Sie zunächst eine neue GitHub OAuth-App.

Klicken Sie auf der SeiteOAuth Apps tab of the Developer settings Ihres Kontos auf die SchaltflächeNew OAuth App.

Die FelderApplication name undHomepage URLkönnen beliebig sein. Geben Sie im FeldAuthorization callback URLhttps://auth.int.your_domain/oauth2/callback ein.

Nach der Registrierung der Anwendung erhalten Sie eine Kunden-ID und ein Geheimnis. Notieren Sie sich die beiden, da Sie sie im nächsten Schritt benötigen.

Nachdem Sie eine GitHub-OAuth-Anwendung erstellt haben, können Sie oauth2_proxy installieren und konfigurieren.

[[Schritt-3 -–- Einrichten des Anmeldeportals]] == Schritt 3 - Einrichten des Anmeldeportals

Sie werden Helm verwenden, um oauth2proxy onto the cluster. First, you’ll create a Kubernetes secret to hold the GitHub application’s Client ID and Secret, as well as an encryption secret for browser cookies set by oauth2proxy zu installieren.

Führen Sie den folgenden Befehl aus, um ein sicheres Cookie-Geheimnis zu generieren:

python -c 'import os,base64; print base64.b64encode(os.urandom(16))'

Kopieren Sie das Ergebnis in Ihre Zwischenablage

Erstellen Sie dann das Kubernetes-Geheimnis und ersetzen Sie Ihr Cookie-Geheimnis, Ihre GitHub-Client-ID und Ihren GitHub-Geheimschlüssel durch die hervorgehobenen Werte:

kubectl -n default create secret generic oauth2-proxy-creds \
--from-literal=cookie-secret=YOUR_COOKIE_SECRET \
--from-literal=client-id=YOUR_GITHUB_CLIENT_ID \
--from-literal=client-secret=YOUR_GITHUB_SECRET

Sie sehen die folgende Ausgabe:

Outputsecret/oauth2-proxy-creds created

Erstellen Sie als Nächstes eine neue Datei mit dem Namenoauth2-proxy-config.yaml, die die Konfiguration füroauth2_proxy enthält:

nano oauth2-proxy-config.yaml

Die Werte, die Sie in dieser Datei festlegen, überschreiben die Standardwerte der Helmkarte. Fügen Sie der Datei den folgenden Code hinzu:

oauth2-proxy-config.yaml

config:
  existingSecret: oauth2-proxy-creds

extraArgs:
  whitelist-domain: .int.your_domain
  cookie-domain: .int.your_domain
  provider: github

authenticatedEmailsFile:
  enabled: true
  restricted_access: |-
    [email protected]
    [email protected]

ingress:
  enabled: true
  path: /
  hosts:
    - auth.int.your_domain
  annotations:
    kubernetes.io/ingress.class: nginx
    certmanager.k8s.io/cluster-issuer: letsencrypt-prod
  tls:
    - secretName: oauth2-proxy-https-cert
      hosts:
        - auth.int.your_domain

Dieser Code bewirkt Folgendes:

  1. Weist oauth2_proxy an, das von Ihnen erstellte Geheimnis zu verwenden.

  2. Legt den Domainnamen und den Providertyp fest.

  3. Legt eine Liste der zulässigen E-Mail-Adressen fest. Wenn ein GitHub-Konto mit einer dieser E-Mail-Adressen verknüpft ist, erhält es Zugriff auf die privaten Dienste.

  4. Konfiguriert den Eingang, der das Anmeldeportal aufauth.int.your_domain bedient, mit einem TLS-Zertifikat von Let's Encrypt.

Nachdem Sie die Geheim- und Konfigurationsdatei bereit haben, können Sieoauth2_proxy installieren. Führen Sie den folgenden Befehl aus:

helm repo update \
&& helm upgrade oauth2-proxy --install stable/oauth2-proxy \
--reuse-values \
--values oauth2-proxy-config.yaml

Es kann einige Minuten dauern, bis das Let's Encrypt-Zertifikat ausgestellt und installiert ist.

Navigieren Sie zuhttps://auth.int.your_domain, um zu testen, ob die Bereitstellung erfolgreich war. Es wird eine Seite angezeigt, auf der Sie aufgefordert werden, sich bei GitHub anzumelden.

Nach dem Einrichten und Ausführen von oauth2_proxy ist lediglich eine Authentifizierung für Ihre Dienste erforderlich.

[[Schritt 4 - Schutz der privaten Dienste]] == Schritt 4 - Schutz der privaten Dienste

Um einen Dienst zu schützen, konfigurieren Sie seinen Nginx-Eingang so, dass die Authentifizierung über oauth2_proxy erzwungen wird. Nginx und nginx-ingress unterstützen diese Konfiguration nativ, sodass Sie der Ingress-Definition nur ein paar Anmerkungen hinzufügen müssen.

Schützen wir die Diensteecho1 undecho2, die Sie im vorausgesetzten Lernprogramm eingerichtet haben. Öffnen Sieecho_ingress.yaml in Ihrem Editor:

nano echo_ingress.yaml

Fügen Sie der Datei diese zwei zusätzlichen Anmerkungen hinzu, um eine Authentifizierung zu erfordern:

echo_ingress.yaml

   annotations:
     kubernetes.io/ingress.class: nginx
     certmanager.k8s.io/cluster-issuer: letsencrypt-prod
     nginx.ingress.kubernetes.io/auth-url: "https://auth.int.your_domain/oauth2/auth"
     nginx.ingress.kubernetes.io/auth-signin: "https://auth.int.your_domain/oauth2/start?rd=https%3A%2F%2F$host$request_uri"

Speichern Sie die Datei und übernehmen Sie die Änderungen:

kubectl apply -f echo_ingress.yaml

Wenn Sie nun zuhttps://echo1.int.your_domain navigieren, werden Sie aufgefordert, sich mit GitHub anzumelden, um darauf zugreifen zu können. Nachdem Sie sich mit einem gültigen Konto angemeldet haben, werden Sie zum Dienst vonecho1zurückgeleitet. Gleiches gilt fürecho2.

Fazit

In diesem Tutorial haben Sie oauth2_proxy in Ihrem Kubernetes-Cluster eingerichtet und einen privaten Dienst hinter einem GitHub-Login geschützt. Befolgen Sie für alle anderen Dienste, die Sie schützen müssen, einfach die Anweisungen in Schritt 4.

oauth2_proxy unterstützt viele andere Anbieter als GitHub. Weitere Informationen zu verschiedenen Anbietern finden Sie unterthe official documentation.

Darüber hinaus müssen möglicherweise viele Konfigurationsparameter angepasst werden, obwohl die Standardeinstellungen für die meisten Anforderungen geeignet sind. Eine Liste der Parameter finden Sie unterthe Helm chart’s documentation undoauth2_proxy’s documentation.