Probleme mit der GKE-Authentifizierung beheben

Auf dieser Seite wird beschrieben, wie Sie Probleme im Zusammenhang mit Sicherheitskonfigurationen in Ihren Autopilot- und Standardclustern in Google Kubernetes Engine (GKE) beheben.

Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Cloud Customer Care.

RBAC und IAM

Authentifizierte IAM-Konten können keine Aktionen im Cluster ausführen

Das folgende Problem tritt auf, wenn Sie versuchen, eine Aktion im Cluster auszuführen, GKE aber keine RBAC-Richtlinie finden kann, die die Aktion autorisiert. GKE versucht, eine IAM-Zulassungsrichtlinie zu finden, die dieselbe Berechtigung gewährt. Wenn dies fehlschlägt, wird eine Fehlermeldung wie die folgende angezeigt:

Error from server (Forbidden): roles.rbac.authorization.k8s.io is forbidden:
User "example-account@example-project.iam.gserviceaccount.com" cannot list resource "roles" in
API group "rbac.authorization.k8s.io" in the namespace "kube-system": requires
one of ["container.roles.list"] permission(s).

Verwenden Sie zum Beheben dieses Problems eine RBAC-Richtlinie, um die Berechtigungen für die versuchte Aktion zu erteilen. Um das Problem im vorherigen Beispiel zu beheben, weisen Sie eine Rolle mit der Berechtigung list für roles-Objekte im Namespace kube-system zu. Eine Anleitung finden Sie unter Aktionen in Clustern mit rollenbasierter Zugriffssteuerung autorisieren.

Workload Identity Federation for GKE

Pod kann sich nicht bei Google Cloud authentifizieren

Wenn sich Ihre Anwendung nicht bei Google Cloud authentifizieren kann, prüfen Sie, ob die folgenden Einstellungen richtig konfiguriert sind:

  1. Achten Sie darauf, dass die IAM Service Account Credentials API in dem Projekt aktiviert ist, das den GKE-Cluster enthält.

    IAM Credentials API aktivieren

  2. Prüfen Sie, ob Workload Identity Federation for GKE im Cluster aktiviert ist. Prüfen Sie dazu, ob ein Workload Identity-Pool festgelegt ist:

    gcloud container clusters describe CLUSTER_NAME \
    --format="value(workloadIdentityConfig.workloadPool)"

    Ersetzen Sie dabei CLUSTER_NAME durch den Namen Ihres GKE-Clusters.

    Wenn Sie noch keine Standardzone oder -region für gcloud angegeben haben, müssen Sie beim Ausführen dieses Befehls evtl. das Flag --region oder --zone angeben.

  3. Der GKE-Metadatenserver muss im Knotenpool, in dem Ihre Anwendung ausgeführt wird, konfiguriert sein:

    gcloud container node-pools describe NODEPOOL_NAME \
    --cluster=CLUSTER_NAME \
    --format="value(config.workloadMetadataConfig.mode)"

    Ersetzen Sie Folgendes:

    • NODEPOOL_NAME durch den Namen Ihres Knotenpools.
    • CLUSTER_NAME ist der Name des GKE-Clusters.

  4. Prüfen Sie, ob das Kubernetes-Dienstkonto richtig annotiert ist:

    kubectl describe serviceaccount \
    --namespace NAMESPACE KSA_NAME

    Ersetzen Sie Folgendes:

    • NAMESPACE durch den Namespace Ihres GKE-Clusters.
    • KSA durch den Namen Ihres Kubernetes-Dienstkontos.

    Die erwartete Ausgabe enthält eine Annotation ähnlich der folgenden:

    iam.gke.io/gcp-service-account: GSA_NAME@PROJECT_ID.iam.gserviceaccount.com

  5. Prüfen Sie, ob das IAM-Dienstkonto richtig konfiguriert ist:

    gcloud iam service-accounts get-iam-policy \
    GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com

    Die erwartete Ausgabe enthält eine Bindung, die etwa so aussieht:

    - members:
  - serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]
  role: roles/iam.workloadIdentityUser

  6. Wenn Sie eine Cluster-Netzwerkrichtlinie haben, muss ausgehender Traffic zu 127.0.0.1/32 an Port 988 für Cluster mit GKE-Versionen vor 1.21.0-gke.1000 oder zu 169.254.169.252/32 an Port 988 für Cluster mit GKE-Version 1.21.0-gke.1000 und höher zugelassen werden. Für Cluster mit GKE Dataplane V2 müssen Sie ausgehenden Traffic an 169.254.169.254/32 an Port 80 zulassen.

    kubectl describe networkpolicy NETWORK_POLICY_NAME

    Ersetzen Sie NETWORK_POLICY_NAME durch den Namen Ihrer GKE-Netzwerkrichtlinie.

