Externe Identitätsanbieter zur Authentifizierung bei GKE verwenden

Standard

Auf dieser Seite wird erläutert, wie Sie einen externen Identitätsanbieter für die Authentifizierung bei GKE-Clustern (Google Kubernetes Engine) konfigurieren.

Übersicht

Identity Service for GKE erweitert Ihre vorhandenen Identitätslösungen für die Authentifizierung in Ihren GKE-Clustern. Mit der Unterstützung von OpenID Connect (OIDC) können Sie den Zugriff auf Kubernetes-Cluster verwalten, indem Sie die Standardverfahren in Ihrer Organisation zum Erstellen, Aktivieren und Deaktivieren von Nutzerkonten verwenden. Identity Service for GKE ist auf OIDC-Identitätsanbieter beschränkt.

Hinweis

In diesem Thema wird davon ausgegangen, dass Sie mit den folgenden Authentifizierungs- und OpenID-Konzepten vertraut sind:
Monitorlose Systeme werden nicht unterstützt. Über einen browserbasierten Authentifizierungsvorgang werden Sie zur Zustimmung aufgefordert, um dann Ihr Nutzerkonto zu autorisieren.

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

Aktivieren Sie die Google Kubernetes Engine API.

Google Kubernetes Engine API aktivieren

Wenn Sie die Google Cloud CLI für diese Aufgabe verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit gcloud components update ab.
Hinweis: Legen Sie für vorhandene Installationen der gcloud CLI die compute/region- und compute/zone-Attribute fest. Durch das Festlegen von Standardspeicherorten können Sie in der gcloud CLI Fehler wie One of [--zone, --region] must be supplied: Please specify location vermeiden.

Wer verwendet Identity Service for GKE?

Die Aufgaben in diesem Dokument sind relevant, wenn Sie zu einer der folgenden Gruppen gehören:

Clusteradministrator: Erstellt einen oder mehrere Nutzercluster und Konfigurationsdateien für die Authentifizierung für Entwickler, die die Cluster verwenden.
Entwickler: Führt Arbeitslasten auf einem oder mehreren Clustern aus und verwendet OIDC zur Authentifizierung.

So gehts:

Zum Einrichten und Verwenden von Identity Service for GKE in Ihrem GKE-Cluster tun Clusteradministratoren folgendes:

Identity Service for GKE in einem Cluster konfigurieren.
Identity Service for GKE konfigurieren.
RBAC-Richtlinie für Ihren Cluster erstellen.

Nachdem Clusteradministratoren Identity Service for GKE konfiguriert haben, können sich Entwickler im Cluster anmelden und sich authentifizieren.

Identity Service for GKE in einem Cluster aktivieren

Dieser Abschnitt richtet sich an Clusteradministratoren.

Standardmäßig ist Identity and Access Management (IAM) als Identitätsanbieter für die Clusterauthentifizierung konfiguriert. Wenn Sie OIDC mit externen Identitätsanbietern verwenden möchten, können Sie Identity Service for GKE über die Google Cloud-Befehlszeile auf neuen oder vorhandenen Clustern aktivieren.

Identity Service for GKE für einen neuen Cluster aktivieren

Führen Sie folgenden Befehl aus, um einen Cluster mit aktiviertem Identity Service for GKE zu erstellen:

gcloud container clusters create CLUSTER_NAME \
    --enable-identity-service

Ersetzen Sie dabei CLUSTER_NAME durch den Namen des neuen Clusters.

Identity Service for GKE auf einem vorhandenen Cluster aktivieren

Führen Sie folgenden Befehl aus, um Identity Service for GKE auf einem vorhandenen Cluster zu aktivieren:

gcloud container clusters update CLUSTER_NAME \
    --enable-identity-service

Ersetzen Sie CLUSTER_NAME durch den Namen Ihres Clusters.

Von Identity Service for GKE erstellte Kubernetes-Objekte

In folgender Tabelle werden die Kubernetes-Objekte beschrieben, die beim Aktivieren von Identity Service for GKE für einen Cluster erstellt werden:

