Une fois que vous avez configuré l'authentification pour les clusters membres d'une flotte, vous pouvez 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 laisser vous authentifier directement auprès du cluster avec un nom de domaine complet (FQDN). Pour les fournisseurs SAML, l'accès à 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 compatibles.
La version de l'CLI gcloud requise pour vous connecter avec le FQDN que vous avez 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-URLpour lancer le processus de connexion. - Sélectionner un fournisseur d'identité : l'utilisateur reçoit une liste de fournisseurs d'identité configurés. Il sélectionne le fournisseur où ses identifiants sont stockés.
S'authentifier auprès du fournisseur d'identité : le processus d'authentification varie en fonction du protocole du 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 au cluster, qui l'échange contre un jeton d'accès via une communication de canal 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) au cluster, ce qui évite un rappel supplémentaire.
- LDAP : au lieu d'être redirigé vers un fournisseur externe, une page de connexion s'affiche où l'utilisateur saisit ses identifiants LDAP, qui sont vérifiés directement auprès du serveur LDAP.
Vérifier le jeton et générer le fichier kubeconfig : le cluster 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éder au cluster : l'utilisateur peut accéder au cluster à l'aide des commandes
kubectl. Le clientkubectlenvoie automatiquement le jeton du fichier kubeconfig avec chaque requête.Valider le jeton et autoriser le contrôle des accès basé sur les rôles : le serveur d'API Kubernetes reçoit le jeton, le service d'authentification le vérifie et récupère les revendications de l'utilisateur (nom d'utilisateur et groupes). Une fois la validation réussie, le serveur d'API exécute des vérifications du 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 approuvé 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 auprès du serveur :
gcloud anthos auth login --server APISERVER-URL --kubeconfig OUTPUT_FILE
Remplacez les éléments suivants :
- APISERVER-URL : FQDN du serveur d'API Kubernetes du cluster.
- OUTPUT_FILE : utilisez cette option si votre fichier
kubeconfigse 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.
Se connecter à votre appareil principal
Exécutez la commande suivante pour vous authentifier auprès du serveur sur votre appareil principal. Spécifiez l'argument
--no-browserpour 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-browserLe résultat est une commande que vous devez utiliser lorsque vous vous connectez à partir du deuxième appareil. Voici un exemple de 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"Lorsque vous tentez de vous connecter à partir de cet appareil, un message d'avertissement s'affiche. Suivez le processus d'authentification standard tel qu'il s'affiche dans le navigateur. Une fois l'authentification réussie, vous recevrez un code à usage 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_tTFOnB6sJQvT6UJ8Ge5nkR38rqBeeGkYdlVIBTXShENG80An1Ve524xZupSzCHNSVTJqYgTerminer 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_tTFOnB6sJQvT6UJ8Ge5nkR38rqBeeGkYdlVIBTXShENG80An1Ve524xZupSzCHNSVTJqYgVotre 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 que vous êtes connecté, le message suivant s'affiche :You are logged in! Context is stored under the name '{cluster-name}'