GKE-Anwendungen und -Ressourcen mit IAP sichern.

Auf dieser Seite wird erläutert, wie eine Google Kubernetes Engine-Instanz (GKE) mit Identity-Aware Proxy (IAP) geschützt wird.

Informationen zum Schutz von Ressourcen, die nicht in Google Cloud gespeichert sind, finden Sie unter Lokale Anwendungen und Ressourcen sichern.

Überblick

IAP wird über Ingress für GKE eingebunden. Damit können Sie den Zugriff für Mitarbeiter auf Ressourcenebene steuern, anstatt ein VPN zu verwenden.

In einem GKE-Cluster wird eingehender Traffic von HTTP(S)-Load-Balancing verarbeitet, einer Komponente von Cloud Load Balancing. Der HTTP(S)-Load-Balancer wird normalerweise vom Kubernetes Ingress-Controller konfiguriert. Der Ingress-Controller ruft Konfigurationsinformationen von einem Kubernetes-Ingress-Objekt ab, das einem oder mehreren Dienstobjekten zugeordnet ist. Jedes Serviceobjekt enthält Routinginformationen, mit denen eingehende Anfragen an einen bestimmten Pod und Port weitergeleitet werden können.

Ab Kubernetes Version 1.10.5-gke.3 können Sie eine Konfiguration für den Load-Balancer hinzufügen. Ordnen Sie dazu einem BackendConfig-Objekt einen Dienst zu. BackendConfig ist eine benutzerdefinierte Ressourcendefinition, die im Repository kubernetes/ingress-gce festgelegt wird.

Der Kubernetes Ingress-Controller liest die Konfigurationsinformationen aus BackendConfig und richtet den Load-Balancer entsprechend ein. BackendConfig enthält für Cloud Load Balancing spezifische Konfigurationsinformationen, mit denen Sie eine separate Konfiguration für jeden Back-End-Dienst des HTTP(S)-Load-Balancing definieren können.

Hinweise

Zum Aktivieren von IAP für GKE benötigen Sie Folgendes:

  • Ein Google Cloud Console-Projekt mit aktivierter Abrechnung.
  • Eine Gruppe mit einer oder mehreren GKE-Instanzen, die von einem HTTPS-Load-Balancer bereitgestellt werden. Der Load-Balancer sollte automatisch erstellt werden, wenn Sie in einem GKE-Cluster ein Ingress-Objekt erstellen.
  • Einen Domainnamen, der für die Adresse des Load-Balancers registriert ist.
  • Anwendungscode, der überprüft, ob alle Anfragen eine Identität haben.

IAP aktivieren

Wenn Sie den OAuth-Zustimmungsbildschirm Ihres Projekts noch nicht konfiguriert haben, werden Sie dazu aufgefordert. Eine Anleitung dazu finden Sie unter OAuth-Zustimmungsbildschirm einrichten.

IAP-Zugriff einrichten

  1. Rufen Sie die Seite Identity-Aware Proxy auf.
    Zur Seite "Identity-Aware Proxy"
  2. Wählen Sie das Projekt aus, das Sie mit IAP sichern möchten.

  3. Klicken Sie das Kästchen neben der Ressource an, für die Sie Zugriff gewähren möchten.

    Wenn keine Ressource angezeigt wird, prüfen Sie, ob die Ressource erstellt wurde und der BackendConfig-Compute Engine-Ingress-Controller synchronisiert ist.

    Führen Sie den folgenden gcloud-Befehl aus, um zu prüfen, ob der Backend-Dienst verfügbar ist:

    gcloud compute backend-services list
  4. Klicken Sie im rechten Bereich auf Hauptkonto hinzufügen.
  5. Fügen Sie im daraufhin angezeigten Dialogfeld Hauptkonten hinzufügen die E-Mail-Adressen von Nutzergruppen oder einzelnen Nutzern hinzu, denen Sie für das Projekt die Rolle Nutzer von IAP-gesicherten Web-Apps zuweisen möchten.

    Folgende Hauptkonten können diese Rolle haben:

    • Google-Konto: nutzer@gmail.com
    • Google Group: admins@googlegroups.com
    • Dienstkonto: server@beispiel.gserviceaccount.com
    • Google Workspace-Domain: beispiel.de

    Fügen Sie unbedingt ein Google-Konto hinzu, auf das Sie zugreifen können.

  6. Wählen Sie in der Drop-down-Liste Rollen den Eintrag Cloud IAP > Nutzer von IAP-gesicherten Web-Apps aus.
  7. Klicken Sie auf Speichern.