Kubernetes-Objekte
`anthos-identity-service`	`Namespace` Wird für den Identity Service for GKE-Bereitstellungen verwendet.
`kube-public`	`Namespace` Wird für die `default`-konfigurationsdatei des Clients verwendet.
`gke-oidc-envoy`	`LoadBalancer` Der Endpunkt für OIDC-Anfragen. Standardmäßig extern. Wenn der Endpunkt in einem privaten Cluster oder einem Cluster mit einer strengen Netzwerkrichtlinie erstellt wird, liegt er intern in der Virtual Private Cloud des Clusters. Wird im Namespace `anthos-identity-service` erstellt.
`gke-oidc-service`	`ClusterIP` Ermöglicht die Kommunikation zwischen dem `gke-oidc-envoy`-Bereitstellung und der `gke-oidc-service`-Bereitstellung. Wird im Namespace `anthos-identity-service` erstellt.
`gke-oidc-envoy`	`Deployment` Führt einen Proxy aus, der für den Load-Balancer `gke-oidc-envoy` freigegeben ist. Kommuniziert mit `gke-oidc-service`, um Identitätstokens zu validieren. Fungiert als Proxy für den Kubernetes API-Server und übernimmt die Identität von Nutzern, wenn Anfragen an den API-Server übergeben werden. Wird im Namespace `anthos-identity-service` erstellt.
`gke-oidc-service`	`Deployment` Validiert Identitätstokens und bietet einen validierenden Zulassungs-Webhook für `ClientConfig`-Ressourcen. Wird im Namespace `anthos-identity-service` erstellt.
`gke-oidc-operator`	`Deployment` Vergleicht die Clientkonfiguration und den Load-Balancer `gke-oidc-envoy`. Wird im Namespace `anthos-identity-service` erstellt.
`gke-oidc-certs`	`Secret` Enthält die Cluster-Zertifizierungsstelle (CA) und TLS-Zertifikate für den LoadBalancer. Wird im Namespace `anthos-identity-service` erstellt.
`default`	`ClientConfig CRD` Enthält OIDC-Parameter wie bevorzugte Authentifizierungsmethode, Identitätsanbieterkonfiguration sowie Nutzer- und Gruppenanforderungenzuordnungen. Wird zur Validierung von Identitätstokens verwendet. Wird von Clusteradministratoren verwendet, um OIDC-Einstellungen zu konfigurieren, bevor sie an Entwickler verteilt werden. Wird im Namespace `kube-public` erstellt.

Identity Service for GKE konfigurieren

Dieser Abschnitt richtet sich an Clusteradministratoren.

Um Identity Service for GKE-Parameter zu konfigurieren, laden Sie die ClientConfig default herunter und bearbeiten sie.

Laden Sie die default-ClientConfig herunter:

kubectl get clientconfig default -n kube-public -o yaml > client-config.yaml

Aktualisieren Sie den spec.authentication-Abschnitt mit Ihren bevorzugten Einstellungen:
```
apiVersion: authentication.gke.io/v2alpha1
kind: ClientConfig
metadata:
  name: default
  namespace: kube-public
spec:
  name: cluster-name
  server: https://192.168.0.1:6443
  authentication:
  - name: oidc
    oidc:
      clientID: CLIENT_ID
      certificateAuthorityData: OIDC_PROVIDER_CERTIFICATE
      extraParams: EXTRA_PARAMS
      issuerURI:  ISSUER_URI
      cloudConsoleRedirectURI: https://console.cloud.google.com/kubernetes/oidc
      kubectlRedirectURI: KUBECTL_REDIRECT_URL
      scopes: SCOPES
      userClaim: USER
      groupsClaim: GROUPS
      userPrefix: USER_PREFIX
      groupPrefix: GROUP_PREFIX
```
Ersetzen Sie Folgendes:
- CLIENT_ID durch die ID der Clientanwendung, die Authentifizierungsanfragen an den OIDC-Anbieter sendet.
- OIDC_PROVIDER_CERTIFICATE: (Optional) Ein PEM-Zertifikat für den OIDC-Anbieter. Dieses Feld kann hilfreich sein, wenn Ihr OIDC-Anbieter selbstsignierte Zertifikate verwendet. Identity Service for GKE enthält standardmäßig eine Reihe öffentlicher Roots.
- EXTRA_PARAMS: Zusätzliche Schlüssel/Wert-Parameter, die an den OIDC-Anbieter gesendet werden.
  - Verwenden Sie resource=token-groups-claim zum Autorisieren von Gruppen.
  - Verwenden Sie prompt=consent zur Authentifizierung von Microsoft Azure und Okta.
  - Verwenden Sie prompt=consent,access_type=offline für Cloud Identity.
