Assurer l'authentification à l'aide d'OIDC et de Google

Découvrez comment configurer OpenID Connect (OIDC) dans les clusters Anthos sur Bare Metal et utiliser Google comme fournisseur OpenID.

Pour obtenir une présentation du flux d'authentification des clusters Anthos sur Bare Metal, consultez la page Authentification. Consultez les rubriques suivantes pour apprendre à configurer OIDC avec d'autres fournisseurs OpenID :

Présentation

Les clusters Anthos sur Bare Metal sont compatibles avec OIDC, qui fait partie des mécanismes d'authentification permettant d'interagir avec le serveur d'API Kubernetes d'un cluster. OIDC vous permet de gérer l'accès aux clusters Kubernetes en utilisant les procédures standards de votre organisation pour créer, activer et désactiver des comptes utilisateur.

Les utilisateurs peuvent autoriser leur compte de deux manières :

  • En utilisant Google Cloud CLI pour lancer le processus OIDC et obtenir l'autorisation de l'utilisateur via une page basée sur un navigateur.

  • En utilisant Google Cloud Console pour lancer le processus d'authentification OIDC.

Avant de commencer

  • Dans cet article, nous partons du principe que vous connaissez les concepts d'authentification et les concepts OpenID suivants :

  • Le fournisseur Google OpenID n'est pas compatible avec les groupes. Lorsque vous utilisez le contrôle des accès basé sur les rôles (RBAC) Kubernetes pour attribuer des rôles à des utilisateurs authentifiés, vous devez attribuer des rôles à chaque utilisateur, et non à un groupe.

  • Les systèmes sans interface graphique ne sont pas compatibles. Un processus d'authentification basé sur navigateur est utilisé pour vous demander votre autorisation et pour autoriser votre compte utilisateur.

  • Pour vous authentifier via Google Cloud Console, chaque cluster que vous souhaitez configurer pour l'authentification OIDC doit être enregistré auprès de Google Cloud.

Personas

Cette rubrique fait référence à trois personas :

  • Administrateur de l'organisation : cette personne choisit un fournisseur OpenID et enregistre les applications clientes auprès du fournisseur.

  • Administrateur de cluster : cette personne crée un ou plusieurs clusters d'utilisateur et crée des fichiers de configuration d'authentification pour les développeurs qui utilisent les clusters.

  • Développeur : cette personne exécute des charges de travail sur un ou plusieurs clusters et s'authentifie à l'aide d'OIDC.

Créer des URL de redirection

Cette section est destinée aux administrateurs de l'organisation.

Vous devez créer des URL de redirection pour gcloud CLI et la console Google Cloud que le fournisseur OpenID pourra utiliser pour renvoyer des jetons d'ID.

URL de redirection de la CLI gcloud

Google Cloud CLI est installé sur la machine locale de chaque développeur et inclut gcloud CLI. Vous pouvez spécifier un numéro de port supérieur à 1 024 pour l'URL de redirection :

http://localhost:[PORT]/callback

où [PORT] est votre numéro de port.

Lorsque vous configurez le fournisseur Google OpenID, spécifiez http://localhost:[PORT]/callback comme l'une de vos URL de redirection.

URL de redirection de la console Google Cloud

L'URL de redirection de la console Google Cloud est la suivante :

https://console.cloud.google.com/kubernetes/oidc

Lorsque vous configurez le fournisseur Google OpenID, spécifiez https://console.cloud.google.com/kubernetes/oidc comme l'une de vos URL de redirection.

Dans cette section, vous allez configurer l'écran d'autorisation OAuth de Google. Lorsqu'un développeur de votre organisation lance l'authentification auprès d'un cluster, cet écran d'autorisation s'affiche. C'est à ce niveau que l'utilisateur prouve son identité à Google et autorise Google à créer un jeton qui fournit des informations d'identification au client OAuth. Dans le contexte de cette rubrique, le client OAuth est gcloud CLI ou Google Cloud Console.

  1. Accédez à la page Écran d'autorisation OAuth dans Google Cloud Console.

    Configurer l'écran d'autorisation OAuth

  2. Sélectionnez Interne, puis cliquez sur Créer.

  3. Dans le champ Type d'application, sélectionnez Interne.

  4. Dans le champ Nom de l'application, saisissez le nom de votre choix. Suggestion : bare metal.

  5. Sous Domaines autorisés, ajoutez google.com.

  6. Renseignez les champs supplémentaires que vous jugez nécessaires.

  7. Cliquez sur Enregistrer.

