Se connecter aux projets

Cette page explique comment accéder à vos charges de travail et à vos ressources et les gérer dans Google Distributed Cloud (GDC) sous air gap. Elle décrit comment vous authentifier, générer des fichiers kubeconfig pour les ressources zonales et globales, et gérer l'inactivité des sessions. Comprendre ces processus vous permet d'accéder à vos projets et à vos charges de travail de manière sécurisée et fiable.

Cette page s'adresse aux audiences appartenant au groupe des administrateurs de plate-forme (tels que les administrateurs informatiques) ou au groupe des opérateurs d'applications (tels que les développeurs d'applications) qui souhaitent utiliser les ressources GDC. Pour en savoir plus, consultez la documentation sur les audiences pour GDC sous air gap.

Vous pouvez accéder aux charges de travail à l'aide de la console GDC, de la CLI gdcloud ou de la CLI kubectl.

Authentifier votre compte pour y accéder

Pour vous connecter à la console GDC ou à un cluster, procédez comme suit :

Console

Ouvrez l'URL suivante dans un nouvel onglet de navigateur pour accéder à l'interface utilisateur de Distributed Cloud :

https://GDC_URL

Remplacez GDC_URL par le nom de domaine que vous utilisez pour accéder à Distributed Cloud et que l'opérateur d'infrastructure (IO) vous fournit. Lorsque vous ouvrez une URL pour la première fois, Distributed Cloud vous redirige vers la page de connexion de votre fournisseur d'identité si l'opérateur d'infrastructure (IO) a configuré la page.

Par exemple, l'image suivante montre la connexion à l'interface utilisateur de la console pour une organisation nommée org-1 :

CLI

Lorsque vous vous connectez à la CLI gdcloud, utilisez la gdcloud auth login commande pour authentifier un compte principal sur la CLI gdcloud. La CLI gdcloud utilise ce compte principal pour l'authentification et l'autorisation, afin de gérer les Google Cloud ressources et les services.

Avant de vous connecter, assurez-vous d'effectuer les opérations suivantes :

• Téléchargez le binaire de la CLI gdcloud et installez-le sur votre système. Pour en savoir plus, consultez Télécharger la CLI gdcloud.
• Configurez et initialisez la configuration par défaut de la CLI gdcloud. Veillez à définir l'URL de l'organisation correcte, qui est utilisée pour récupérer le point de terminaison de configuration de connexion. Pour en savoir plus, consultez Installation de la CLI gdcloud.
• Installez le plug-in d'authentification gdcloud-k8s-auth-plugin. Pour en savoir plus, consultez Authentification de la CLI gdcloud.

Important : Exécutez les étapes suivantes sur votre système avec votre compte utilisateur et non avec le compte racine. La CLI gdcloud n'ouvre pas automatiquement de navigateur en mode racine.

Pour vous connecter à un serveur d'API Management ou à un cluster Kubernetes, procédez comme suit :

• Serveur d'API de gestion :

1. Exportez le chemin d'accès à l'emplacement où vous souhaitez stocker le fichier kubeconfig du serveur d'API Management :

   export KUBECONFIG=MANAGEMENT_API_SERVER
   

   Remplacez MANAGEMENT_API_SERVER par le chemin d'accès au répertoire dans lequel stocker le fichier kubeconfig.

2. Authentifiez votre instance de la CLI gdcloud pour vous connecter. Vous pouvez vous authentifier de deux manières :

   • Connexion standard au navigateur : utilisez ce flux d'authentification lorsque vous vous connectez à partir d'un navigateur.

     gdcloud auth login
     

   • Connexion à un appareil secondaire : utilisez ce flux d'authentification si votre appareil principal ne dispose pas d'un navigateur. Ce flux démarre la connexion sur l'appareil principal sans accès au navigateur et la poursuit sur l'appareil secondaire qui y a accès.

     Lancez la connexion sur votre appareil principal sans navigateur :

     gdcloud auth login --no-browser
     

     La variable d'environnement KUBECONFIG est mise à jour avec les fichiers kubeconfig de tous les serveurs d'API et clusters de l'organisation. Si la variable KUBECONFIG n'est pas définie, la CLI kubectl utilise le fichier kubeconfig par défaut stocké dans $HOME/.kube/config.

     Pour éviter de modifier les fichiers kubeconfig, ajoutez l'option --skip-kubeconfig-update à votre commande. Exemple :

     gdcloud auth login --no-browser --skip-kubeconfig-update
     

     Copiez le résultat de la commande de la CLI gdcloud qui s'affiche, puis exécutez-la sur une machine ayant accès à un navigateur.

3. Suivez les instructions de la page Web pour terminer le processus de connexion.

   Une fois la connexion établie, le navigateur affiche le message Authentication successful. Please close this window (Authentification réussie. Veuillez fermer cette fenêtre).

4. Suivez les instructions du terminal. Une fois la connexion établie, le terminal affiche le message suivant : You are now logged in (Vous êtes maintenant connecté).

   Remarque : Si vous voyez une erreur x509: certificate signed by unknown authority, cela signifie que votre station de travail n’approuve pas le certificat CA utilisé dans GDC. Suivez la procédure de votre organisation pour vérifier le magasin de certificats approuvés de votre station de travail.
   Avertissement : L’utilisation de --login-config-cert avec un certificat non validé vous rend vulnérable aux attaques de l’homme du milieu. Assurez-vous de ne vous fier qu'au magasin de confiance de votre station de travail au lieu d'approuver un certificat CA provenant de sources inconnues.

• Cluster Kubernetes:

1. Authentifiez votre instance de la CLI gdcloud pour vous connecter. Vous pouvez vous authentifier de deux manières :

   • Connexion standard au navigateur : utilisez ce flux d'authentification lorsque vous vous connectez à partir d'un navigateur.

     gdcloud auth login
     

   • Connexion à un appareil secondaire : utilisez ce flux d'authentification si votre appareil principal ne dispose pas d'un navigateur. Ce flux démarre la connexion sur l'appareil principal sans accès au navigateur et la poursuit sur l'appareil secondaire qui y a accès.

     1. Lancez la connexion sur votre appareil principal sans navigateur :

        gdcloud auth login --no-browser
        

        La commande de l'appareil principal affiche une autre commande gdcloud que vous devez exécuter sur l'appareil secondaire à l'étape c.

     2. Répétez l'étape 1 pour télécharger le certificat sur l'appareil secondaire.

     3. Terminez la connexion sur l'appareil secondaire en saisissant la commande affichée sur l'appareil principal à l'étape a.

   Cette action ouvre un navigateur pour vous connecter au fournisseur d'identité (IdP) configuré. Indiquez le nom d'utilisateur et le mot de passe que vous avez définis lors de la configuration initiale de la CLI gdcloud pour vous connecter.

   Remarque : Si vous voyez une erreur x509: certificate signed by unknown authority, cela signifie que votre station de travail n’approuve pas le certificat CA utilisé dans GDC. Suivez la procédure de votre organisation pour vérifier le magasin de certificats approuvés de votre station de travail.
   Avertissement : L’utilisation de --login-config-cert avec un certificat non validé vous rend vulnérable aux attaques de l’homme du milieu. Assurez-vous de ne vous fier qu'au magasin de confiance de votre station de travail au lieu d'approuver un certificat CA provenant de sources inconnues.

2. Exportez le fichier kubeconfig de votre identité utilisateur en tant que variable :

   export KUBECONFIG=/tmp/CLUSTER_NAME-ZONE-kubeconfig-with-user-identity.yaml
   

3. Générez un fichier kubeconfig pour un cluster zonal avec votre identité utilisateur :

   gdcloud clusters get-credentials CLUSTER_NAME --zone ZONE
   

   Remplacez ZONE par le nom de la zone.

   Important : L'apiserver global n'est lié à aucune zone. Exécutez donc cette commande sans l'option zone pour générer le kubeconfig de l'apiserver global : gdcloud clusters get-credentials global-api.
   Remarque : La liste des noms de cluster disponibles est disponible dans l'URL de configuration de connexion :
   https://GDC_URL/.well-known/login-config.

   Un fichier kubeconfig est généré avec votre identité utilisateur. Le fichier YAML suivant en est un exemple :

   apiVersion: v1
   clusters:
   - cluster:
     certificate-authority-data: <REDACTED>
     server: https://10.200.0.32:443
   name: cluster-name
   contexts:
   - context:
     cluster: cluster-name
     user: cluster-name-anthos-default-user
   name: cluster-name-cluster-name-anthos-default-user
   current-context: cluster-name-cluster-name-anthos-default-user
   kind: Config
   preferences: {}
   users:
   - name: cluster-name-anthos-default-user
   user:
     exec:
       apiVersion: client.authentication.k8s.io/v1
       args:
       - --audience=root-admin
       command: gdcloud-k8s-auth-plugin
       env: null
       installHint: Run 'gdcloud components install gdcloud-k8s-auth-plugin' to use plugin
       interactiveMode: Never
       provideClusterInfo: false
   

4. Pour vérifier que vous pouvez accéder au cluster, connectez-vous avec le fichier kubeconfig généré avec une identité utilisateur :

   kubectl --kubeconfig /tmp/admin-kubeconfig-with-user-identity.yaml version
   

Se déconnecter

Pour vous déconnecter de la console GDC, procédez comme suit :

Console

Cliquez sur Logout (Déconnexion) dans la barre de menu.

CLI

Déconnectez-vous de la CLI :

gdcloud auth revoke

Remarque : Toute page qui repose sur des ressources Kubernetes ne fonctionne pas. La console de débogage Chrome affiche des erreurs "forbidden" (interdit) dans les réponses. Cette erreur se produit, car l'utilisateur ne dispose d'aucune autorisation et n'est lié à aucun rôle. Pour savoir comment accorder des autorisations, consultez Accorder l'accès aux ressources.

Générer manuellement un fichier kubeconfig

Si vous gérez des ressources avec la CLI kubectl en appelant directement les API KRM, vous devez générer le fichier kubeconfig pour le cluster ou le serveur d'API qui héberge votre ressource, en fonction du type de ressource que vous gérez.

Vous devez également connaître la configuration de votre univers GDC pour déterminer les zones dans lesquelles vous comptez déployer vos ressources zonales ou le serveur d'API global pour les ressources globales. Pour en savoir plus, consultez Serveurs d'API globaux et zonaux.

Déterminez si la ressource que vous manipulez est une ressource globale ou zonale. Si vous n'êtes pas sûr, consultez la documentation dédiée à la ressource.

Effectuez la configuration applicable en fonction du type de ressource.

Ressources du serveur d'API de gestion zonale

Pour générer votre fichier kubeconfig pour le serveur d'API Management zonal, procédez comme suit :

1. Affichez toutes les zones disponibles :

   gdcloud zones list
   

   Notez le nom de la zone qui héberge votre ressource personnalisée.

2. Définissez la variable d'environnement ZONE sur la zone qui héberge vos ressources zonales :

   export ZONE="ZONE"
   

   Remplacez ZONE par le nom de la zone.

3. Définissez la variable d'environnement MANAGEMENT_API_SERVER :

   export MANAGEMENT_API_SERVER="ORG_NAME-admin"
   

   Remplacez ORG_NAME par le nom de votre organisation, par exemple org-1.

4. Générez le fichier kubeconfig du serveur d'API Management pour la zone cible et validez les identifiants :

   export KUBECONFIG=${HOME}/${MANAGEMENT_API_SERVER:?}-kubeconfig.yaml
   rm ${KUBECONFIG:?}
   gdcloud clusters get-credentials ${MANAGEMENT_API_SERVER:?} --zone ${ZONE:?}
   [[ $(kubectl config current-context) == *${MANAGEMENT_API_SERVER:?}* ]] && echo "Success. Your kubeconfig is at $KUBECONFIG" || echo "Failure"
   

   La commande rm ${KUBECONFIG:?} supprime le fichier kubeconfig existant dans le répertoire d'accueil. Lorsque vous générez un fichier kubeconfig, il remplace celui qui existe déjà. Si vous ne souhaitez pas écraser ni supprimer le fichier existant, sauvegardez-le dans un autre emplacement sécurisé.

Ressources du cluster Kubernetes zonal

Pour générer votre fichier kubeconfig pour le cluster Kubernetes zonal, procédez comme suit :

1. Affichez toutes les zones disponibles :

   gdcloud zones list
   

   Notez le nom de la zone qui héberge votre ressource personnalisée.

2. Définissez la variable d'environnement ZONE sur la zone qui héberge votre cluster Kubernetes :

   export ZONE="ZONE"
   

   Remplacez ZONE par le nom de la zone.

3. Définissez la variable d'environnement KUBERNETES_CLUSTER :

   export KUBERNETES_CLUSTER="KUBERNETES_CLUSTER_NAME"
   

   Remplacez KUBERNETES_CLUSTER_NAME par le nom de votre cluster Kubernetes.

4. Générez le fichier kubeconfig du cluster Kubernetes pour la variable de zone cible et validez les identifiants :

   export KUBECONFIG=${HOME}/${KUBERNETES_CLUSTER:?}-kubeconfig.yaml
   rm ${KUBECONFIG:?}
   gdcloud clusters get-credentials ${KUBERNETES_CLUSTER:?} --zone ${ZONE:?}
   [[ $(kubectl config current-context) == *${KUBERNETES_CLUSTER:?}* ]] && echo "Success. Your kubeconfig is at $KUBECONFIG" || echo "Failure"
   

   La commande rm ${KUBECONFIG:?} supprime le fichier kubeconfig existant dans le répertoire d'accueil. Lorsque vous générez un fichier kubeconfig, il remplace celui qui existe déjà. Si vous ne souhaitez pas écraser ni supprimer le fichier existant, sauvegardez-le dans un autre emplacement sécurisé.

Ressources du serveur d'API global

Pour générer votre fichier kubeconfig pour le serveur d'API global, procédez comme suit :

1. Définissez la variable d'environnement GLOBAL_API_SERVER :

   export GLOBAL_API_SERVER="global-api"
   

2. Générez le fichier kubeconfig du serveur d'API global et validez les identifiants :

   export KUBECONFIG=${HOME}/${GLOBAL_API_SERVER:?}-kubeconfig.yaml
   rm ${KUBECONFIG:?}
   gdcloud clusters get-credentials ${GLOBAL_API_SERVER:?}
   [[ $(kubectl config current-context) == *${GLOBAL_API_SERVER:?}* ]] && echo "Success. Your kubeconfig is at $KUBECONFIG" || echo "Failure"
   

   La commande rm ${KUBECONFIG:?} supprime le fichier kubeconfig existant dans le répertoire d'accueil. Lorsque vous générez un fichier kubeconfig, il remplace celui qui existe déjà. Si vous ne souhaitez pas écraser ni supprimer le fichier existant, sauvegardez-le dans un autre emplacement sécurisé.

Déconnexion en cas d'inactivité de la session

Après 15 minutes d'inactivité ou plus dans une session, la console GDC et la CLI gdcloud vous déconnectent. Distributed Cloud considère l'inactivité d'une session comme une période pendant une session ouverte sans engagement actif de votre part, par exemple sans mouvement du curseur ni du clavier. Une session active dure jusqu'à 12 heures avec une activité utilisateur.

Console

En cas d'inactivité de la session, la console GDC vous déconnecte. Deux minutes avant que la console GDC ne vous déconnecte pour inactivité, une boîte de dialogue s'affiche pour vous avertir de la déconnexion :

Une fois que vous êtes déconnecté pour inactivité, l'écran suivant s'affiche :

Pour vous reconnecter à la console GDC, sélectionnez votre fournisseur d'identité et ajoutez vos identifiants de connexion. Si vous utilisez un service, tel que le tableau de bord de surveillance, et que la console GDC vous déconnecte pour inactivité, reconnectez-vous pour y accéder.

gdcloud

En cas d'inactivité de la session, la CLI gdcloud vous déconnecte. Une fois que la CLI gdcloud vous a déconnecté et que vous tentez d'exécuter une commande, une erreur d'autorisation s'affiche :

Error: error when creating kube client: unable to create k8sclient: Unauthorized

Pour vous reconnecter à GDC, suivez les étapes de la CLI décrites dans Se connecter.

Si vous vous reconnectez à GDC via un serveur d'API Management, votre fichier kubeconfig est automatiquement mis à jour. Pour éviter que votre fichier kubeconfig ne soit mis à jour, utilisez l'option --skip-kubeconfig-update dans la commande gdcloud auth login.

Remarque : Les commandes qui n'effectuent pas de requêtes d'API, telles que gdcloud init et gdcloud config, ne sont pas comptabilisées dans votre activité. Lorsque vous utilisez ces commandes, la CLI gdcloud vous déconnecte quand même.

kubectl

La CLI gdcloud fait expirer vos fichiers kubeconfig après une inactivité de session. Si vous tentez d'exécuter une commande kubectl après une inactivité, une erreur d'autorisation s'affiche :

error: You must be logged in to the server (Unauthorized)

Pour vous reconnecter et utiliser votre fichier kubeconfig, suivez les étapes de la CLI décrites dans Se connecter. Pour chaque délai d'expiration de session, vous devez régénérer vos fichiers kubeconfig.