Mit einem voll qualifizierten Domainnamen (FQDN) anmelden
Mit GKE Identity Service können Sie sich über die Befehlszeile mit einem Nutzernamen und einem Passwort eines externen Identitätsanbieters in konfigurierten Clustern anmelden. Folgen Sie der Anleitung auf dieser Seite, wenn Ihr Clusteradministrator Ihnen die Möglichkeit gegeben hat, sich direkt auf dem GKE Identity Service-Server mit einem vollständig qualifizierten Domainnamen (FQDN) zu authentifizieren. Für SAML-Anbieter wird der Anmeldezugriff nur über diesen Authentifizierungsansatz unterstützt.
Dieser Authentifizierungsansatz wird nur für lokale Cluster (Google Distributed Cloud) auf VMware und Bare-Metal ab Version 1.29 unterstützt. Andere Clustertypen werden nicht unterstützt.
Die älteste gcloud
CLI-Version, mit der die Anmeldung mit dem bereitgestellten FQDN möglich ist, ist Version 477.0.0.
Anmeldeworkflow
Hier sind die Workflow-Schritte, wenn sich ein Nutzer mit dem FQDN-Zugriffsansatz anmeldet:
- Anmeldung initiieren: Der Nutzer führt den Befehl
gcloud anthos auth login --server APISERVER-URL
aus, um den Anmeldevorgang zu starten. - Auswahl des Identitätsanbieters: Der Nutzer erhält eine Liste der konfigurierten Identitätsanbieter. Der Nutzer wählt den Anbieter aus, unter dem seine Anmeldedaten gespeichert sind.
Authentifizierung über Identitätsanbieter: Der Authentifizierungsprozess unterscheidet sich je nach ausgewähltem Protokoll des Identitätsanbieters:
- OIDC: Der Nutzer wird zur Anmeldeseite des OIDC-Anbieters weitergeleitet. Nach erfolgreicher Anmeldung sendet der Anbieter einen Code an den GKE Identity Service zurück, der diesen über eine Backkanal-Kommunikation gegen ein Zugriffstoken austauscht.
- SAML: Der Nutzer wird auf die Anmeldeseite des SAML-Anbieters weitergeleitet. Nach erfolgreicher Anmeldung sendet der Anbieter ein Token (Assertion) direkt an den GKE Identity Service zurück, wodurch ein zusätzlicher Callback vermieden wird.
- LDAP: Anstatt zu einem externen Anbieter weiterzuleiten, zeigt GKE Identity Service eine Anmeldeseite an, auf der der Nutzer seine LDAP-Anmeldedaten eingibt, die direkt vom LDAP-Server geprüft werden.
Tokenprüfung und kubeconfig-Dateigenerierung: Der GKE Identity Service überprüft das empfangene Token (oder die Assertion), erstellt ein neues Token für den Nutzer und sendet eine kubeconfig-Datei zurück, die dieses Token enthält.
Clusterzugriff: Der Nutzer kann mit
kubectl
-Befehlen auf den Cluster zugreifen. Derkubectl
-Client sendet das Token aus der kubeconfig-Datei automatisch mit jeder Anfrage.Tokenvalidierung und RBAC-Autorisierung: Der Kubernetes API-Server empfängt das Token, GKE Identity Service prüft dieses Token und ruft die Anforderungen des Nutzers (Nutzername und Gruppen) ab. Nach erfolgreicher Validierung führt der API-Server die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) durch, um die Ressourcen zu bestimmen, auf die der Nutzer zugreifen darf.
Mit vertrauenswürdigen SNI-Zertifikaten anmelden
SNI-Zertifikate vereinfachen den Clusterzugriff. Dazu nutzen sie vertrauenswürdige Zertifikate, die bereits auf Unternehmensgeräten vorhanden sind. Administratoren können dieses Zertifikat bei der Clustererstellung angeben. Wenn Ihr Cluster ein vertrauenswürdiges SNI-Zertifikat auf Clusterebene verwendet, verwenden Sie den Befehl in diesem Abschnitt mit dem von Ihrem Administrator bereitgestellten FQDN, um sich beim Cluster anzumelden und ein Zugriffstoken zu erhalten. Sie können auch eine sichere kubeconfig
-Datei verwenden, in der das Token nach erfolgreicher Authentifizierung gespeichert wird.
Führen Sie den folgenden Befehl aus, um sich beim Server zu authentifizieren:
gcloud anthos auth login --server APISERVER-URL --kubeconfig OUTPUT_FILE
Ersetzen Sie Folgendes:
- APISERVER-URL: FQDN des Kubernetes API-Servers des Clusters.
- OUTPUT_FILE: Verwenden Sie dieses Flag, wenn sich die
kubeconfig
-Datei nicht am Standardspeicherort befindet. Wenn dieses Flag weggelassen wird, werden am Standardspeicherort Authentifizierungstokens zur Dateikubeconfig
hinzugefügt. Beispiel:--kubeconfig /path/to/custom.kubeconfig
.
Mit von der Zertifizierungsstelle (Certification Authority) des Clusters ausgestellten Zertifikaten anmelden
Wenn Sie kein vertrauenswürdiges SNI-Zertifikat auf Clusterebene verwenden, wird das vom Identity Service verwendete Zertifikat von der Zertifizierungsstelle (CA, Certificate Authority) des Clusters ausgestellt. Administratoren verteilen dieses CA-Zertifikat an Nutzer. Führen Sie den folgenden Befehl mit dem CA-Zertifikat des Clusters aus, um sich beim Cluster anzumelden:
gcloud anthos auth login --server APISERVER-URL --kubeconfig OUTPUT_FILE --login-config-cert CLUSTER_CA_CERTIFICATE
Geräteübergreifende Authentifizierung
Mit der geräteübergreifenden Authentifizierung können Sie sich auf Geräten, auf denen kein Browser installiert ist, in GDC-Clustern (Google Distributed Cloud) anmelden. Sie können den Authentifizierungsprozess auf Ihrem Hauptgerät (auf dem kein Browser installiert ist) starten und auf einem sekundären Gerät abschließen, auf dem ein Browser installiert ist.
Führen Sie die folgenden Schritte aus, um die geräteübergreifende Authentifizierung einzurichten.
Auf Ihrem Hauptgerät anmelden
Führen Sie den folgenden Befehl aus, um sich auf Ihrem primären Gerät beim Server zu authentifizieren. Geben Sie das Argument
--no-browser
an, um anzugeben, dass auf dem Gerät, von dem aus Sie auf Ihren Cluster zugreifen möchten, kein Browser installiert ist.gcloud anthos auth login --server APISERVER-URL --kubeconfig OUTPUT_FILE --no-browser
GKE Identity Service gibt einen Befehl zurück, den Sie verwenden müssen, wenn Sie sich über das zweite Gerät anmelden. Hier ein Beispiel für den Befehl:
You are authorizing gcloud CLI without access to a web browser. Please run the following command on a machine with a web browser and copy its output back here. gcloud auth login --server APISERVER-URL --kubeconfig OUTPUT_FILE --remote-bootstrap="URL_TO_COPY_ON_THE_SECOND_DEVICE" Enter the output of the above command:
Kopieren Sie den Befehl
gcloud
.Auf dem zweiten Gerät bei Clustern anmelden
Bevor Sie sich auf dem zweiten Gerät anmelden, prüfen Sie, ob der Browser installiert ist und eine Netzwerkverbindung zum Kubernetes API-Server besteht. Führen Sie den Befehl aus, den Sie im vorherigen Schritt kopiert haben, auf dem zweiten Gerät aus.
gcloud auth login --server APISERVER-URL --kubeconfig OUTPUT_FILE --remote-bootstrap="URL_TO_COPY_ON_THE_SECOND_DEVICE"
Wenn Sie versuchen, sich von diesem Gerät aus anzumelden, wird eine Warnmeldung angezeigt. Führen Sie die standardmäßige Authentifizierung durch, die im Browser angezeigt wird. Nach einer erfolgreichen Authentifizierung erhalten Sie einen Einmalcode. Kopieren Sie diesen Code.
WARNING: The following line enables access to your Cluster resources. ONLY COPY IT TO A MACHINE YOU TRUST AND RUN 'gcloud auth login --server APISERVER-URL --kubeconfig OUTPUT_FILE --no-browser' EARLY ON. Or_mHYQFm90efgJdwhajx0KeC_WXkuvBPuWv_83nFX9J_Eawm3tQcBpxBBWszj6Ix8dAWCgc1QjJBrlt67bzIYIBTexU7dc_ggtkMTNkG7wCIGYZ75zfg9P1gBshP33STe0ks-AoVonzk01YekMbyNugeYSO18CBwFhaDDSMABq4PI-clgbaSh8CPqrvDKRLenbvfD9BSK6SW945I0bOgPURxNzUX4sICWcvFozhQdLYICuwRM0AgarNFwoeh-0wbJGyRqUjq2NJbaYdf-VCaByiZaGPR2B1QVGXO7deKGtUnk1_tTFOnB6sJQvT6UJ8Ge5nkR38rqBeeGkYdlVIBTXShENG80An1Ve524xZupSzCHNSVTJqYg
Auf Ihrem Hauptgerät anmelden
Fügen Sie den kopierten Code aus dem vorherigen Schritt in die Eingabeaufforderung Ihres Hauptgeräts ein.
Enter the code you received on the other device: Or_mHYQFm90efgJdwhajx0KeC_WXkuvBPuWv_83nFX9J_Eawm3tQcBpxBBWszj6Ix8dAWCgc1QjJBrlt67bzIYIBTexU7dc_ggtkMTNkG7wCIGYZ75zfg9P1gBshP33STe0ks-AoVonzk01YekMbyNugeYSO18CBwFhaDDSMABq4PI-clgbaSh8CPqrvDKRLenbvfD9BSK6SW945I0bOgPURxNzUX4sICWcvFozhQdLYICuwRM0AgarNFwoeh-0wbJGyRqUjq2NJbaYdf-VCaByiZaGPR2B1QVGXO7deKGtUnk1_tTFOnB6sJQvT6UJ8Ge5nkR38rqBeeGkYdlVIBTXShENG80An1Ve524xZupSzCHNSVTJqYg
Ihr Gerät verwendet diesen Code, um Anmeldedaten zu generieren, die in einer
kubeconfig
-Datei gespeichert werden. Mit dieser Datei wird der Zugriff auf den Cluster auf Ihrem primären Gerät ermöglicht. Nach der Anmeldung wird die folgende Meldung angezeigt:You are logged in! Context is stored under the name '{cluster-name}'