Version 1.8. Diese Version wird unterstützt, wie in der Supportrichtlinie für Anthos-Versionen beschrieben. Darin sind die neuesten Patches und Updates zu Sicherheitslücken, Kontakten und Problemen mit Anthos-Clustern auf Bare-Metal aufgeführt. Weitere Informationen finden Sie in den Versionshinweisen 1.8. Eine vollständige Liste der einzelnen Neben- und Patchversionen in chronologischer Reihenfolge finden Sie in den kombinierten Versionshinweisen.

Verfügbare Versionen: 1.9  |   1.8  |   1.7

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 für Anthos-Cluster auf Bare Metal nicht funktioniert, wurde die OIDC-Spezifikation in der Cluster-Konfigurationsdatei meist nicht ordnungsgemäß konfiguriert. 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.

  1. 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
    
  2. 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.
    
  3. Wenn Sie in den Logs ein Konfigurationsproblem ermittelt haben, fahren Sie mit OIDC neu konfigurieren fort.

  4. 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.

  1. 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
    
  2. Prüfen Sie die Feldwerte, um sicherzustellen, dass die Spezifikation für Ihren OIDC-Anbieter korrekt konfiguriert ist.

  3. Wenn Sie ein Konfigurationsproblem in der Spezifikation festgestellt haben, fahren Sie mit OIDC neu konfigurieren fort.

  4. 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 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 Nein 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