Enregistrer une application cliente auprès de Google

Dans cette section, vous enregistrez les clusters Anthos sur Bare Metal avec Google, afin que Google puisse agir en tant que fournisseur OpenID pour les développeurs de votre organisation. Dans le cadre de l'enregistrement, vous devez fournir les deux URL de redirection que vous avez créées précédemment.

  1. Accédez à la page Identifiants dans Google Cloud Console.

    Accéder à la page Identifiants

  2. Cliquez sur Créer des identifiants, puis sélectionnez ID client OAuth.

  3. Dans le champ Type d'application, sélectionnez Application Web.

  4. Dans le champ Nom, saisissez le nom de votre choix.

  5. Sous URI de redirection autorisés, ajoutez vos deux URL de redirection. Rappelez-vous que vous avez créé une URL de redirection pour gcloud CLI et une URL de redirection pour Google Cloud Console.

  6. Cliquez sur Créer.

  7. Vous recevez un ID client et un code secret client. Enregistrez-les pour une utilisation ultérieure.

Remplir la spécification oidc dans le fichier de configuration des clusters Anthos sur Bare Metal

Cette section s'adresse aux administrateurs de cluster.

Avant de créer un cluster, vous devez générer un fichier de configuration de cluster Anthos sur Bare Metal à l'aide de bmctl create config. La configuration inclut la spécification oidc suivante. Vous devez remplir oidc avec les valeurs propres à votre fournisseur :

authentication:
  oidc:
    issuerURL:
    kubectlRedirectURL:
    clientID:
    clientSecret:
    username:
    usernamePrefix:
    group:
    groupPrefix:
    scopes:
    extraParams:
    proxy:
    deployCloudConsoleProxy:
    certificateAuthorityData:
  • issuerURL : définissez cette valeur sur "https://accounts.google.com". Les applications clientes, telles que la gcloud CLI et la console Google Cloud, envoient des requêtes d'autorisation à cette URL. Le serveur d'API Kubernetes utilise cette URL pour découvrir les clés publiques permettant de valider les jetons.
  • kubectlRedirectURL : valeur obligatoire. URL de redirection que vous avez configurée précédemment pour gcloud CLI.
  • clientID : ID de l'application cliente qui envoie des requêtes d'authentification au fournisseur OpenID. La gcloud CLI et la console Google Cloud utilisent cet ID. Vous avez reçu cet ID lorsque vous avez enregistré votre application cliente auprès de Google.
  • clientSecret : code secret de l'application cliente. La gcloud CLI et la console Google Cloud utilisent ce code secret. Vous avez reçu cet ID lorsque vous avez enregistré votre application cliente auprès de Google.
  • username : définissez cette valeur sur "email".
  • usernamePrefix : facultatif. Préfixe ajouté aux revendications de nom d'utilisateur pour éviter les conflits avec les noms existants. Si vous ne renseignez pas ce champ et que username est une valeur autre que email, le préfixe est défini par défaut sur issuerurl#. Vous pouvez utiliser la valeur - pour désactiver tous les préfixes.
  • group : laissez ce champ vide.
  • groupPrefix : laissez ce champ vide.
  • scopes : définissez cette valeur sur "email".
  • extraParams : définissez cette valeur sur "prompt=consent,access_type=offline".
  • proxy : facultatif. À partir de la version 1.6.1 des clusters Anthos sur Bare Metal, vous pouvez spécifier un serveur proxy à utiliser pour que le cluster se connecte à votre fournisseur OIDC, le cas échéant. Exemple : http://user:password@10.10.10.10:8888. Si vous ne renseignez pas ce champ, aucun proxy n'est utilisé.
  • deployCloudConsoleProxy : définissez cette valeur sur false.
  • certificateAuthorityData : laissez ce champ vide.

