Fehlerbehebung bei OIDC in Anthos-Cluster on Bare-Metal

Auf dieser Seite wird beschrieben, wie Sie OpenID Connect-Probleme (OIDC) mit Anthos-Cluster on Bare-Metal ermitteln und beheben.

OIDC-Probleme identifizieren

Wenn OIDC nicht für Anthos-Cluster auf Bare-Metal funktioniert, liegt das in der Regel an einem Konfigurationsproblem in der OIDC-Spezifikation in der Clusterkonfigurationsdatei. In diesem Abschnitt finden Sie eine Anleitung zum Prüfen der Logs und der OIDC-Spezifikation, um die Ursache eines OIDC-Problems zu ermitteln.

Anthos Identity Service-Logs prüfen

Anthos Identity Service unterstützt OIDC in Anthos-Cluster on Bare-Metal.

Verwenden Sie kubectl logs, um die Logs von Anthos Identity Service zu drucken:

kubectl --kubeconfig CLUSTER_KUBECONFIG -n anthos-identity-service logs \
deployment/ais --all-containers=true

Prüfen Sie die Logs auf Fehler, die Ihnen bei der Diagnose von OIDC-Problemen helfen können.

Wenn Sie sich nicht mit OIDC authentifizieren können, bieten die Anthos Identity Service-Logs die relevantesten und nützlichsten Informationen zum Beheben des Problems.

Wenn die OIDC-Spezifikation (in der Clusterkonfigurationsdatei) beispielsweise im Feld issuerURL einen Tippfehler hat, z. B. htps://accounts.google.com (ein fehlendes "t" in https), enthalten die Anthos Identity Service-Logs einen Eintrag wie diesen:
```
OIDC (htps://accounts.google.com) - Unable to fetch JWKs needed to validate OIDC ID token.
```
Wenn Sie in den Logs ein Konfigurationsproblem ermittelt haben, fahren Sie mit OIDC neu konfigurieren fort.
Wenn Sie das Problem nicht selbst diagnostizieren und lösen können, wenden Sie sich an Cloud Customer Care.

Cloud Customer Care benötigt die Anthos Identity Service-Logs und die OIDC-Spezifikation, um OIDC-Probleme zu diagnostizieren und zu beheben.

OIDC-Spezifikation im Cluster prüfen

Die OIDC-Informationen für Ihren Cluster werden im clientconfig-Objekt im Namespace kube-public angegeben.

Verwenden Sie kubectl get, um die OIDC-Ressource für Ihren Cluster zu drucken:
```
kubectl --kubeconfig CLUSTER_KUBECONFIG -n kube-public get \
clientconfig.authentication.gke.io default -o yaml
```
Hinweis: Die Spezifikation clientconfig kann sich geringfügig von der OIDC-Spezifikation in der Clusterkonfigurationsdatei unterscheiden. Beispielsweise wird die URL des OIDC-Anbieters mit dem Feld issuerURL in der Clusterkonfigurationsdatei angegeben, das Objekt clientconfig gibt diese Informationen jedoch im Feld issuerURI zurück.
Prüfen Sie die Feldwerte, um sicherzustellen, dass die Spezifikation für Ihren OIDC-Anbieter korrekt konfiguriert ist.
Wenn Sie ein Konfigurationsproblem in der Spezifikation festgestellt haben, fahren Sie mit OIDC neu konfigurieren fort.
Wenn Sie das Problem nicht selbst diagnostizieren und lösen können, wenden Sie sich an Cloud Customer Care.

Cloud Customer Care benötigt die Anthos Identity Service-Logs und die OIDC-Spezifikation, um OIDC-Probleme zu diagnostizieren und zu beheben.

OIDC neu konfigurieren

Wenn Sie Probleme in den Logs von Anthos Identity Service oder im clientconfig-Objekt ermittelt haben, können Sie OIDC in Ihrem Cluster neu konfigurieren, ohne den Cluster neu zu erstellen, und die Probleme beheben. Zum Neukonfigurieren von OIDC bearbeiten Sie das KRM-Standardobjekt vom Typ clientconfig im Namespace kube-public:

kubectl --kubeconfig CLUSTER_KUBECONFIG -n kube-public edit clientconfig default