Zugriff auf IAM-Dienstkonto verweigert

Pods können mit der Identitätsföderation von Arbeitslasten für GKE möglicherweise nicht auf eine Ressource zugreifen, nachdem sie IAM-Rollenbindungen hinzugefügt haben. Ein Zugriffsfehler tritt eher in Bereitstellungspipelines oder in deklarativen Google Cloud-Konfigurationen auf, in denen Ressourcen wie IAM-Zulassungsrichtlinien, Rollenbindungen und Kubernetes-Pods zusammen erstellt werden. Die folgende Fehlermeldung wird in den Pod-Logs angezeigt:

HTTP/403: generic::permission_denied: loading: GenerateAccessToken("SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com", ""): googleapi: Error 403: Permission 'iam.serviceAccounts.getAccessToken' denied on resource (or it may not exist).

Dieser Fehler kann durch die Weitergabe von Zugriffsänderungen in IAM verursacht werden. Das bedeutet, dass Zugriffsänderungen wie Rollenzuweisungen einige Zeit benötigen, bis sie im gesamten System wirksam werden. Bei Rollenzuweisungen dauert die Weitergabe in der Regel etwa zwei Minuten, kann aber manchmal sieben oder mehr Minuten dauern. Weitere Informationen finden Sie unter Zugriffsänderungsverteilung.

Um diesen Fehler zu beheben, sollten Sie eine Verzögerung hinzufügen, bevor Ihre Pods nach dem Erstellen versuchen, auf Google Cloud-Ressourcen zuzugreifen.

Probleme mit der DNS-Auflösung

Einige Google Cloud-Clientbibliotheken sind für die Verbindung mit den GKE- und Compute Engine-Metadatenserver konfiguriert, indem der DNS-Name metadata.google.internal aufgelöst wird. Für diese Bibliotheken ist eine fehlerfreie DNS-Auflösung im Cluster von entscheidender Bedeutung für die Authentifizierung der Arbeitslasten bei Google Cloud-Diensten.

Wie Sie dieses Problem erkennen, hängt von den Details Ihrer bereitgestellten Anwendung ab, einschließlich der Logging-Konfiguration. Suchen Sie nach Fehlermeldungen, die:

  • Ihnen sagen, dass Sie GOOGLE_APPLICATION_CREDENTIALS konfigurieren müssen, oder
  • Ihnen sagen, dass Ihre Anfragen an einen Google Cloud-Dienst abgelehnt wurden, da die Anfrage keine Anmeldedaten enthielt.

Wenn Probleme mit der DNS-Auflösung von metadata.google.internal auftreten, können einige Google Cloud-Clientbibliotheken angewiesen werden, die DNS-Auflösung zu überspringen, indem die Umgebungsvariable GCE_METADATA_HOST auf 169.254.169.254 festgelegt wird:

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
  namespace: default
spec:
  containers:
  - image: debian
    name: main
    command: ["sleep", "infinity"]
    env:
    - name: GCE_METADATA_HOST
      value: "169.254.169.254"

Dies ist die hartcodierte IP-Adresse, unter der der Metadatendienst auf Computing-Plattformen von Google Cloud immer verfügbar ist.

Unterstützte Google Cloud-Bibliotheken:

  • Python
  • Java
  • Node.js
  • Golang (Hinweis: Die Golang-Clientbibliothek bevorzugt bereits Verbindungen über die IP-Adresse statt über den DNS-Namen).

Zeitüberschreitungsfehler beim Starten des Pods

Der GKE-Metadatenserver benötigt einige Sekunden, bevor er Anfragen von einem neuen Pod annehmen kann. Daher können Versuche, sich mithilfe der Workload Identity Federation for GKE innerhalb der ersten Sekunden der Lebensdauer eines Pods zu authentifizieren, bei Anwendungen und Google Cloud-Clientbibliotheken, die nur mit einem kurzen Zeitlimit konfiguriert sind, fehlschlagen.

