Se connecter à l'aide d'un nom de domaine complet (FQDN)
GKE Identity Service vous permet de vous connecter aux clusters configurés à partir de la ligne de commande à l'aide d'un nom d'utilisateur et d'un mot de passe fournis par un fournisseur d'identité tiers. Suivez les instructions de cette page si l'administrateur de votre cluster a choisi de vous autoriser à vous authentifier directement sur le serveur GKE Identity Service en utilisant un nom de domaine complet (FQDN). Pour les fournisseurs SAML, la connexion n'est possible que via cette approche d'authentification.
Cette approche d'authentification n'est compatible qu'avec les clusters sur site (Google Distributed Cloud) sur VMware et Bare Metal, à partir de la version 1.29. Les autres types de clusters ne sont pas acceptés.
La version de la CLI gcloud
requise pour vous connecter avec le FQDN fourni est au moins la version 477.0.0.
Workflow de connexion
Voici les étapes du workflow lorsqu'un utilisateur se connecte à l'aide de l'approche d'accès au FQDN :
- Lancer la connexion : l'utilisateur exécute la commande
gcloud anthos auth login --server APISERVER-URL
pour lancer le processus de connexion. - Sélection du fournisseur d'identité : l'utilisateur reçoit une liste des fournisseurs d'identité configurés. L'utilisateur sélectionne le fournisseur où ses identifiants sont stockés.
Authentification avec un fournisseur d'identité : le processus d'authentification varie en fonction du protocole de fournisseur d'identité que vous choisissez :
- OIDC : l'utilisateur est redirigé vers la page de connexion du fournisseur OIDC. Une fois la connexion réussie, le fournisseur renvoie un code à GKE Identity Service, qui l'échange contre un jeton d'accès via un canal de communication secondaire.
- SAML : l'utilisateur est redirigé vers la page de connexion du fournisseur SAML. Une fois la connexion réussie, le fournisseur renvoie directement un jeton (assertion) à GKE Identity Service, ce qui évite un rappel supplémentaire.
- LDAP : au lieu de rediriger l'utilisateur vers un fournisseur externe, GKE Identity Service affiche une page de connexion sur laquelle l'utilisateur saisit ses identifiants LDAP, qui sont vérifiés directement auprès du serveur LDAP.
Vérification du jeton et génération du fichier kubeconfig : GKE Identity Service vérifie le jeton reçu (ou l'assertion), crée un jeton pour l'utilisateur et renvoie un fichier kubeconfig contenant ce jeton.
Accès au cluster : l'utilisateur peut accéder au cluster à l'aide des commandes
kubectl
. Le clientkubectl
envoie automatiquement le jeton du fichier kubeconfig avec chaque requête.Validation du jeton et autorisation RBAC : le serveur d'API Kubernetes reçoit le jeton, GKE Identity Service le vérifie et récupère les revendications de l'utilisateur (nom d'utilisateur et groupes). Une fois la validation effectuée, le serveur d'API exécute des vérifications de contrôle des accès basé sur les rôles (RBAC) pour déterminer les ressources auxquelles l'utilisateur est autorisé à accéder.
Se connecter à l'aide de certificats SNI approuvés
Les certificats SNI simplifient l'accès aux clusters en exploitant des certificats approuvés déjà présents sur les appareils d'entreprise. Les administrateurs peuvent spécifier ce certificat au moment de la création du cluster. Si votre cluster utilise un certificat SNI de confiance au niveau du cluster, utilisez la commande de cette section avec le FQDN fourni par votre administrateur pour vous connecter au cluster et recevoir un jeton d'accès. Vous pouvez également utiliser un fichier kubeconfig
sécurisé dans lequel le jeton est stocké une fois l'authentification réussie.
Exécutez la commande suivante pour vous authentifier sur le serveur :
gcloud anthos auth login --server APISERVER-URL --kubeconfig OUTPUT_FILE
Remplacez les éléments suivants :
- APISERVER-URL : nom de domaine complet du serveur d'API Kubernetes du cluster.
- OUTPUT_FILE : utilisez cette option si votre fichier
kubeconfig
se trouve ailleurs que dans l'emplacement par défaut. Si cette option est omise, les jetons d'authentification sont ajoutés au fichierkubeconfig
à l'emplacement par défaut. Par exemple,--kubeconfig /path/to/custom.kubeconfig
.
Se connecter à l'aide de certificats émis par l'autorité de certification (CA) du cluster
Si vous n'utilisez pas de certificat SNI de confiance au niveau du cluster, le certificat utilisé par le service de gestion des identités est émis par l'autorité de certification du cluster. Les administrateurs distribuent ce certificat CA aux utilisateurs. Exécutez la commande suivante en utilisant le certificat CA du cluster pour vous connecter à votre cluster :
gcloud anthos auth login --server APISERVER-URL --kubeconfig OUTPUT_FILE --login-config-cert CLUSTER_CA_CERTIFICATE
Authentification inter-appareil
L'authentification inter-appareil vous permet de vous connecter aux clusters Google Distributed Cloud (GDC) à partir d'appareils sur lesquels aucun navigateur n'est installé. Vous pouvez lancer le processus d'authentification sur votre appareil principal (sur lequel aucun navigateur n'est installé) et le terminer sur un appareil secondaire sur lequel un navigateur est installé.
Suivez la procédure ci-dessous pour configurer l'authentification inter-appareil.
Connectez-vous à votre appareil principal.
Exécutez la commande suivante pour vous authentifier auprès du serveur sur votre appareil principal. Spécifiez l'argument
--no-browser
pour indiquer que l'appareil à partir duquel vous devez accéder à votre cluster ne dispose pas d'un navigateur installé.gcloud anthos auth login --server APISERVER-URL --kubeconfig OUTPUT_FILE --no-browser
GKE Identity Service renvoie une commande que vous devez utiliser lorsque vous vous connectez à partir du deuxième appareil. Voici un exemple de la commande :
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:
Copiez la commande
gcloud
.Se connecter aux clusters sur le deuxième appareil
Avant de vous connecter à partir du deuxième appareil, vérifiez que le navigateur est installé et que vous disposez d'une connectivité réseau au serveur d'API Kubernetes. Exécutez la commande que vous avez copiée à l'étape précédente sur le deuxième appareil.
gcloud auth login --server APISERVER-URL --kubeconfig OUTPUT_FILE --remote-bootstrap="URL_TO_COPY_ON_THE_SECOND_DEVICE"
Lorsqu'un utilisateur tente de se connecter à partir de cet appareil, un message d'avertissement s'affiche. Suivez la procédure d'authentification standard affichée dans le navigateur. Une fois l'authentification réussie, vous recevrez un code unique. Copiez ce 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
Terminer la connexion sur votre appareil principal
Collez le code copié à l'étape précédente dans l'invite de votre appareil principal.
Enter the code you received on the other device: Or_mHYQFm90efgJdwhajx0KeC_WXkuvBPuWv_83nFX9J_Eawm3tQcBpxBBWszj6Ix8dAWCgc1QjJBrlt67bzIYIBTexU7dc_ggtkMTNkG7wCIGYZ75zfg9P1gBshP33STe0ks-AoVonzk01YekMbyNugeYSO18CBwFhaDDSMABq4PI-clgbaSh8CPqrvDKRLenbvfD9BSK6SW945I0bOgPURxNzUX4sICWcvFozhQdLYICuwRM0AgarNFwoeh-0wbJGyRqUjq2NJbaYdf-VCaByiZaGPR2B1QVGXO7deKGtUnk1_tTFOnB6sJQvT6UJ8Ge5nkR38rqBeeGkYdlVIBTXShENG80An1Ve524xZupSzCHNSVTJqYg
Votre appareil utilise ce code pour générer un identifiant qui est enregistré dans un fichier
kubeconfig
. Ce fichier permet d'accéder au cluster sur votre appareil principal. Une fois connecté, le message suivant s'affiche :You are logged in! Context is stored under the name '{cluster-name}'