Probleme mit OIDC-Anbietern beheben

Dieses Dokument enthält Informationen zur Fehlerbehebung bei Problemen mit OIDC- und AzureAD-Identitätsanbietern in GKE Identity Service.

Falsche Formatierung des Zertifikats

Dieses Problem tritt auf, wenn der Zertifikatwert Formatierungsfehler enthält. Formatierungsprobleme können auf Zertifikatwerte zurückzuführen sein, die nicht base64-codiert sind, und auf Werte, die base64-codiert, aber falsch sind. Das Problem kann auch auftreten, wenn das Zertifikat nicht von einer Root-Zertifizierungsstelle signiert wurde oder keine korrekt formatierte Vertrauenskette angegeben ist.

Fehlermeldungen

Die folgenden Beispiele zeigen Fehlermeldungen für Szenarien, in denen das Zertifikatsformat falsch ist:

  • Zertifikat, das nicht Base64-codiert ist: Failed creating HTTP client to fetch the Discovery URI "<Discovery-document URI>" with error: Unable to decode data field, the value should be Base64 encoded

  • Zertifikat, das nicht korrekt formatiert oder Base64-codiert, aber falsch ist: Unable to connect to 'https://example.com', encountered the following error: Problem with the SSL CA cert (path? access rights?). Details: error setting certificate verify locations: CAfile: /tmp/example.pem CApath: none (The certificate could not be read, this is most likely because it's empty or contains a formatting error. Please check your configuration.)

  • Zertifikat, das nicht korrekt formatiert oder Base64-codiert, aber falsch ist: Failed fetching the Discovery URI "<Discovery-document URI>" with error: Unable to load TLS certificates.

Lösung

Sie haben folgende Möglichkeiten, die Probleme zu beheben:

  • Der Zertifikatwert, den Sie in der ClientConfig angeben, muss ein base64-codierter String und ein PEM-formatierter String sein. Weitere Informationen finden Sie unter CA-Zertifikate codieren.
  • Wenn Ihr Anbieter keine von einer Root-Zertifizierungsstelle signierten Zertifikate verwendet, müssen Sie GKE Identity Service mit einer Zertifikatsvertrauenskette konfigurieren. Weitere Informationen finden Sie unter Zwischenzertifikate.

Falscher Zertifikatwert

Dieses Problem tritt auf, wenn das Zertifikat einen nicht übereinstimmenden Wert hat. In diesem Fall ist die Formatierung der Zertifikate korrekt, sie stimmen jedoch nicht mit dem Server überein. Es kann auch darauf hinweisen, dass in der Konfiguration keine Zertifikate vorhanden waren.

Ein Zertifikatwert kann in den folgenden Szenarien als falsch betrachtet werden:

  • In der ClientConfig wird ein falscher Zertifikatwert angegeben. Ein Zertifikatwert ist falsch, wenn der issuer des Serverzertifikats nicht mit dem subject des konfigurierten Zertifikats übereinstimmt.
  • Das Zertifikat in der ClientConfig ist kein Base64-codierter String.
  • Die Zertifikatskette wird nicht bereitgestellt, wenn Zwischenzertifikate zum Ausstellen des Serverzertifikats verwendet werden.

Fehlermeldung

Die folgenden Beispiele zeigen Fehlermeldungen für Szenarien, in denen der Zertifikatwert nicht übereinstimmt:

  • Die Zertifikatskette ist nicht vollständig oder stimmt nicht mit dem Server überein: SSL peer certificate was not OK. Details: SSL certificate problem: unable to get local issuer certificate

  • Die Zertifikatskette ist nicht vollständig (entspricht einer ungültigen Teilkette, die nicht am Stamm beginnt oder nicht zusammenhängend ist): Failed fetching the Discovery URI "<Discovery-document URI>" with error: The server's TLS certificate did not match expectations.

  • Die Zertifikatkette ist gültig, stimmt aber nicht mit dem OIDC-Server überein: AIS was expecting the server to have a different certificate

  • Die Zertifikatkette ist gültig, stimmt aber nicht mit dem OIDC-Server überein: Failed fetching the Discovery URI "<Discovery-document URI>" with error: The server's TLS certificate did not match expectations.

Lösung

Der Zertifikatwert, den Sie in der ClientConfig angeben, muss eine korrekt formatierte Zertifikatkette enthalten, die mit dem Identitätsanbieter übereinstimmt. Weitere Informationen zum Formatieren und Codieren von Zertifikaten finden Sie unter CA-Zertifikate codieren.

kubectl-Befehle schlagen fehl, wenn eine kubeconfig-Datei verwendet wird, die mit dem Befehl gcloud anthos auth login generiert wurde

Wenn Sie den gcloud anthos auth login-Befehl mit OIDC auf Windows-Computern verwenden, um eine kubeconfig-Datei für den Clusterzugriff zu generieren, schlagen kubectl-Befehle möglicherweise mit der folgenden Fehlermeldung fehl: The command line is too long. Dieses Problem tritt speziell auf Windows-Systemen auf und betrifft nicht Linux-Computer, die dieselbe kubeconfig-Datei verwenden. Die zugrunde liegende Ursache hängt mit der Größe des Authentifizierungstokens zusammen, das von Azure Active Directory (Azure AD) generiert wird, wenn ein Nutzer einer großen Anzahl von Gruppen angehört (etwa 70 bis 200 Gruppen, abhängig von der Länge der Gruppennamen).

Dieses lange Token führt dazu, dass die Ausführung von kubectl-Befehlen fehlschlägt,da es die von Windows zulässige maximale Länge der Befehlszeile von 8.191 Zeichen überschreitet.

Fehlermeldung

$ kubectl --kubeconfig test-kubeconfig.yml get nodes

The command line is too long.
The command line is too long.
E0102 11:02:29.115256 24320 memcache.go:265] couldn't get current server API group list: Get "https://10.35.0.86:443/api?timeout=32s": getting credentials: exec: executable gcloud failed with exit code 1
The command line is too long.
E0102 11:02:29.350238 24320 memcache.go:265] couldn't get current server API group list: Get "https://10.35.0.86:443/api?timeout=32s": getting credentials: exec: executable gcloud failed with exit code 1
The command line is too long.
E0102 11:02:30.062811 24320 memcache.go:265] couldn't get current server API group list: Get "https://10.35.0.86:443/api?timeout=32s": getting credentials: exec: executable gcloud failed with exit code 1
Unable to connect to the server: getting credentials: exec: executable gcloud failed with exit code 1