Wenn Zeitüberschreitungsfehler auftreten, versuchen Sie Folgendes:

  • Aktualisieren Sie die von Ihren Arbeitslasten verwendeten Google Cloud-Clientbibliotheken.
  • Ändern Sie den Anwendungscode. Warten Sie einige Sekunden und versuchen Sie es dann noch einmal.

  • Ein initContainer, der wartet, bis der GKE-Metadatenserver bereit ist, bevor er den Hauptcontainer des Pods ausführt.

    Das folgende Manifest gilt beispielsweise für einen Pod mit einem initContainer:

    apiVersion: v1
kind: Pod
metadata:
  name: pod-with-initcontainer
spec:
  serviceAccountName: KSA_NAME
  initContainers:
  - image:  gcr.io/google.com/cloudsdktool/cloud-sdk:alpine
    name: workload-identity-initcontainer
    command:
    - '/bin/bash'
    - '-c'
    - |
      curl -sS -H 'Metadata-Flavor: Google' 'http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/token' --retry 30 --retry-connrefused --retry-max-time 60 --connect-timeout 3 --fail --retry-all-errors > /dev/null && exit 0 || echo 'Retry limit exceeded. Failed to wait for metadata server to be available. Check if the gke-metadata-server Pod in the kube-system namespace is healthy.' >&2; exit 1
  containers:
  - image: gcr.io/your-project/your-image
    name: your-main-application-container

Die Workload Identity Federation for GKE schlägt aufgrund der Nichtverfügbarkeit der Steuerungsebene fehl

Der Metadatenserver kann die Workload Identity Federation for GKE nicht zurückgeben, wenn die Clustersteuerungsebene nicht verfügbar ist. Aufrufe an den Metadatenserver geben den Statuscode 500 zurück.

Der Logeintrag kann im Log-Explorer etwa so aussehen:

dial tcp 35.232.136.58:443: connect: connection refused

Dieses Verhalten führt zur Nichtverfügbarkeit der Workload Identity Federation for GKE.

Die Steuerungsebene ist möglicherweise in zonalen Clustern bei Clusterwartungen wie dem Rotieren von IPs, dem Upgrade von Steuerungsebenen-VMs oder der Größenanpassung von Clustern oder Knotenpools nicht verfügbar. Weitere Informationen zur Verfügbarkeit der Steuerungsebene finden Sie unter Regionale oder zonale Steuerungsebene auswählen. Durch den Wechsel zu einem regionalen Cluster wird dieses Problem behoben.

Die Authentifizierung für Workload Identity Federation for GKE schlägt in Clustern mit Istio fehl

Wenn der GKE-Metadatenserver blockiert wird, schlägt die Authentifizierung für Workload Identity Federation for GKE fehl.

Wenn Sie Istio oder Cloud Service Mesh verwenden, fügen Sie allen Arbeitslasten, die Workload Identity Federation for GKE verwenden, die folgende Annotation auf Pod-Ebene hinzu, um die IP von der Weiterleitung auszuschließen:

traffic.sidecar.istio.io/excludeOutboundIPRanges: 169.254.169.254/32

Sie können dafür auch den Schlüssel Istio ConfigMap von global.proxy.excludeIPRanges ändern.

Alternativ können Sie die folgende Annotation auf Pod-Ebene allen Arbeitslasten hinzufügen, die Workload Identity Federation for GKE verwenden, um den Start des Anwendungscontainers zu verzögern, bis der Sidecar bereit ist:

proxy.istio.io/config: '{ "holdApplicationUntilProxyStarts": true }'

Sie können dafür auch den Schlüssel Istio ConfigMap von global.proxy.holdApplicationUntilProxyStarts ändern.

gke-metadata-server-Pod stürzt ab

Der gke-metadata-server-System-DaemonSet-Pod erleichtert Workload Identity Federation for GKE auf Ihren Knoten. Der Pod verwendet Arbeitsspeicherressourcen, die proportional zur Anzahl der Kubernetes-Dienstkonten in Ihrem Cluster sind.