Details aus dem ClientConfig CRD werden verwendet, um OIDC für die Google Cloud Console und das Authentication Plug-in für Anthos zu konfigurieren. Weitere Details zu den OIDC-Informationen, die in der ClientConfig-CRD enthalten sind, finden Sie in der folgenden YAML-Datei und in der zugehörigen Tabelle mit Feldbeschreibungen.

authentication:
  - name: oidc
    oidc:
      certificateAuthorityData: CERTIFICATE_STRING
      clientID: CLIENT_ID
      clientSecret: CLIENT_SECRET
      cloudConsoleRedirectURI: "http://console.cloud.google.com/kubernetes/oidc"
      deployCloudConsoleProxy: PROXY_BOOLEAN
      extraParams: EXTRA_PARAMS
      groupsClaim: GROUPS_CLAIM
      groupPrefix: GROUP_PREFIX
      issuerURI: ISSUER_URI
      kubectlRedirectURI: KUBECTL_REDIRECT_URI
      scopes: SCOPES
      userClaim: USER_CLAIM
      userPrefix: USER_PREFIX
    proxy: PROXY_URL

In der folgenden Tabelle werden die Felder des ClientConfig CRD-Objekts oidc beschrieben.

Feld	Erforderlich	Beschreibung	Format
name	Ja	Der Name der zu erstellenden OIDC-Konfiguration.	String
certificateAuthorityData	Nein	Ein `base64`-codiertes PEM-codiertes Zertifikat für den OIDC-Anbieter. Codieren Sie das Zertifikat, einschließlich der Header, in `base64`, um den String zu erstellen. Fügen Sie den resultierenden String in `certificateAuthorityData` als eine Zeile ein. Beispiel: `certificateAuthorityData: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tC...k1JSUN2RENDQWFT==`	String
clientID	Ja	Die ID für die Clientanwendung, die Authentifizierungsanfragen an den OpenID-Anbieter sendet.	String
clientSecret	Nein	Gemeinsames Secret vom OIDC-Clientanwendung und OIDC-Anbieter.	String
extraParams	Nein	Zusätzliche Schlüssel/Wert-Parameter, die an den OpenID-Anbieter gesendet werden. Wenn Sie eine Gruppe autorisieren, übergeben Sie `resource=token-groups-claim`. Wenn Ihr Autorisierungsserver zur Einwilligung auffordert, legen Sie für die Authentifizierung mit Microsoft Azure und Okta `extraParams` auf `prompt=consent` fest. Legen Sie für Cloud Identity `extraParams` auf `prompt=consent,access_type=offline` fest.	Durch Kommas getrennte Liste
groupsClaim	Nein	Die JWT-Anforderung, mit der der Anbieter Ihre Sicherheitsgruppen zurückgibt.	String
groupPrefix	Nein	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`.	String
issuerURI	Ja	Die URL, über die Autorisierungsanfragen an Ihren OpenID-Anbieter gesendet werden, z. B. `https://example.com/adfs`. Der Kubernetes API-Server verwendet diese URL, um öffentliche Schlüssel zum Verifizieren von Tokens festzustellen. Für den URI muss HTTPS verwendet werden.	URL String
kubectlRedirectURI	Ja	Die Weiterleitungs-URL, die `kubectl` für die Autorisierung verwendet.	URL String
scopes	Ja	Zusätzliche Bereiche, die an den OpenID-Anbieter gesendet werden. Microsoft Azure und Okta benötigen den Bereich `offline_access`.	Durch Kommas getrennte Liste
userClaim	Ja	Die JWT-Anforderung, die als Nutzername verwendet wird. Je nach OpenID-Anbieter können Sie andere Anforderungen auswählen, beispielsweise E-Mail-Adresse oder Name. Allerdings wird anderen Anforderungen als der E-Mail-Adresse die Aussteller-URL vorangestellt, um Namenskonflikte zu vermeiden.	String
userPrefix	Nein	Das Präfix, das Nutzernamensanforderungen vorangestellt wird, um Konflikte mit vorhandenen Namen zu vermeiden.	String
proxy	Nein	Proxyserver, der ggf. für die Methode `auth` verwendet werden soll. Beispiel: `http://user:password@10.10.10.10:8888.`	String