Probleme mit dem Nutzerzugriff beheben

Dieses Dokument enthält Informationen zur Fehlerbehebung bei Problemen mit dem Nutzerzugriff in GKE Identity Service.

gcloud anthos create-login-config ruft clientconfig nicht ab

Dieses Problem tritt in einem der folgenden Fälle auf:

  • Die an gcloud anthos create-login-config übergebene kubeconfig-Datei ist falsch.
  • Die benutzerdefinierte Ressource „ClientConfig“ ist nicht im Cluster vorhanden (GKE Identity Service ist nicht im Cluster installiert).

Fehlermeldung

  failed to get clientconfig default in namespace kube-public

Lösung

So beheben Sie das Problem:

  1. Prüfen Sie, ob Sie die richtige kubeconfig-Datei für Ihren Cluster haben.

  2. Führen Sie den folgenden Befehl aus, um zu prüfen, ob sich die benutzerdefinierte ClientConfig-Ressource im Cluster befindet:

    kubectl --kubeconfig KUBECONFIG  get clientconfig default -n kube-public

    Wenn die ClientConfig nicht im Cluster vorhanden ist, installieren und konfigurieren Sie GKE Identity Service im Cluster. Weitere Informationen zu den Einrichtungsoptionen für Cluster finden Sie unter Einrichtungsoptionen für Cluster.

gcloud anthos create-login-config schlägt aufgrund eines doppelten Clusternamens fehl

Dieses Problem tritt auf, wenn Sie versuchen, eine Anmeldekonfiguration für einen Cluster in einer Datei zu erstellen, die bereits eine Anmeldekonfiguration für diesen Cluster enthält.

Fehlermeldung

  error merging with file FILENAME because FILENAME contains a
    cluster with the same name as the one read from KUBECONFIG.

Lösung

Verwenden Sie zum Beheben dieses Problems das Flag --output, um eine neue Zieldatei anzugeben.

Wenn Sie --output nicht angeben, werden die Konfigurationsdaten für die Anmeldung in eine Datei mit dem Namen kubectl-anthos-config.yaml im aktuellen Verzeichnis geschrieben.

gcloud anthos auth login schlägt mit proxyconnect tcp fehl

Dieses Problem tritt auf, wenn die Konfiguration der Umgebungsvariablen https_proxy oder HTTPS_PROXY fehlerhaft ist. Wenn in den Umgebungsvariablen https:// angegeben ist, können die GoLang-HTTP-Clientbibliotheken fehlschlagen, wenn der Proxy für die Verarbeitung von HTTPS-Verbindungen mit anderen Protokollen konfiguriert wird, wie etwa SOCK5.

Fehlermeldung

  proxyconnect tcp: tls: first record does not look like a TLS handshake

Lösung

Um dieses Problem zu beheben, ändern Sie die Umgebungsvariablen https_proxy und HTTPS_PROXY so, dass das https:// prefix weggelassen wird. Wenn Sie Windows verwenden, ändern Sie die Systemumgebungsvariablen. Ändern Sie beispielsweise den Wert der Umgebungsvariablen https_proxy von https://webproxy.example.com:8000 in webproxy.example.com:8000.

Clusterzugriff schlägt fehl, wenn von gcloud anthos auth login generierte kubeconfig verwendet wird

Dieses Problem tritt auf, wenn der Kubernetes API-Server den Nutzer aus einem der folgenden Gründe nicht autorisieren kann:

  • Bei der Konfiguration, die für die Anmeldung mit dem Befehl gcloud anthos auth login verwendet wird, ist ein Fehler aufgetreten.
  • Die erforderlichen RBAC-Richtlinien sind für den Nutzer falsch oder fehlen.

Fehlermeldung

  Unauthorized

Lösung

So beheben Sie das Problem:

  1. Prüfen Sie die Konfiguration, die für die Anmeldung verwendet wird.

    OIDC-Konfiguration

    Der Abschnitt authentication.oidc in der Konfigurationsdatei des Nutzerclusters enthält die Felder group und username, die verwendet werden, um die Flags --oidc-group-claim und --oidc-username-claim auf dem Kubernetes API-Server festzulegen. Wenn der API-Server das Identitätstoken eines Nutzers erhält, leitet er das Token an den GKE Identity Service weiter, der die extrahierten group-claim und username-claim an den API-Server zurückgibt. Der API-Server prüft anhand der Antwort, ob die entsprechende Gruppe oder der Nutzer über die erforderlichen Berechtigungen verfügt.

    Prüfen Sie, ob die für group und user im Abschnitt authentication.oidc der Clusterkonfigurationsdatei festgelegten Anforderungen im ID-Token vorhanden sind.

  2. Angewendete RBAC-Richtlinien prüfen.

    Informationen zum Einrichten der korrekten RBAC-Richtlinien für GKE Identity Service finden Sie unter Rollenbasierte Zugriffssteuerung (RBAC) einrichten.