Das folgende Problem tritt auf, wenn die Ressourcennutzung des Pods gke-metadata-server die Limits überschreitet. Das Kubelet entfernt den Pod mit einem Fehler aufgrund fehlenden Arbeitsspeichers. Dieses Problem kann auftreten, wenn Ihr Cluster mehr als 3.000 Kubernetes-Dienstkonten hat.

So erkennen Sie das Problem:

  1. Suchen Sie nach abstürzenden gke-metadata-server-Pods im Namespace kube-system:

    kubectl get pods -n=kube-system | grep CrashLoopBackOff

    Die Ausgabe sieht etwa so aus:

    NAMESPACE     NAME                        READY     STATUS             RESTARTS   AGE
kube-system   gke-metadata-server-8sm2l   0/1       CrashLoopBackOff   194        16h
kube-system   gke-metadata-server-hfs6l   0/1       CrashLoopBackOff   1369       111d
kube-system   gke-metadata-server-hvtzn   0/1       CrashLoopBackOff   669        111d
kube-system   gke-metadata-server-swhbb   0/1       CrashLoopBackOff   30         136m
kube-system   gke-metadata-server-x4bl4   0/1       CrashLoopBackOff   7          15m

  2. Beschreiben Sie den abstürzenden Pod, um zu bestätigen, dass die Ursache eine Bereinigung Fehler aufgrund fehlenden Arbeitsspeichers war:

    kubectl describe pod POD_NAME --namespace=kube-system | grep OOMKilled

    Ersetzen Sie POD_NAME durch den Namen des zu prüfenden Pods.

Wenn Sie die Funktion auf dem GKE-Metadatenserver wiederherstellen möchten, reduzieren Sie die Anzahl der Dienstkonten in Ihrem Cluster auf weniger als 3.000.

Workload Identity Federation for GKE kann nicht mit der Fehlermeldung „DeployPatch fehlgeschlagen“ aktiviert werden

GKE verwendet den von Google Cloud verwalteten Kubernetes Engine-Dienst-Agent, um Workload Identity Federation for GKE in Ihren Clustern zu vereinfachen. Google Cloud weist diesem Dienst-Agent automatisch die Rolle des Kubernetes Engine-Dienst-Agents (roles/container.serviceAgent) für Ihr Projekt zu, wenn Sie die Google Kubernetes Engine API aktivieren.

Wenn Sie versuchen, Workload Identity Federation for GKE für Cluster in einem Projekt zu aktivieren, in dem der Dienst-Agent nicht die Rolle „Kubernetes Engine-Dienst-Agent“ hat, schlägt der Vorgang mit einer Fehlermeldung wie der folgenden fehl:

Error waiting for updating GKE cluster workload identity config: DeployPatch failed

Versuchen Sie Folgendes, um dieses Problem zu beheben:

  1. Prüfen Sie, ob der Dienst-Agent in Ihrem Projekt vorhanden und korrekt konfiguriert ist:

    gcloud projects get-iam-policy PROJECT_ID \
    --flatten=bindings \
    --filter=bindings.role=roles/container.serviceAgent \
    --format="value[delimiter='\\n'](bindings.members)"

    Ersetzen Sie PROJECT_ID durch die Google Cloud-Projekt-ID.

    Wenn der Dienst-Agent ordnungsgemäß konfiguriert ist, zeigt die Ausgabe die vollständige Identität des Dienst-Agents an:

    serviceAccount:service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com

    Wenn in der Ausgabe der Dienst-Agent nicht angezeigt wird, müssen Sie ihm die Rolle „Kubernetes Engine-Dienst-Agent“ zuweisen. Zum Gewähren dieser Rolle müssen Sie die folgenden Schritte ausführen.

  2. Rufen Sie Ihre Google Cloud-Projektnummer ab:

    gcloud projects describe PROJECT_ID \
    --format="value(projectNumber)"

    Die Ausgabe sieht in etwa so aus:

    123456789012

  3. Gewähren Sie dem Dienst-Agent die Rolle:

    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com \
    --role=roles/container.serviceAgent \
    --condition=None

    Ersetzen Sie PROJECT_NUMBER durch Ihre Google Cloud-Projektnummer.

  4. Versuchen Sie noch einmal, die Workload Identity Federation for GKE zu aktivieren.

Nächste Schritte

Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Cloud Customer Care.