- ISSUER_URI: Die URL, an die OIDC-Autorisierungsanfragen gesendet werden, z. B. https://example.com/adfs. Der Kubernetes API-Server nutzt diese URL, um öffentliche Schlüssel zum Verifizieren von Tokens zu ermitteln. Für den URI muss HTTPS verwendet werden. Verwenden Sie https://accounts.google.com für Cloud Identity.
- KUBECTL_REDIRECT_URL: Die Weiterleitungs-URL, die kubectl oidc login für die Autorisierung verwendet. Sie hat in der Regel das Format http://localhost:PORT/callback, wobei PORT ein beliebiger Port über 1024 ist, der auf Entwickler-Workstations verfügbar ist, wie z. B. http://localhost:10000/callback. Sie müssen die URL bei Ihrem OIDC-Anbieter als autorisierte Weiterleitungs-URL für die Clientanwendung registrieren. Wenn Sie Google Identity als OIDC-Anbieter verwenden, folgen Sie der Anleitung unter Weiterleitungs-URI festlegen.
- SCOPES: Zusätzliche Bereiche, die an den OIDC-Anbieter gesendet werden.
  - Microsoft Azure und Okta benötigen den Bereich offline_access.
  - Verwenden Sie für Cloud Identity openid, email, um ID-Tokens abzurufen, die die E-Mail-Adresse im Anforderung email enthalten.
- USER: Die Nutzeranforderung aus dem Identitätstoken.
- GROUPS: Die Gruppenanforderung aus dem Identitätstoken.
- USER_PREFIX: Das Präfix, das Gruppenanforderungen vorangestellt wird, um Konflikte mit vorhandenen Namen zu vermeiden. Standardmäßig wird ein Ausstellerpräfix an userID angehängt, der dem Kubernetes API-Server zugewiesen ist (es sei denn, der Nutzeranspruch ist email). Die resultierende Nutzer-ID lautet ISSUER_URI#USER. Wir empfehlen die Verwendung eines Präfixes. Wenn Sie das Präfix deaktivieren wollen, setzen Sie USER_PREFIX auf -.
- GROUP_PREFIX: Das Präfix, das Gruppenanforderungen vorangestellt wird, um Konflikte mit vorhandenen Namen zu vermeiden. Wenn Sie beispielsweise zwei Gruppen mit dem Namen foobar haben, fügen Sie das Präfix gid- hinzu. Die resultierende Gruppe ist gid-foobar.
Wenden Sie die aktualisierte Konfiguration an:
```
kubectl apply -f client-config.yaml
```
Nachdem Sie diese Konfiguration angewendet haben, wird Identity Service for GKE in Ihrem Cluster ausgeführt und verarbeitet Anfragen hinter dem Load-Balancer gke-oidc-envoy. Die IP-Adresse im Feld spec.server muss die IP-Adresse des Load-Balancers sein. Wenn Sie das Feld spec.server ändern, schlagen kubectl-Befehle möglicherweise fehl.
Erstellen Sie eine Kopie der Konfigurationsdatei client-config.yaml:
```
cp client-config.yaml login-config.yaml
```
Aktualisieren Sie die Konfigurationsdatei login-config.yaml mit der Einstellung clientSecret im Abschnitt spec.authentication.oidc.
```
clientSecret: CLIENT_SECRET
```
Ersetzen Sie CLIENT_SECRET durch das gemeinsame Secret zwischen der OIDC-Clientanwendung und dem OIDC-Anbieter.
Verteilen Sie die aktualisierte Datei login-config.yaml an Ihre Entwickler.

Identity Service for GKE auf Clustern mit strengen Richtlinien konfigurieren

So konfigurieren Sie Identity Service for GKE für Cluster, die strenge Netzwerkrichtlinien haben, z. B. private Cluster:

Fügen Sie eine Firewallregel für den TCP-Port 15000 hinzu, damit die Steuerungsebene mit dem ClientConfig-Validierungs-Webhook kommunizieren kann.
Wenn die gke-oidc-envoy als interner Load-Balancer erstellt wird, stellen Sie sie in Ihrer VPC bereit.
Wenn Richtlinien in Ihrem Cluster abgelehnt werden, fügen Sie eine Firewallregel für den TCP-Port 8443 hinzu, damit die Bereitstellung gke-oidc-envoy mit der Bereitstellung gke-oidc-service kommunizieren kann.

Die Komponente "Identity Service for GKE" Version 0.2.20 und höher verwendet den TCP-Port 15000 nicht. Wenn Ihre Version der Komponente 0.2.20 oder höher ist, müssen Sie keine Firewallregel für Port 15000 hinzufügen. Führen Sie folgenden Befehl aus, um die Version der Komponente zu prüfen:

kubectl describe deployment gke-oidc-envoy -n anthos-identity-service \
    | grep "components.gke.io/component-name: gke-oidc" -A1

