Probleme mit dem Nutzerzugriff beheben

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

gcloud anthos create-login-config kann clientconfig nicht abrufen

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

  • Die an gcloud anthos create-login-config übergebene kubeconfig-Datei ist falsch.
  • Die benutzerdefinierte ClientConfig-Ressource ist im Cluster nicht vorhanden (GKE Identity Service ist nicht auf dem 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 den GKE Identity Service im Cluster. Weitere Informationen zu den Optionen für die Clustereinrichtung 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, die 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:

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

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, die nicht für OIDC-Anbieter funktionieren

  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 initiieren, 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 wie erwartet die Gruppeninformationen des Nutzers 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 Identity-Anbieters verwenden, folgen Sie der Dokumentation des Okta Identity-Anbieters, um Gruppen im ID-Token zu konfigurieren.

  3. Wenn das ID-Token Gruppeninformationen enthält, prüfen Sie, ob der Gruppeninformationsschlüssel im ID-Token mit dem im Abschnitt oidc konfigurierten Feld groupsClaim übereinstimmt.

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

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

    Dann sollte der Wert des groupsClaim-Felds im Abschnitt oidc groups lauten.

    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 identitätsbezogene Probleme in Ihrem Cluster zu beheben, aktivieren Sie das Debug-Log des 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. Prüfen Sie die Logs mit kubectl logs:

    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 die Containerlogs Probleme anzeigen, starten Sie den GKE Identity Service-Pod neu.

  1. Löschen Sie den vorhandenen Pod, um den GKE Identity Service-Pod neu zu starten. 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.

Fehler bei der Verbindung zum Identitätsanbieter beheben

Wenn der GKE Identity Service-Pod scheinbar ordnungsgemäß 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: Aussteller-URL Ihres Identitätsanbieters.
    • KUBECONFIG: Der Pfad zur Kubeconfig-Datei des Nutzerclusters.

    Eine erfolgreiche Antwort ist ein JSON-Ergebnis mit den detaillierten Identitätsanbietern.

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

LDAP-Anmeldung funktioniert nicht für Anthos on VMware-Administratorcluster

LDAP wird derzeit nur für den Anthos auf VMware-Nutzercluster unterstützt.