Créer une règle RBAC pour votre cluster

Cette section s'adresse aux administrateurs de cluster.

Après avoir créé un cluster, utilisez le contrôle des accès basé sur les rôles (RBAC) Kubernetes afin d'accorder l'accès aux utilisateurs authentifiés du cluster. Pour accorder l'accès aux ressources d'un espace de noms particulier, créez un Role et un RoleBinding. Pour accorder l'accès aux ressources de l'ensemble d'un cluster, créez un ClusterRole et un ClusterRoleBinding.

Lorsque vous utilisez Google en tant que fournisseur OpenID, vous devez accorder l'accès à chaque utilisateur. Vous ne pouvez pas accorder l'accès aux groupes. Cela est dû au fait que le jeton renvoyé par le fournisseur Google OpenID ne contient aucune information sur les groupes auxquels appartient un utilisateur individuel.

Par exemple, supposons que vous souhaitiez que jane@example.com puisse afficher tous les objets Secret du cluster.

Voici le fichier manifeste d'un ClusterRole nommé secret-viewer. Une personne disposant de ce rôle peut obtenir, surveiller et répertorier tous les objets Secret du cluster.

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"]

Voici le fichier manifeste d'un ClusterRoleBinding nommé people-who-view-secrets. La liaison accorde le rôle secret-viewer à un utilisateur nommé jane@example.com.

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

Pour créer le ClusterRole, enregistrez le fichier manifeste dans un fichier nommé secret-viewer-cluster-role.yaml, puis saisissez la commande suivante :

kubectl --kubeconfig [CLUSTER_KUBECONFIG] apply -f secret-viewer-cluster-role.yaml

où [CLUSTR_KUBECONFIG] représente le fichier kubeconfig de votre cluster d'utilisateur.

Pour créer le ClusterRoleBinding, enregistrez le fichier manifeste dans un fichier nommé secret-viewer-cluster-role-binding.yaml, puis saisissez la commande suivante :

kubectl --kubeconfig [CLUSTER_KUBECONFIG] apply -f secret-viewer-cluster-role-binding.yaml

Installer la CLI gcloud

Cette section s'adresse à la fois aux administrateurs de cluster et aux développeurs.

Les administrateurs de cluster qui souhaitent créer des fichiers de configuration d'authentification de cluster ainsi que chaque développeur ou utilisateur devant s'authentifier auprès d'un cluster doivent installer Google Cloud CLI sur leur machine. Les commandes d'authentification Anthos ont été intégrées à gcloud CLI en tant que composant anthos-auth.

Supprimer les anciens plug-ins

Vous devez désinstaller l'ancien plug-in pour pouvoir utiliser le composant anthos-auth de gcloud CLI. Vous pouvez vérifier si l'un des anciens plug-ins basés sur kubectl est présent sur votre machine en exécutant la commande suivante :

kubectl anthos version

  • Si la commande renvoie Error: unknown command "anthos" for "kubectl", aucun plug-in n'a été trouvé et vous pouvez passer à la section suivante.

  • Si une version 1.0beta du plug-in a été trouvée, vous devez localiser le binaire du plug-in et le supprimer. Exécutez la commande suivante pour afficher l'emplacement, puis utilisez cet emplacement pour supprimer le binaire de votre machine :

    kubectl plugin list

Installer gcloud CLI et la CLI gcloud

Pour installer gcloud CLI, vous devez d'abord installer gcloud CLI :

  1. Installez gcloud CLI, mais ignorez la commande gcloud init.

  2. Exécutez les commandes suivantes pour installer le composant anthos-auth :

    gcloud components update
gcloud components install anthos-auth

  3. Vérifiez que gcloud CLI a bien été installé en exécutant l'une des commandes suivantes :

    gcloud anthos auth