BackendConfig konfigurieren

Erstellen Sie ein Kubernetes-Secret und fügen dann einen iap-Block zu BackendConfig hinzu, um BackendConfig für IAP zu konfigurieren.

Ein Kubernetes-Secret erstellen

BackendConfig verwendet ein Kubernetes-Secret, um den zuvor erstellten OAuth-Client zu verpacken. Kubernetes-Secrets werden wie andere Kubernetes-Objekte mithilfe der kubectl-Befehlszeile verwaltet. Mit folgendem Befehl erstellen Sie ein Secret, wobei client_id_key und client_secret_key die Schlüssel aus der JSON-Datei sind, die Sie beim Erstellen der OAuth-Anmeldedaten heruntergeladen haben: 

kubectl create secret generic my-secret --from-literal=client_id=client_id_key \
    --from-literal=client_secret=client_secret_key

Mit dem vorherigen Befehl wird eine Ausgabe angezeigt, um zu bestätigen, dass das Secret erfolgreich erstellt wurde:

secret "my-secret" created

Einen iap-Block zu BackendConfig hinzufügen

Zum Konfigurieren von BackendConfig für IAP müssen Sie die Werte enabled und secretName angeben. Achten Sie darauf, dass Sie die Berechtigung compute.backendServices.update haben, und fügen Sie BackendConfig den iap-Block hinzu, um diese Werte festzulegen. In diesem Block ist my-secret der Name zuvor erstellten Kubernetes-Secrets:

Verwenden Sie für die GKE-Versionen 1.16.8-gke.3 und höher die API-Version „cloud.google.com/v1“. Wenn Sie eine ältere GKE-Version verwenden, verwenden Sie „cloud.google.com/v1beta1“. 

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: config-default
  namespace: my-namespace
spec:
  iap:
    enabled: true
    oauthclientCredentials:
      secretName: my-secret

Zum Aktivieren von IAP müssen Sie noch Dienstports mit Ihrer BackendConfig verknüpfen. Sie können diese Verknüpfung dadurch herstellen, dass Sie Ihre BackendConfig als Standardeinstellung für alle Ports angeben. Fügen Sie Ihrer Dienstressource hierfür folgende Annotation hinzu: 

metadata:
  annotations:
    beta.cloud.google.com/backend-config: '{"default": "config-default"}'

Führen Sie kubectl get event aus, um die Konfiguration zu testen. Wird die Meldung "no BackendConfig for service port exists" angezeigt, haben Sie den Dienstport erfolgreich mit Ihrer BackendConfig verknüpft, die BackendConfig-Ressource wurde jedoch nicht gefunden. Dieser Fehler kann auftreten, wenn Sie die BackendConfig-Ressource gar nicht oder im falschen Namespace erstellt haben oder den Verweis in der Dienstannotation falsch geschrieben haben.

Wenn der von Ihnen referenzierte secretName nicht existiert oder nicht richtig strukturiert ist, wird eine der folgenden Fehlermeldungen angezeigt:

  • BackendConfig default/config-default is not valid: error retrieving secret "foo": secrets "foo" not found. Dieser Fehler lässt sich beheben, indem Sie dafür sorgen, dass das Kubernetes-Secret wie im letzten Abschnitt beschrieben korrekt erstellt wurde.
  • BackendConfig default/config-default is not valid: secret "foo" missing client_secret data. Dieser Fehler lässt sich beheben, indem Sie dafür sorgen, dass die OAuth-Anmeldedaten korrekt erstellt wurden. Prüfen Sie außerdem, ob Sie in der zuvor heruntergeladenen JSON-Datei die richtigen client_id- und client_secret-Schlüssel referenziert haben.

Wenn das Flag enabled auf true gesetzt und secretName korrekt festgelegt ist, dann ist IAP für die ausgewählte Ressource konfiguriert.

IAP deaktivieren

Zum Deaktivieren von IAP müssen Sie für enabled in BackendConfig den Wert false festlegen. Wenn Sie den IAP-Block aus BackendConfig löschen, bleiben die Einstellungen erhalten. Beispiel: Wenn IAP mit secretName: my_secret aktiviert ist und Sie den Block löschen, wird IAP weiterhin mit den in my_secret gespeicherten OAuth-Anmeldedaten aktiviert.

Nächste Schritte