Erfahren Sie, wie Sie OpenID Connect (OIDC) in Anthos-Cluster on Bare Metal konfigurieren und Google als OpenID-Anbieter verwenden.
Einen Überblick über den "Anthos-Cluster on Bare Metal"-Authentifizierungsablauf finden Sie unter Authentifizierung. In den folgenden Themen erfahren Sie, wie Sie OIDC mit anderen OpenID-Anbietern konfigurieren:
Übersicht
Anthos-Cluster on Bare-Metal unterstützt OIDC als einen Authentifizierungsmechanismus für die Interaktion mit dem Kubernetes API-Server eines Clusters. Mit OIDC können Sie den Zugriff auf Kubernetes-Cluster verwalten und die Standardverfahren in Ihrer Organisation zum Erstellen, Aktivieren und Deaktivieren von Nutzerkonten verwenden.
Es gibt zwei Möglichkeiten, Konten zu autorisieren:
Sie können den OIDC-Ablauf mit dem Google Cloud CLI initiieren und die Nutzerautorisierung über eine browserbasierte Zustimmungsseite abrufen.
Sie initiieren den OIDC-Authentifizierungsvorgang mit der Google Cloud Console.
Hinweis
In diesem Thema wird davon ausgegangen, dass Sie mit den folgenden Authentifizierungs- und OpenID-Konzepten vertraut sind:
Der Google-OpenID-Anbieter unterstützt keine Gruppen. Wenn Sie die rollenbasierte Zugriffssteuerung von Kubernetes (Role-based Access Control, RBAC) verwenden, um authentifizierten Nutzern Rollen zuzuweisen, müssen Sie jedem einzelnen Nutzer Rollen zuweisen, nicht einer Gruppe.
Monitorlose Systeme werden nicht unterstützt. Über einen browserbasierten Authentifizierungsvorgang werden Sie zur Zustimmung aufgefordert, um dann Ihr Nutzerkonto zu autorisieren.
Zur Authentifizierung über die Google Cloud Console muss jeder Cluster, den Sie für die OIDC-Authentifizierung konfigurieren möchten, bei Google Cloud registriert sein.
Identitäten
In diesem Thema werden drei Identitäten behandelt:
Administrator der Organisation: Wählt einen OpenID-Anbieter aus und registriert Clientanwendungen beim Anbieter.
Clusteradministrator: Erstellt einen oder mehrere Cluster und Konfigurationsdateien zur Authentifizierung für Entwickler, die die Cluster verwenden.
Entwickler: Führt Arbeitslasten auf einem oder mehreren Clustern aus und verwendet OIDC zur Authentifizierung.
Weiterleitungs-URLs erstellen
Dieser Abschnitt richtet sich an Organisationsadministratoren.
Sie müssen sowohl für die gcloud CLI als auch die Google Cloud Console Weiterleitungs-URLs erstellen, mit denen der OpenID-Anbieter ID-Tokens zurückgeben kann.
gcloud-CLI-Weiterleitungs-URL
Die Google Cloud CLI ist auf dem lokalen Computer jedes Entwicklers installiert und enthält die gcloud CLI. Sie können für die Weiterleitungs-URL eine Portnummer größer als 1024 angeben:
http://localhost:[PORT]/callback
Dabei ist [PORT] Ihre Portnummer.
Geben Sie beim Konfigurieren des Google-OpenID-Anbieters http://localhost:[PORT]/callback
als eine Ihrer Weiterleitungs-URLs an.
Weiterleitungs-URL für die Google Cloud Console
Die Weiterleitungs-URL für die Google Cloud Console lautet:
https://console.cloud.google.com/kubernetes/oidc
Geben Sie beim Konfigurieren des Google-OpenID-Anbieters https://console.cloud.google.com/kubernetes/oidc
als eine Ihrer Weiterleitungs-URLs an.
Zustimmungsbildschirm konfigurieren
In diesem Abschnitt konfigurieren Sie den OAuth-Zustimmungsbildschirm von Google. Wenn ein Entwickler in Ihrer Organisation die Authentifizierung für einen Cluster startet, wird er zu diesem Zustimmungsbildschirm weitergeleitet. Er weist dann gegenüber Google seine Identität nach und erteilt Google die Berechtigung, ein Token zu erstellen, das dem OAuth-Client identifizierende Informationen bereitstellt. Im Kontext dieses Themas ist der OAuth-Client entweder die gcloud CLI oder die Google Cloud Console.
Rufen Sie in der Google Cloud Console die Seite OAuth-Zustimmungsbildschirm auf.
Wählen Sie Intern aus und klicken Sie auf Erstellen.
Wählen Sie für Anwendungstyp die Option Intern aus.
Für Name der Anwendung geben Sie einen Namen Ihrer Wahl ein. Vorschlag:
bare metal
Fügen Sie unter Autorisierte Domains
google.com
hinzu.Füllen Sie gegebenenfalls weitere Felder aus.
Klicken Sie auf Speichern.
Clientanwendung bei Google registrieren
In diesem Abschnitt registrieren Sie Anthos-Cluster on Bare Metal bei Google, sodass Google als OpenID-Anbieter für Entwickler in Ihrer Organisation fungieren kann. Im Rahmen der Registrierung müssen Sie die beiden Weiterleitungs-URLs angeben, die Sie zuvor erstellt haben.
Rufen Sie in der Google Cloud Console die Seite Anmeldedaten auf.
Klicken Sie auf Anmeldedaten erstellen und wählen Sie OAuth-Client-ID aus.
Wählen Sie als Anwendungstyp die Option Webanwendung aus.
Geben Sie unter Name einen Namen Ihrer Wahl ein.
Fügen Sie unter Autorisierte Weiterleitungs-URIs Ihre beiden Weiterleitungs-URLs ein. Sie haben eine Weiterleitungs-URL für die gloud CLI und eine Weiterleitungs-URL für die Google Cloud Console erstellt.
Klicken Sie auf Erstellen.
Sie erhalten eine Client-ID und einen Clientschlüssel. Speichern Sie sie für später.
Die oidc
-Spezifikation in der "Anthos-Cluster on Bare Metal"-Konfigurationsdatei ausfüllen
Dieser Abschnitt richtet sich an Clusteradministratoren.
Bevor Sie einen Cluster erstellen, generieren Sie mithilfe von bmctl create config
eine Konfigurationsdatei für Anthos-Cluster on Bare Metal. Die Konfiguration enthält die folgende oidc
-Spezifikation. Sie müssen für oidc
die Werte Ihres Anbieters angeben:
authentication: oidc: issuerURL: kubectlRedirectURL: clientID: clientSecret: username: usernamePrefix: group: groupPrefix: scopes: extraParams: proxy: deployCloudConsoleProxy: certificateAuthorityData:
issuerURL
: Setzen Sie dies auf"https://accounts.google.com"
. Clientanwendungen wie die gcloud CLI und die Google Cloud Console senden Autorisierungsanfragen an diese URL. Der Kubernetes API-Server nutzt diese URL, um öffentliche Schlüssel zum Verifizieren von Tokens zu ermitteln.kubectlRedirectURL
: erforderlich. Die Weiterleitungs-URL, die Sie für die gcloud CLI zuvor konfiguriert haben.clientID
: ID für die Clientanwendung, die Authentifizierungsanfragen an den OpenID-Anbieter sendet. Sowohl diegcloud
CLI als auch die Google Cloud Console nutzen diese ID. Sie haben diese ID bei der Registrierung Ihrer Clientanwendung bei Google erhalten.clientSecret
: Secret für die Clientanwendung. Sowohl die gcloud CLI als auch die Google Cloud Console nutzen dieses Secret. Sie haben diese ID bei der Registrierung Ihrer Clientanwendung bei Google erhalten.username
: Setzen Sie dies auf"email"
.usernamePrefix
: Optional Das Präfix, das Nutzernamensanforderungen vorangestellt wird, um Konflikte mit vorhandenen Namen zu vermeiden. Wenn Sie dieses Feld nicht angeben undusername
ein anderer Wert alsemail
ist, wird standardmäßig das Präfixissuerurl#
verwendet. Sie können mit dem Wert-
alle Präfixe deaktivieren.group
: Lassen Sie dieses Feld leer.groupPrefix
: Lassen Sie dieses Feld leer.scopes
: Setzen Sie dies auf"email"
.extraParams
: Setzen Sie dies auf"prompt=consent,access_type=offline"
.proxy
: Optional. Sie können gegebenenfalls einen Proxyserver angeben, der für den Cluster verwendet werden soll, um eine Verbindung zu Ihrem OIDC-Anbieter herzustellen. Beispiel:http://user:password@10.10.10.10:8888
. Bleibt das Feld leer, wird standardmäßig kein Proxy verwendet.deployCloudConsoleProxy
: Setzen Sie dies auffalse
.certificateAuthorityData
: Lassen Sie dieses Feld leer.
RBAC-Richtlinie für Ihren Cluster erstellen
Dieser Abschnitt richtet sich an Clusteradministratoren.
Nachdem Sie einen Cluster erstellt haben, verwenden Sie die rollenbasierte Zugriffssteuerung (Role-based Access Control, RBAC) von Kubernetes, um authentifizierten Clusternutzern Zugriff zu gewähren. Wenn Sie Zugriff auf Ressourcen in einem bestimmten Namespace gewähren möchten, erstellen Sie eine Role und eine RoleBinding. Wenn Sie Zugriff auf Ressourcen auf einem gesamten Cluster gewähren möchten, erstellen Sie eine ClusterRole und eine ClusterRoleBinding.
Wenn Sie Google als OpenID-Anbieter verwenden, müssen Sie Nutzern einzeln Zugriff gewähren. Gruppen können keinen Zugriff erhalten. Der Grund dafür ist, dass das Token, das der Google-OpenID-Anbieter zurückgibt, keine Informationen über die Gruppen enthält, zu denen ein einzelner Nutzer gehört.
Angenommen, Sie möchten, dass jane@example.com alle Secret-Objekte im Cluster ansehen kann.
Dies ist ein Manifest für eine ClusterRole namens secret-viewer
. Eine Person, der diese Rolle zugewiesen wurde, kann beliebige Secrets im Cluster abrufen, beobachten und auflisten.
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: secret-viewer rules: - apiGroups: [""] # The resource type for which access is granted resources: ["secrets"] # The permissions granted by the ClusterRole verbs: ["get", "watch", "list"]
Dies ist ein Manifest für eine ClusterRoleBinding namens people-who-view-secrets
. Durch die Bindung wird einem Nutzer namens jane@example.com
die Rolle secret-viewer
zugewiesen.
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: people-who-view-secrets subjects: - kind: User name: jane@example.com apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: secret-viewer apiGroup: rbac.authorization.k8s.io
Zum Erstellen der ClusterRole speichern Sie das Manifest in einer Datei mit dem Namen secret-viewer-cluster-role.yaml
und geben den folgenden Befehl ein:
kubectl --kubeconfig [CLUSTER_KUBECONFIG] apply -f secret-viewer-cluster-role.yaml
Dabei ist [CLUSTR_KUBECONFIG] die kubeconfig-Datei für Ihren Cluster.
Zum Erstellen der ClusterRoleBinding speichern Sie das Manifest in einer Datei mit dem Namen secret-viewer-cluster-role-binding.yaml
und geben den folgenden Befehl ein:
kubectl --kubeconfig [CLUSTER_KUBECONFIG] apply -f secret-viewer-cluster-role-binding.yaml
gcloud-CLI installieren
Dieser Abschnitt richtet sich sowohl an Clusteradministratoren als auch an Entwickler.
Clusteradministratoren, die Konfigurationsdateien für die Clusterauthentifizierung erstellen möchten, sowie alle Entwickler und Nutzer, die sich bei einem Cluster authentifizieren müssen, müssen das Cloud CLI auf ihrem eigenen Computer installieren. Die Anthos-Authentifizierungsbefehle wurden in die gcloud CLI als anthos-auth
-Komponente eingebunden.
Wenn Sie eine ältere Version des Anthos-Plug-ins für Kubectl verwenden, müssen Sie dieses Plug-in deinstallieren, bevor Sie die
gcloud
-Befehlszeile und die Komponenteanthos-auth
installieren.Wenn Sie eine vorhandene Version der gcloud CLI verwenden, installieren Sie die neueste Version und die Komponente
anthos-auth
.
Alte Plug-ins entfernen
Sie müssen das alte Plug-in deinstallieren, bevor Sie die Komponente anthos-auth
der gcloud CLI verwenden können. Mit dem folgenden Befehl können Sie prüfen, ob eines der bisherigen kubectl
-basierten Plug-ins auf Ihrem Computer vorhanden ist:
kubectl anthos version
Wenn der Befehl die Meldung
Error: unknown command "anthos" for "kubectl"
ausgibt, wurde kein Plug-in gefunden und Sie können mit dem nächsten Abschnitt fortfahren.Wenn die Version
1.0beta
des Plug-ins gefunden wurde, müssen Sie die Plug-in-Binärdatei suchen und löschen. Mit dem folgenden Befehl können Sie den Speicherort feststellen und anschließend die Binärdatei von Ihrem Computer entfernen:kubectl plugin list
gcloud CLI und die gcloud-Befehlszeile installieren
Installieren Sie zuerst die gcloud CLI, um die gcloud-Befehlszeile zu installieren:
Installieren Sie die gcloud CLI, aber überspringen Sie den Befehl
gcloud init
.Führen Sie die folgenden Befehle aus, um die Komponente
anthos-auth
zu installieren:gcloud components update gcloud components install anthos-auth
Führen Sie einen der folgenden Befehle aus, um zu prüfen, ob die gcloud CLI installiert wurde:
gcloud anthos auth gcloud anthos auth login
Ergebnis: Jeder Befehl sollte Details zu den erforderlichen Argumenten und verfügbaren Optionen ausgeben.
Konfigurationsdatei für die Authentifizierung erstellen und verteilen
Dieser Abschnitt richtet sich an Clusteradministratoren.
Nachdem Sie einen Cluster erstellt haben, erstellen Sie eine Authentifizierungskonfigurationsdatei für diesen Cluster. Sie können in einer einzigen Konfigurationsdatei für die Authentifizierung mehrere Cluster konfigurieren. Sie müssen die Konfigurationsdatei für die Authentifizierung dann allen Nutzern bereitstellen, die sich bei jedem dieser Cluster authentifizieren möchten.
Konfigurationsdatei für die Authentifizierung erstellen
Wenn Sie die Konfigurationsdatei für die Authentifizierung im aktuellen Verzeichnis erstellen möchten, führen Sie den folgenden gcloud
-Befehl aus:
gcloud anthos create-login-config --kubeconfig [CLUSTER_KUBECONFIG]
Dabei ist [CLUSTER_KUBECONFIG] der Pfad zur kubeconfig
-Datei Ihres Nutzerclusters. Ihre kubeconfig
-Datei wurde erstellt, als Sie Ihren Cluster mit bmctl create cluster
erstellt haben.
Ergebnis: Im aktuellen Verzeichnis wird die Konfigurationsdatei für die Authentifizierung mit dem Namen kubectl-anthos-config.yaml
erstellt.
Mehrere Cluster zur Konfigurationsdatei für die Authentifizierung hinzufügen
Sie können für mehrere Cluster die Details der Authentifizierungskonfiguration in einer einzigen Konfigurationsdatei für die Authentifizierung speichern.
Mit dem folgenden Befehl können Sie zusätzliche Details zur Clusterauthentifizierung in einer vorhandenen Konfigurationsdatei für die Authentifizierung zusammenführen. Bei einer vorhandenen Konfigurationsdatei für die Authentifizierung können Sie zusätzliche Authentifizierungsdetails für Cluster entweder mit den vorhandenen Details zusammenführen oder kombinieren:
- Führen Sie entweder die zusätzlichen Authentifizierungsdetails für Cluster mit den Details in der vorhandenen Konfigurationsdatei für die Authentifizierung zusammen
- oder kombinieren Sie die zusätzlichen Details zur Cluster-Authentifizierung mit den vorhandenen Details in einer neuen Datei.
Beispielsweise kann es sein, dass Sie die beiden Konfigurationsdateien für die Authentifizierung anthos-config-1cluster.yaml
und anthos-config-3clusters.yaml
verwalten müssen, um die Zugriffsanforderungen mehrerer Nutzergruppen in Ihrer Organisation zu erfüllen.
So fügen Sie Ihrer vorhandenen Konfigurationsdatei für die Authentifizierung zusätzliche Cluster hinzu:
Achten Sie darauf, dass jeder Cluster einen eindeutigen Namen hat. Wenn Ihre Cluster gleiche Namen haben, können ihre Details nicht in einer Konfigurationsdatei für die Authentifizierung kombiniert werden. Ein einmal erstellter Cluster kann nicht umbenannt werden.
Führen Sie den folgenden
gcloud
-Befehl aus, um Konfigurationsdetails zusammenzuführen oder zu kombinieren:gcloud anthos create-login-config --kubeconfig [CLUSTER_KUBECONFIG] \ --merge-from [IN_AUTH_CONFIG_FILE] --output [OUT_AUTH_CONFIG_FILE]
Dabei gilt:
[CLUSTER_KUBECONFIG] gibt die Datei
kubeconfig
des Clusters an, den Sie hinzufügen möchten.[IN_AUTH_CONFIG_FILE] gibt den Pfad der vorhandenen Konfigurationsdatei für die Authentifizierung an, deren Details Sie mit den zusätzlichen Clusterinformationen zusammenführen möchten.
[OUT_AUTH_CONFIG_FILE] gibt den Pfad der Datei an, in der Sie die zusammengeführte Konfiguration für die Authentifizierung speichern möchten:
- Geben Sie dieselbe Datei wie unter [IN_AUTH_CONFIG_FILE] an, wenn Sie die zusätzlichen Clusterinformationen in dieser vorhandenen Datei zusammenführen möchten.
- Geben Sie einen neuen Pfad und Dateinamen an, wenn die Details der Konfiguration für die Authentifizierung in einer neuen Datei kombiniert werden sollen.
Konfigurationsdatei für die Authentifizierung verteilen
Damit Ihre Nutzer sich bei Ihren Clustern authentifizieren können, müssen Sie ihnen Zugriff auf eine oder mehrere von Ihnen erstellte Konfigurationsdateien für die Authentifizierung gewähren. In den folgenden Schritten werden der Standarddateiname und der Standardspeicherort verwendet, die von der gcloud CLI erwartet werden. Informationen zur Verwendung alternativer Dateinamen und Speicherorte finden Sie unter Benutzerdefinierte Konfiguration.
Konfigurationsdateien für die Authentifizierung können so verteilt werden:
Durch Hosten der Datei unter einer zugänglichen URL. Wenn Sie den Befehl
gcloud anthos auth login
mit dem Flag--login-config
verwenden, ruft die gcloud CLI die Konfigurationsdatei für die Authentifizierung von diesem Speicherort ab.Durch Hosten der Datei auf einem sicheren Host. Weitere Informationen zur Verwendung von PEM-Zertifikaten für sicheren HTTPS-Zugriff finden Sie im Flag
--login-config-cert
der gcloud CLI.Durch manuelles Bereitstellen der Datei für jeden Nutzer. Wenn Nutzer die Datei heruntergeladen haben, müssen sie die Datei am Standardspeicherort und mit dem Standarddateinamen speichern, den die gcloud CLI erwartet.
Nutzer können beispielsweise mit den folgenden Befehlen die Konfigurationsdatei für die Authentifizierung mit dem Standarddateinamen
kubectl-anthos-config.yaml
am Standardspeicherort speichern:Linux
mkdir -p $HOME/.config/google/anthos/ cp [AUTH_CONFIG_FILE] $HOME/.config/google/anthos/kubectl-anthos-config.yaml
Dabei ist [AUTH_CONFIG_FILE] der Name Ihrer Konfigurationsdatei für die Authentifizierung. Beispiel:
kubectl-anthos-config.yaml
.macOS
mkdir -p $HOME/Library/Preferences/google/anthos/ cp [AUTH_CONFIG_FILE] $HOME/Library/Preferences/google/anthos/kubectl-anthos-config.yaml
Dabei ist [AUTH_CONFIG_FILE] der Name Ihrer Konfigurationsdatei für die Authentifizierung. Beispiel:
kubectl-anthos-config.yaml
.Windows
md "%APPDATA%\google\anthos" copy [AUTH_CONFIG_FILE] "%APPDATA%\google\anthos\kubectl-anthos-config.yaml"
Dabei ist [AUTH_CONFIG_FILE] der Name Ihrer Konfigurationsdatei für die Authentifizierung. Beispiel:
kubectl-anthos-config.yaml
.Übertragen Sie mit Ihren internen Tools die Konfigurationsdatei für die Authentifizierung per Push auf den Computer jedes Nutzers. Sie können beispielsweise Ihre Tools verwenden, um Dateien mit dem Standarddateinamen
kubectl-anthos-config.yaml
zu deren Standardspeicherorten auf jedem Nutzercomputer per Push zu übertragen:Linux
$HOME/.config/google/anthos/kubectl-anthos-config.yaml
macOS
$HOME/Library/Preferences/google/anthos/kubectl-anthos-config.yaml
Windows
%APPDATA%\google\anthos\kubectl-anthos-config.yaml
Benutzerdefinierte Konfiguration
Die gcloud CLI erwartet, dass die Konfigurationsdatei für die Authentifizierung am Standardspeicherort und mit dem Standarddateinamen kubectl-anthos-config.yaml
gespeichert wird, wie im vorherigen Abschnitt dargestellt. Sie haben aber die Möglichkeit, die Konfigurationsdatei für die Authentifizierung umzubenennen oder an einem anderen Speicherort zu speichern. Wenn der Name und der Speicherort der Datei vom Standard abweichen, müssen Sie das Flag --login-config
an jeden Befehl anhängen, den Sie für die Authentifizierung beim Cluster ausführen. Das zusätzliche Befehls-Flag übergibt den benutzerdefinierten Pfad und den Dateinamen.
Weitere Informationen zum Befehls-Flag finden Sie unter Über die gcloud CLI authentifizieren.
Konfigurationsdatei für die Authentifizierung abrufen
Dieser Abschnitt richtet sich an Entwickler.
Ihr Administrator ist dafür verantwortlich, dass Ihre Konfigurationsdatei für die Authentifizierung erstellt und Ihnen dann zur Verfügung gestellt wird. Weitere Informationen finden Sie unter Konfigurationsdatei für die Authentifizierung verteilen.
Standardmäßig verwendet die gcloud CLI einen Standarddateinamen und -speicherort für Ihre Konfigurationsdatei für die Authentifizierung. Wenn Ihnen die Datei manuell zur Verfügung gestellt wurde und auf Ihrem Computer gespeichert werden muss, verwenden Sie die Standardeinstellungen, um die gcloud
-Authentifizierungsbefehle zu vereinfachen.
Verwenden Sie die im Folgenden aufgeführten Befehle, um die Konfigurationsdatei für die Authentifizierung an den Standardspeicherort zu kopieren:
Linux
mkdir -p $HOME/.config/google/anthos/ cp [AUTH_CONFIG_FILE] $HOME/.config/google/anthos/kubectl-anthos-config.yaml
Dabei ist [AUTH_CONFIG_FILE] der Name Ihrer Konfigurationsdatei für die Authentifizierung. Beispiel: kubectl-anthos-config.yaml
.
macOS
mkdir -p $HOME/Library/Preferences/google/anthos/ cp [AUTH_CONFIG_FILE] $HOME/Library/Preferences/google/anthos/kubectl-anthos-config.yaml
Dabei ist [AUTH_CONFIG_FILE] der Name Ihrer Konfigurationsdatei für die Authentifizierung. Beispiel: kubectl-anthos-config.yaml
.
Windows
md "%APPDATA%\google\anthos" copy [AUTH_CONFIG_FILE] "%APPDATA%\google\anthos\kubectl-anthos-config.yaml"
Dabei ist [AUTH_CONFIG_FILE] der Name Ihrer Konfigurationsdatei für die Authentifizierung. Beispiel: kubectl-anthos-config.yaml
.
Wenn Sie einen anderen Dateinamen oder Speicherort verwenden möchten, können Sie dafür das Flag --login-config
in jede Authentifizierungsanfrage einfügen.
Weitere Informationen zur Verwendung des Befehls gcloud anthos auth login
finden Sie im folgenden Abschnitt.
Mit Clustern authentifizieren
Dieser Abschnitt richtet sich an Entwickler.
Nachdem die gcloud CLI auf Ihrem Computer installiert wurde und der Administrator Ihnen die Konfigurationsdatei für die Authentifizierung zur Verfügung gestellt hat, können Sie sich entweder über die gcloud CLI oder über die Google Cloud Console bei Ihren Clustern authentifizieren.
Über die gcloud-CLI authentifizieren
Zum Authentifizieren bei Ihren Clustern verwenden Sie gcloud
-Befehle.
Führen Sie den Befehl
gcloud anthos auth login
aus, um den Authentifizierungsvorgang zu starten:gcloud anthos auth login \ --cluster [CLUSTER_NAME] \ --user [USER_NAME] \ --login-config [AUTH_CONFIG_FILE_PATH] \ --login-config-cert [CA_CERT_PEM_FILE] \ --kubeconfig [CLUSTER_KUBECONFIG]
Dabei gilt:
[CLUSTER_NAME] (optional) den Namen des Clusters angibt. Wenn dieses Flag weggelassen wird, werden Sie aufgefordert, einen der Cluster auszuwählen, die in Ihrer Konfigurationsdatei für die Authentifizierung angegeben sind.
[USER_NAME] ist optional und gibt den Nutzernamen für die in der
kubeconfig
-Datei gespeicherten Anmeldedaten an. Der Standardwert ist[CLUSTER_NAME]-anthos-default-user
.[AUTH_CONFIG_FILE_PATH] ist optional und gibt den benutzerdefinierten Pfad oder die URL an, unter dem bzw. unter der die Konfigurationsdatei für die Authentifizierung gespeichert ist oder gehostet wird. Sie können diesen Parameter weglassen, wenn sich die Datei am Standardspeicherort befindet. Beispiel:
--login-config /path/to/custom/authentication-config.yaml
.[CA_CERT_PEM_FILE] ist optional und gibt den Pfad zu einer PEM-Zertifikatsdatei von Ihrer Zertifizierungsstelle an. Wenn Ihre Konfigurationsdatei für die Authentifizierung sicher gehostet wird, können Sie über eine HTTPS-Verbindung auf die Datei zugreifen. Beispiel:
--login-config-cert my-cert.pem
[CLUSTER_KUBECONFIG] ist optional und gibt den benutzerdefinierten Pfad zur
kubeconfig
-Datei Ihres Clusters an. Die OIDC-ID-Tokens, die von Ihrem OpenID-Anbieter zurückgegeben werden, sind in derkubeconfig
-Datei gespeichert.Verwenden Sie dieses Flag, wenn sich die
kubeconfig
-Datei nicht am Standardspeicherort befindet. Wird dieses Flag nicht angegeben, wird am Standardspeicherort eine neuekubeconfig
-Datei erstellt. Beispiel:--kubeconfig /path/to/custom.kubeconfig
.
Beispiele:
Bei einem bestimmten Cluster authentifizieren:
gcloud anthos auth login --cluster my-production-cluster
Mithilfe einer Eingabeaufforderung den Cluster für die Authentifizierung auswählen:
gcloud anthos auth login
Ergebnis:
Please use the --cluster flag to specify a cluster from the list below: Source: $HOME/.config/google/anthos/kubectl-anthos-config.yaml 1. Cluster: test-cluster ServerIP: https://192.168.0.1:6443 2. Cluster: test-cluster-2 ServerIP: https://192.168.0.2:6443 3. Cluster: my-production-cluster ServerIP: https://192.168.0.3:6443
Gehostete Konfigurationsdatei für die Authentifizierung verwenden:
gcloud anthos auth login \ --cluster my-production-cluster \ --login-config HTTPS://my-secure-server/kubectl-anthos-config.yaml \ --login-config-cert my-cert.pem
Geben Sie im browserbasierten Zustimmungsbildschirm Ihre Anmeldedaten ein.
Führen Sie einen
kubectl
-Befehl aus, um Details zu Ihrem Cluster abzurufen und zu prüfen, ob die Authentifizierung erfolgreich war. Beispiel:kubectl get nodes --kubeconfig [CLUSTER_KUBECONFIG]
Ergebnis: Die kubeconfig
-Datei enthält jetzt ein ID-Token, das von Ihren kubectl
-Befehlen zur Authentifizierung beim Kubernetes API-Server auf Ihrem Cluster verwendet wird.
SSH zur Authentifizierung von einen Remote-Computer aus verwenden
Angenommen, Sie möchten eine SSH-Verbindung zu einem Remote-Computer herstellen und sich bei einem Cluster vom Remote-Computer authentifizieren. Dazu muss sich Ihre Konfigurationsdatei für die Authentifizierung auf dem Remote-Computer befinden und Sie müssen Ihren Open-ID-Anbieter von Ihrem lokalen Computer aus erreichen können.
Führen Sie auf Ihrem lokalen Computer den folgenden Befehl aus:
ssh [USER_NAME]@[REMOTE_MACHINE] -L [LOCAL_PORT]:localhost:[REMOTE_PORT]
Dabei gilt:
[USER_NAME] und [REMOTE_MACHINE] sind die Standardwerte, die für die Anmeldung mit SSH verwendet werden.
[LOCAL_PORT] ist ein offener Port Ihrer Wahl auf Ihrem lokalen Computer, über den Sie auf den Remote-Computer zugreifen.
[REMOTE_PORT] ist der Port, den Sie für Ihre OIDC-Weiterleitungs-URL konfiguriert haben. Diesen Port finden Sie im Feld
kubectlRedirectURI
Ihrer Konfigurationsdatei für die Authentifizierung.
Führen Sie in Ihrer SSH-Shell den folgenden Befehl aus, um die Authentifizierung zu starten:
gcloud anthos auth login --login-config [AUTH_CONFIG_FILE]
Dabei ist [AUTH_CONFIG_FILE] der Pfad Ihrer Konfigurationsdatei für die Authentifizierung auf dem Remote-Computer.
Geben Sie auf Ihrem lokalen Computer in einem Browser http://localhost:[LOCAL_PORT]/login ein und schließen Sie den OIDC-Anmeldevorgang ab.
Die Datei „kubeconfig“ enthält jetzt das Token, das Sie für den Zugriff auf den Cluster benötigen.
Prüfen Sie in der SSH-Shell, ob Sie Zugriff auf den Cluster haben:
kubectl --kubeconfig [CLUSTER_KUBECONFIG] get nodes
Über die Google Cloud Console authentifizieren
Starten Sie in der Google Cloud Console den Authentifizierungsvorgang auf der Seite "Kubernetes-Cluster":
-
Öffnen Sie die Google Cloud Console.
-
Suchen Sie in der Liste Ihre "Anthos-Cluster on Bare Metal"-Cluster und klicken Sie dann auf Anmelden.
-
Wählen Sie Mit dem für den Cluster konfigurierten Identitätsanbieter authentifizieren aus und klicken Sie dann auf ANMELDEN.
Sie werden zu Ihrem Identitätsanbieter weitergeleitet. Dort müssen Sie sich möglicherweise anmelden oder dem Zugriff der Google Cloud Console auf Ihr Konto zustimmen. Anschließend werden Sie wieder zurück zur Seite Kubernetes-Cluster in der Google Cloud Console geleitet.
Fehlerbehebung bei der OIDC-Konfiguration
Prüfen Sie die folgenden Verhaltensweisen und Fehler zur Behebung von OIDC-Problemen:
- Ungültige Konfiguration
- Wenn die OIDC-Konfiguration in der Google Cloud Console nicht aus Ihrem Cluster gelesen werden kann, ist die Schaltfläche ANMELDEN deaktiviert.
- Ungültige Anbieterkonfiguration
- Wenn die Konfiguration Ihres Identitätsanbieters ungültig ist, wird nach dem Klicken auf ANMELDEN eine Fehlermeldung Ihres Identitätsanbieters angezeigt. Folgen Sie der anbieterspezifischen Anleitung, um den Anbieter oder Ihren Cluster richtig zu konfigurieren.
- Ungültige Berechtigungen
- Wenn Sie den Authentifizierungsvorgang abgeschlossen haben, die Details des Clusters aber noch nicht sichtbar sind, prüfen Sie, ob Sie dem mit OIDC verwendeten Konto die erforderlichen RBAC-Berechtigungen erteilt haben. Dieses Konto kann sich von dem Konto unterscheiden, mit dem Sie auf die Google Cloud Console zugreifen.
Error: missing 'RefreshToken' field in 'OAuth2Token' in credentials struct
- Dieser Fehler tritt möglicherweise auf, wenn der Autorisierungsserver zur Zustimmung auffordert, der erforderliche Authentifizierungsparameter jedoch nicht angegeben wurde. Geben Sie den Parameter
prompt=consent
für das Feldoidc: extraparams
der "Anthos-Cluster on Bare Metal"-Konfigurationsdatei ein und generieren Sie die Clientauthentifizierungsdatei mit dem Flag--extra-params prompt=consent
neu.