gcloud anthos auth login

    Résultat : Chaque commande doit renvoyer des informations sur les arguments requis et les options disponibles.

Créer et distribuer le fichier de configuration d'authentification

Cette section s'adresse aux administrateurs de cluster.

Après avoir créé un cluster, vous devez créer un fichier de configuration d'authentification pour ce cluster. Vous pouvez configurer plusieurs clusters dans un même fichier de configuration d'authentification. Vous devez fournir chaque fichier de configuration d'authentification aux utilisateurs qui souhaitent s'authentifier auprès de chacun de ces clusters.

Créer le fichier de configuration d'authentification

Pour créer le fichier de configuration d'authentification dans le répertoire actuel, exécutez la commande gcloud suivante :

gcloud anthos create-login-config --kubeconfig [CLUSTER_KUBECONFIG]

où [CLUSTER_KUBECONFIG] est le chemin d'accès au fichier kubeconfig de votre cluster. Lorsque vous avez exécuté bmctl create cluster pour créer votre cluster, le fichier kubeconfig a été créé.

Résultat : Votre fichier de configuration d'authentification, nommé kubectl-anthos-config.yaml, est créé dans le répertoire actuel.

Ajouter plusieurs clusters au fichier de configuration d'authentification

Vous pouvez enregistrer les détails de configuration d'authentification pour plusieurs clusters dans un seul fichier de configuration d'authentification.

Vous pouvez utiliser la commande suivante pour fusionner des informations d'authentification de cluster supplémentaires dans un fichier de configuration d'authentification existant. Avec un fichier de configuration d'authentification existant, vous pouvez fusionner ou combiner des informations d'authentification de cluster supplémentaires :

  • Fusionnez les informations supplémentaires d'authentification de cluster dans ce fichier de configuration d'authentification existant.
  • Combinez les informations supplémentaires d'authentification de cluster dans un nouveau fichier.

Par exemple, vous devrez peut-être gérer les fichiers de configuration d'authentification anthos-config-1cluster.yaml et anthos-config-3clusters.yaml pour répondre aux besoins d'accès des différents groupes d'utilisateurs de votre organisation.

Pour ajouter des clusters supplémentaires à votre fichier de configuration d'authentification existant, procédez comme suit :

  1. Assurez-vous que chaque cluster dispose d'un nom unique. Si vos clusters possèdent des noms identiques, vous ne pouvez pas les combiner dans un même fichier de configuration d'authentification. Notez qu'une fois le cluster créé, il ne peut pas être renommé.

  2. Exécutez la commande gcloud suivante pour fusionner ou combiner les informations de configuration :

    gcloud anthos create-login-config --kubeconfig [CLUSTER_KUBECONFIG] \
--merge-from [IN_AUTH_CONFIG_FILE] --output [OUT_AUTH_CONFIG_FILE]

    Où :

    • [CLUSTER_KUBECONFIG] spécifie le fichier kubeconfig du cluster que vous souhaitez ajouter.

    • [IN_AUTH_CONFIG_FILE] spécifie le chemin d'accès au fichier de configuration d'authentification existant que vous souhaitez fusionner avec les informations de cluster supplémentaires.

    • [OUT_AUTH_CONFIG_FILE] spécifie le chemin d'accès au fichier dans lequel vous souhaitez enregistrer la configuration d'authentification fusionnée :

      • Spécifiez le même fichier que [IN_AUTH_CONFIG_FILE] pour fusionner les informations de cluster supplémentaires dans ce fichier.
      • Spécifiez un nouveau chemin d'accès et un nouveau nom de fichier pour combiner les informations de configuration d'authentification dans un nouveau fichier.

Distribuer le fichier de configuration d'authentification

Pour permettre à vos utilisateurs de s'authentifier auprès de vos clusters, vous devez leur fournir un accès à un ou plusieurs fichiers de configuration d'authentification que vous avez créés. Notez que les étapes suivantes utilisent les valeurs de nom de fichier et d'emplacement par défaut attendues par gcloud CLI. Pour en savoir plus sur l'utilisation d'autres noms et emplacements de fichiers, consultez la section Configuration personnalisée.