RBACs für Gruppen funktionieren nicht für OIDC-Anbieter

  1. Prüfen, ob das ID-Token die Gruppeninformationen enthält

    Nachdem Sie den Befehl gcloud anthos auth login ausgeführt haben, um den OIDC-Authentifizierungsablauf zu starten, wird das ID-Token in der Datei kubeconfig im Feld id-token gespeichert. Decodieren Sie das ID-Token mit jwt.io und prüfen Sie, ob es die Gruppeninformationen des Nutzers wie erwartet enthält.

  2. Wenn das ID-Token keine Gruppeninformationen des Nutzers enthält, konfigurieren Sie den OIDC-Anbieter so, dass die Gruppeninformationen gemäß der Dokumentation Ihres OIDC-Anbieters zurückgegeben werden. Wenn Sie beispielsweise die OIDC-Konfiguration des Okta-Identitätsanbieters verwenden, folgen Sie der Dokumentation des Okta-Identitätsanbieters, um Gruppen im ID-Token zu konfigurieren.

  3. Wenn das ID-Token Gruppeninformationen enthält, prüfen Sie, ob der Schlüssel für die Gruppeninformationen im ID-Token mit dem Feld groupsClaim übereinstimmt, das im Bereich oidc konfiguriert ist.

    Wenn das ID-Token beispielsweise Gruppeninformationen im Schlüssel groups enthält:

    "groups" : ["group1", "group2" ...]

    muss der Wert des Felds groupsClaim im Abschnitt oidc groups sein.

    Nachdem Sie die Konfiguration im Abschnitt oidc geändert haben, müssen Sie die Anleitungen unter Nutzerzugriff einrichten und Auf Cluster zugreifen noch einmal ausführen.

Fehlerbehebung bei Identitätsanbietern

Wenn Sie Probleme bei der Verwendung von OIDC oder LDAP mit Ihrem GKE-Cluster haben, führen Sie die Schritte in diesem Abschnitt aus, um Probleme mit dem GKE Identity Service zu beheben und zu ermitteln, ob ein Problem mit der Konfiguration Ihres Identitätsanbieters vorliegt.

Debug-Log für GKE Identity Service aktivieren

Um Probleme mit der Identität in Ihrem Cluster zu beheben, aktivieren Sie das Debug-Log für GKE Identity Service.

  1. Patchen Sie Ihren vorhandenen Cluster mit kubectl patch:

    kubectl patch deployment ais \
  -n anthos-identity-service --type=json \
  -p='[{"op": "add", "path": "/spec/template/spec/containers/0/args/-", "value":"--vmodule=cloud/identity/hybrid/charon/*=LOG_LEVEL"}]' \
  --kubeconfig KUBECONFIG

    Ersetzen Sie Folgendes:

    • LOG_LEVEL: Für sehr ausführliche Logs legen Sie für diesen Wert bei der Fehlerbehebung auf 3 fest.

    • KUBECONFIG: Der Pfad zur Kubeconfig-Datei des Nutzerclusters.

Containerlog des GKE Identity Service prüfen

Prüfen Sie den Inhalt der Containerlogs des GKE Identity Service auf Fehler oder Warnungen.

  1. So rufen Sie die Logs mit kubectl logs auf:

    kubectl logs -f -l k8s-app=ais \
  -n anthos-identity-service \
  --kubeconfig KUBECONFIG

    Ersetzen Sie KUBECONFIG durch den Pfad der kubeconfig-Datei des Nutzerclusters.

GKE Identity Service-Pod neu starten

Wenn in den Containerlogs Probleme angezeigt werden, starten Sie den GKE Identity Service-Pod neu.

  1. Wenn Sie den GKE Identity Service-Pod neu starten möchten, löschen Sie den vorhandenen Pod. Als Ersatz wird automatisch ein neuer Pod erstellt.

    kubectl delete pod -l k8s-app=ais \
  -n anthos-identity-service \
  --kubeconfig KUBECONFIG

    Ersetzen Sie KUBECONFIG durch den Pfad der kubeconfig-Datei des Nutzerclusters.

Fehlerbehebung bei der Verbindung zum Identitätsanbieter

Wenn der GKE Identity Service-Pod anscheinend korrekt ausgeführt wird, testen Sie die Verbindung zum Remote-Identitätsanbieter.

  1. Starten Sie einen Busybox-Pod im selben Namespace wie den GKE Identity Service-Pod:

    kubectl run curl --image=radial/busyboxplus:curl \
  -n anthos-identity-service -- sleep 3000 \
  --kubeconfig KUBECONFIG

    Ersetzen Sie KUBECONFIG durch den Pfad der kubeconfig-Datei des Nutzerclusters.

  2. Wenn Sie prüfen möchten, ob Sie die Erkennungs-URL abrufen können, führen Sie den busybox-Pod und den curl-Befehl aus:

    kubectl exec pod/curl -n anthos-identity-service -- \
  curl ISSUER_URL \
  --kubeconfig KUBECONFIG

    Ersetzen Sie Folgendes:

    • ISSUER_URL: Die Aussteller-URL Ihres Identitätsanbieters.
    • KUBECONFIG: Der Pfad zur Kubeconfig-Datei des Nutzerclusters.

    Eine erfolgreiche Antwort ist ein JSON-Ergebnis mit den detaillierten Endpunkten des Identitätsanbieters.

  3. Wenn der vorherige Befehl nicht das erwartete Ergebnis zurückgibt, wenden Sie sich an den Administrator Ihres Identitätsanbieters.

LDAP-Anmeldung für Google Distributed Cloud-Administratorcluster funktioniert nicht

LDAP wird derzeit nur für Google Distributed Cloud-Nutzercluster unterstützt.