Lösung

So beheben Sie das Problem:

  • Upgrade auf GKE-Clusterversion 1.28 oder höher

    Wenn Sie eine GKE-Clusterversion vor 1.28 verwenden, empfehlen wir Ihnen, ein Upgrade auf die unterstützte Version durchzuführen.

  • Gruppenmitgliedschaften des betroffenen Nutzers reduzieren

    Das Problem lässt sich beheben, indem Sie die Anzahl der Gruppen, denen der authentifizierende Nutzer angehört, auf unter den problematischen Schwellenwert (ca. 70 Gruppen) reduzieren.

  • Gruppenmitgliedschaften des betroffenen Nutzers erhöhen

    Die Microsoft Entra ID-Funktion hat ein Limit für die Anzahl der Gruppen, die in einem Token ausgegeben werden. Wenn Sie zwischen 70 und 200 Gruppenmitgliedschaften haben, kann es zu Authentifizierungsproblemen kommen. Sie können die Probleme mit dem Identitätsanbieter jedoch beheben, indem Sie die Anzahl der Gruppenmitgliedschaften über dieses Limit hinaus erhöhen. Aufgrund des Verhaltens dieses Limits lässt Azure AD Gruppen aus dem id_token weg, wenn die Anzahl der Mitgliedschaften zu groß wird. Dadurch wird verhindert, dass die Befehlszeile zu lang wird, und die Probleme mit dem Identitätsanbieter werden behoben. Weitere Informationen und das Limit finden Sie in der Microsoft Entra ID-Dokumentation.