Envisagez de distribuer les fichiers de configuration d'authentification comme suit :

  • Héberger le fichier en l'associant à une URL accessible. Si vous incluez l'option --login-config dans la commande gcloud anthos auth login, gcloud CLI obtient le fichier de configuration d'authentification à partir de cet emplacement.

    Envisagez d'héberger le fichier sur un hôte sécurisé. Pour en savoir plus sur l'utilisation de certificats PEM pour l'accès HTTPS sécurisé, consultez l'option --login-config-cert de gcloud CLI.

  • Fournir le fichier manuellement à chaque utilisateur. Une fois que les utilisateurs ont téléchargé le fichier, vous devez leur indiquer comment l'enregistrer à l'emplacement par défaut et avec le nom de fichier par défaut attendus par gcloud CLI.

    Par exemple, les utilisateurs peuvent exécuter les commandes suivantes pour stocker le fichier de configuration d'authentification en utilisant le nom de fichier kubectl-anthos-config.yaml par défaut et l'emplacement par défaut :

    Linux

    mkdir -p  $HOME/.config/google/anthos/
cp [AUTH_CONFIG_FILE] $HOME/.config/google/anthos/kubectl-anthos-config.yaml

    où [AUTH_CONFIG_FILE] est le nom de votre fichier de configuration d'authentification. Par exemple, 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

    où [AUTH_CONFIG_FILE] est le nom de votre fichier de configuration d'authentification. Par exemple, kubectl-anthos-config.yaml.

    Windows

    md "%APPDATA%\google\anthos"
copy [AUTH_CONFIG_FILE] "%APPDATA%\google\anthos\kubectl-anthos-config.yaml"

    où [AUTH_CONFIG_FILE] est le nom de votre fichier de configuration d'authentification. Par exemple, kubectl-anthos-config.yaml.

  • Utiliser vos outils internes pour transférer le fichier de configuration d'authentification sur l'ordinateur de chaque utilisateur. Par exemple, vous pouvez utiliser vos outils pour transférer des fichiers en utilisant le nom de fichier kubectl-anthos-config.yaml et l'emplacement par défaut sur la machine de chaque utilisateur :

    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

Configuration personnalisée

gcloud CLI s'attend à ce que le fichier de configuration d'authentification soit enregistré à l'emplacement par défaut et avec le nom de fichier par défaut kubectl-anthos-config.yaml, comme indiqué dans la section précédente. Toutefois, vous avez la possibilité de renommer votre fichier de configuration d'authentification ou de l'enregistrer à un autre emplacement. Si le nom et l'emplacement du fichier diffèrent de ceux par défaut, vous devez ajouter l'option --login-config à chaque commande que vous exécutez lorsque vous vous authentifiez auprès du cluster. L'option supplémentaire de commande transmet le chemin d'accès et le nom de fichier personnalisés. Pour en savoir plus sur l'option de commande, consultez la section S'authentifier via gcloud CLI.

Obtenir le fichier de configuration d'authentification

Cette section s'adresse aux développeurs.

Votre administrateur est chargé de créer votre fichier de configuration d'authentification, puis de vous le fournir. Pour en savoir plus, consultez la section Distribuer le fichier de configuration d'authentification.

Par défaut, gcloud CLI utilise un nom de fichier et un emplacement de stockage par défaut pour votre fichier de configuration d'authentification. Si vous avez reçu manuellement le fichier et que vous devez l'enregistrer sur votre ordinateur, utilisez les valeurs par défaut pour simplifier vos commandes d'authentification gcloud.

Utilisez les commandes suivantes pour copier le fichier de configuration d'authentification à l'emplacement par défaut :

Linux

mkdir -p  $HOME/.config/google/anthos/
cp [AUTH_CONFIG_FILE] $HOME/.config/google/anthos/kubectl-anthos-config.yaml

où [AUTH_CONFIG_FILE] est le nom de votre fichier de configuration d'authentification. Par exemple, 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