Benutzerdefinierte Attribute zum Load-Balancer hinzufügen

Nachdem Sie Identity Service for GKE konfiguriert haben, können Sie dem gke-oidc-envoy-Load-Balancer benutzerdefinierte Annotationen und Attribute, z. B. eine statische IP-Adresse, hinzufügen. Führen Sie zum Bearbeiten des gke-oidc-envoy-Dienstes den folgenden Befehl aus:

kubectl edit service gke-oidc-envoy -n anthos-identity-service

Lesen Sie in der Dokumentation wie Konfigurieren von TCP/UDP-Load-Balancing für GKE funktioniert.

RBAC-Richtlinie für Ihren Cluster erstellen

Dieser Abschnitt richtet sich an Clusteradministratoren.

Administratoren können mit der rollenbasierten Zugriffssteuerung (Role-based Access Control, RBAC) von Kubernetes authentifizierten Clusternutzern Zugriff gewähren. Zur Konfiguration von RBAC für Ihren Cluster müssen Sie jedem Entwickler RBAC-Rollen zuweisen. Wenn Sie Zugriff auf Ressourcen in einem bestimmten Namespace gewähren möchten, erstellen Sie eine Role und eine RoleBinding. Wenn Sie Zugriff auf Ressourcen auf einem gesamten Cluster gewähren möchten, erstellen Sie eine ClusterRole und eine ClusterRoleBinding.

Angenommen, ein Nutzer muss alle Secret-Objekte im gesamten Cluster anzeigen. Durch die folgenden Schritte werden diesem Nutzer die erforderlichen RBAC-Rollen zugewiesen.

Speichern Sie das folgende ClusterRole-Manifest als secret-viewer-cluster-role.yaml. Eine Person, der diese Rolle zugewiesen wurde, kann beliebige Secrets im Cluster abrufen, beobachten und auflisten.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: secret-viewer
rules:
- apiGroups: [""]
  # The resource type for which access is granted
  resources: ["secrets"]
  # The permissions granted by the ClusterRole
  verbs: ["get", "watch", "list"]

Wenden Sie das ClusterRole-Manifest an:

kubectl apply -f secret-viewer-cluster-role.yaml

Speichern Sie das folgende ClusterRoleBinding-Manifest als secret-viewer-cluster-role-binding.yaml. Durch die Bindung wird einem in der Clientkonfigurationsdatei definierten Nutzernamen die Rolle secret-viewer zugewiesen.
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name:  people-who-view-secrets
subjects:
- kind: User
  name: ISSUER_URI#USER
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-viewer
  apiGroup: rbac.authorization.k8s.io
```
Ersetzen Sie Folgendes:
- ISSUER_URI durch die Aussteller-URI aus spec.authentication.oidc.issuerURI in der Client-Konfigurationsdatei.
- USERdurch die Nutzerkennung im Token unter dem Anforderungsnamen, der in spec.authentication.oidc.userClaim in der Client-Konfigurationsdatei konfiguriert ist.

Wenden Sie das ClusterRoleBinding-Manifest an:

kubectl apply -f secret-viewer-cluster-role-binding.yaml

Beim Cluster anmelden und authentifizieren

Dieser Abschnitt richtet sich an Entwickler.

Wenn Sie die OIDC-Konfigurationsdatei von Ihrem Administrator erhalten, können Sie sich bei Ihren Clustern authentifizieren.

Laden Sie die vom Administrator bereitgestellte Datei login-config.yaml herunter.
Installieren Sie das Google Cloud CLI-SDK, das eine separate OIDC-Komponente bietet. Zur Installation führen Sie folgenden Befehl aus:
```
gcloud components install kubectl-oidc
```
Authentifizieren Sie sich bei Ihrem Cluster:
```
kubectl oidc login --cluster=CLUSTER_NAME --login-config=login-config.yaml
```
Ein Webbrowser wird geöffnet, um den Authentifizierungsvorgang abzuschließen.
Nach der Authentifizierung können Sie kubectl-Befehle ausführen, zum Beispiel:
```
kubectl get pods
```

Identity Service for GKE deaktivieren

Dieser Abschnitt richtet sich an Clusteradministratoren.

Sie können Identity Service for GKE mit der gcloud CLI deaktivieren. Führen Sie zum Deaktivieren von Identity Service for GKE folgenden Befehl aus:

gcloud container clusters update CLUSTER_NAME \
    --no-enable-identity-service

Nächste Schritte

Weitere Informationen zum Bereitstellen von Arbeitslasten
Mehr über OpenID Connect erfahren
Bereiche und Anforderungen