où [AUTH_CONFIG_FILE] est le nom de votre fichier de configuration d'authentification. Par exemple, kubectl-anthos-config.yaml.

Windows

md "%APPDATA%\google\anthos"
copy [AUTH_CONFIG_FILE] "%APPDATA%\google\anthos\kubectl-anthos-config.yaml"

où [AUTH_CONFIG_FILE] est le nom de votre fichier de configuration d'authentification. Par exemple, kubectl-anthos-config.yaml.

Si vous choisissez d'utiliser un nom de fichier ou un emplacement différent, vous avez la possibilité d'ajouter l'option --login-config à chacune de vos requêtes d'authentification. Consultez la section suivante pour en savoir plus sur l'utilisation de la commande gcloud anthos auth login.

S'authentifier avec les clusters

Cette section s'adresse aux développeurs.

Maintenant que gcloud CLI est installé sur votre ordinateur et que le fichier de configuration d'authentification vous a été fourni par votre administrateur, vous pouvez utiliser gcloud CLI ou la console Google Cloud pour vous authentifier auprès de vos clusters.

S'authentifier via la CLI gcloud

Exécutez des commandes gcloud pour vous authentifier auprès de vos clusters :

  1. Exécutez la commande gcloud anthos auth login pour lancer le processus d'authentification :

    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]

    où :

    • [CLUSTER_NAME] (facultatif) spécifie le nom de votre cluster. Si cette option est omise, vous êtes invité à choisir parmi les clusters spécifiés dans votre fichier de configuration d'authentification.

    • [USER_NAME] (facultatif) spécifie le nom d'utilisateur des identifiants enregistrés dans le fichier kubeconfig. La valeur par défaut est [CLUSTER_NAME]-anthos-default-user.

    • [AUTH_CONFIG_FILE_PATH] (facultatif) spécifie le chemin d'accès personnalisé ou l'URL de l'emplacement auquel votre fichier de configuration d'authentification est enregistré ou hébergé. Vous pouvez omettre ce paramètre si le fichier se trouve à l'emplacement par défaut. Exemple : --login-config /path/to/custom/authentication-config.yaml

    • [CA_CERT_PEM_FILE] (facultatif) spécifie le chemin d'accès à un fichier de certificat PEM de votre autorité de certification. Si votre fichier de configuration d'authentification est hébergé de manière sécurisée, vous pouvez utiliser une connexion HTTPS pour y accéder. Exemple : --login-config-cert my-cert.pem

    • [CLUSTER_KUBECONFIG] (facultatif) spécifie le chemin d'accès personnalisé au fichier kubeconfig de votre cluster. Les jetons d'ID OIDC renvoyés par votre fournisseur OpenID sont enregistrés dans le fichier kubeconfig.

      Utilisez cette option si votre fichier kubeconfig se trouve ailleurs que dans l'emplacement par défaut. Si cette option est omise, un nouveau fichier kubeconfig est créé à l'emplacement par défaut. Exemple : --kubeconfig /path/to/custom.kubeconfig

    Exemples :

    • S'authentifier auprès d'un cluster spécifique :

      gcloud anthos auth login --cluster my-production-cluster

    • Utiliser une invite pour sélectionner le cluster auprès duquel l'authentification doit s'effectuer :

      gcloud anthos auth login

      Résultat :

      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

    • Utiliser un fichier de configuration d'authentification hébergé :

      gcloud anthos auth login \
 --cluster my-production-cluster \
 --login-config HTTPS://my-secure-server/kubectl-anthos-config.yaml \
 --login-config-cert my-cert.pem

  2. Saisissez vos identifiants dans l'écran d'autorisation basé sur navigateur qui s'affiche.

  3. Vérifiez que l'authentification a réussi en exécutant l'une des commandes kubectl pour récupérer les informations concernant votre cluster. Exemple :

    kubectl get nodes --kubeconfig [CLUSTER_KUBECONFIG]

Résultat : Votre fichier kubeconfig contient désormais un jeton d'ID que vos commandes kubectl utiliseront pour s'authentifier auprès du serveur d'API Kubernetes sur votre cluster.

S'authentifier via SSH depuis une machine distante

Supposons que vous souhaitiez vous connecter en SSH à un ordinateur distant et vous authentifier auprès d'un cluster depuis cette machine distante. Pour ce faire, votre fichier de configuration d'authentification doit se trouver sur la machine distante et vous devez être en mesure d'accéder à votre fournisseur OpenID depuis votre machine locale.

Sur votre machine locale, exécutez la commande suivante :

ssh [USER_NAME]@[REMOTE_MACHINE] -L [LOCAL_PORT]:localhost:[REMOTE_PORT]

où :

  • [USER_NAME] et [REMOTE_MACHINE] sont les valeurs standards permettant de se connecter en SSH.

  • [LOCAL_PORT] est un port ouvert de votre choix sur votre machine locale que vous utiliserez pour accéder à la machine distante.

  • [REMOTE_PORT] est le port que vous avez configuré pour votre URL de redirection OIDC. Vous le trouverez dans le champ kubectlRedirectURI de votre fichier de configuration d'authentification.

Dans votre interface système SSH, exécutez la commande suivante pour lancer l'authentification :

gcloud anthos auth login --login-config [AUTH_CONFIG_FILE]

où [AUTH_CONFIG_FILE] est le chemin d'accès à votre fichier de configuration d'authentification sur la machine distante.

Sur votre ordinateur local, dans un navigateur, accédez à http://localhost:[LOCAL_PORT]/login et suivez la procédure de connexion OIDC.

Le fichier kubeconfig sur la machine distante contient maintenant le jeton dont vous avez besoin pour accéder au cluster.

Dans votre interface système SSH, vérifiez que vous avez accès au cluster :

kubectl --kubeconfig [CLUSTER_KUBECONFIG] get nodes

S'authentifier via Google Cloud Console

Démarrez le processus d'authentification sur la page des clusters Kubernetes dans la console Google Cloud :

  1. Ouvrez la console Google Cloud.

    Accéder à la page Clusters Kubernetes

  2. Localisez vos clusters Anthos sur Bare Metal dans la liste, puis cliquez sur Connexion.

  3. Sélectionnez S'authentifier auprès du fournisseur d'identité configuré pour le cluster, puis cliquez sur CONNEXION.

    Vous êtes redirigé vers votre fournisseur d'identité et il vous faudra peut-être vous connecter ou autoriser la console Google Cloud à accéder à votre compte. Vous êtes ensuite redirigé vers la page Clusters Kubernetes dans la console Google Cloud.

Résoudre les problèmes de configuration OIDC

Pour résoudre vos problèmes liés à OIDC, passez en revue les erreurs et comportements suivants :

Configuration non valide
Si Google Cloud Console ne peut pas lire la configuration OIDC de votre cluster, le bouton CONNEXION sera désactivé.
Configuration de fournisseur non valide
Si la configuration de votre fournisseur d'identité est incorrecte, un message d'erreur en provenance de votre fournisseur d'identité s'affiche lorsque vous cliquez sur CONNEXION. Suivez les instructions spécifiques au fournisseur pour configurer correctement le fournisseur ou votre cluster.
Autorisations non valides
Si vous avez suivi toute la procédure d'authentification mais que vous ne voyez toujours pas les détails du cluster, assurez-vous d'avoir accordé les autorisations RBAC appropriées au compte que vous avez utilisé avec OIDC. Notez qu'il peut s'agir d'un compte différent de celui que vous utilisez pour accéder à la console Google Cloud.
Error: missing 'RefreshToken' field in 'OAuth2Token' in credentials struct
Vous pouvez rencontrer cette erreur si le serveur d'autorisation demande votre autorisation, mais que le paramètre d'authentification requis n'a pas été fourni. Renseignez le paramètre prompt=consent dans le champ oidc: extraparams du fichier de configuration des clusters Anthos sur Bare Metal, puis générez à nouveau le fichier d'authentification du client avec l'option --extra-params prompt=consent.

Étapes suivantes