Version 1.8. Cette version est compatible conformément à la politique de compatibilité avec les versions d'Anthos, en fournissant les derniers correctifs et mises à jour pour les failles de sécurité, les expositions et les problèmes affectant Anthos Clusters on VMware (GKE On-Prem). Reportez-vous aux notes de version pour plus de détails. Il ne s'agit pas de la version la plus récente.

Versions disponibles : 1.11 1.10 1.9 Versions précédentes

Cette page a été traduite par l'API Cloud Translation.

Assurer l'authentification avec OIDC et AD FS

Découvrez comment configurer Anthos Clusters on VMware (GKE On-Prem) pour utiliser OpenID Connect (OIDC) avec Active Directory Federation Services (AD FS) pour l'authentification auprès des clusters. Cette page décrit la procédure générale pour vous aider à comprendre comment configurer un serveur AD FS comme fournisseur OpenID avec Active Directory comme base de données utilisateur.

Pour obtenir une présentation du flux d'authentification de Anthos clusters on VMware, consultez la page Authentification. Pour savoir comment configurer OIDC avec d'autres fournisseurs OpenID, consultez les ressources suivantes :

Anthos clusters on VMware accepte OIDC comme l'un des mécanismes d'authentification permettant d'interagir avec le serveur d'API Kubernetes d'un cluster d'utilisateur ou d'administrateur. 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 :
Vous devez disposer d'un serveur AD FS et d'une base de données utilisateur Active Directory pour effectuer les étapes décrites dans cette section.
OIDC n'est compatible qu'avec AD FS 2016 et ses versions ultérieures.
Vous devez tenir compte des comportements suivants dans AD FS :
- Dans les versions d'AD FS antérieures à la version 5.0, l'attribut LDAP Token-Groups Qualified Names de votre base de données Active Directory est mappé sur la revendication groups. Dans la version 5.0 et les versions ultérieures, l'attribut est Token-Groups Qualified by Domain name.
- Le serveur AD FS renvoie des jetons qui incluent l'ID de l'utilisateur, l'ID de l'émetteur, la revendication openid et la revendication groups. La revendication groups (Group dans la version 5.0) répertorie les groupes de sécurité auxquels l'utilisateur appartient.
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 de ce fournisseur.
Administrateur du cluster. Cette personne crée des clusters, ainsi que des fichiers de configuration de l'authentification pour les développeurs qui les utilisent.
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

Remplacez PORT par votre numéro de port.

Lorsque vous configurez votre serveur AD FS, spécifiez http://localhost:PORT/callback comme l'un 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 votre serveur AD FS, spécifiez https://console.cloud.google.com/kubernetes/oidc comme l'un de vos URL de redirection.

Configurer AD FS

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

Configurez un serveur AD FS et une base de données d'utilisateurs Active Directory à l'aide d'un ensemble d'assistants de gestion AD FS :

Ouvrez le volet de gestion AD FS.
Sélectionnez Groupes d'applications > Actions > Ajouter un groupe d'applications.
Sélectionnez Application de serveur. Saisissez le nom et la description de votre choix. Cliquez sur Suivant.
Saisissez vos deux URL de redirection. Un ID client vous est attribué. C'est ainsi que le serveur AD FS identifie gcloud CLI et la console Google Cloud. Notez l'identifiant client pour pouvoir l'utiliser ultérieurement.
Sélectionnez Générer une clé secrète partagée. La console Google Cloud et gcloud CLI utilisent ce secret pour s'authentifier auprès du serveur AD FS. Enregistrez la clé secrète pour plus tard.

Configurer des groupes de sécurité (facultatif)

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

Dans la gestion AD FS, sélectionnez Approbations par un tiers de confiance > Ajouter une approbation par un tiers de confiance.
Sélectionnez Prise en charge des revendications, puis cliquez sur Démarrer.
Sélectionnez Saisir manuellement les données concernant le tiers de confiance.
Saisissez un nom à afficher.
Ignorez les deux étapes suivantes.
Saisissez un identifiant d'approbation par un tiers de confiance. Suggestion : token-groups-claim.
Pour Stratégie de contrôle d'accès, sélectionnez Autoriser tout le monde. Cela signifie que tous les utilisateurs partagent leurs informations de groupe de sécurité avec gcloud CLI et la console Google Cloud.
Cliquez sur Terminer.

Mapper des attributs LDAP à des noms de revendication

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

Dans la gestion AD FS, sélectionnez Approbations par des tiers de confiance > Éditer la stratégie d'émission de revendication.
Sélectionnez Envoyer les attributs LDAP en tant que revendications, puis cliquez sur Suivant.
Dans Nom de la règle de revendication, saisissez groups.
Dans Liste des attributs, sélectionnez Active Directory.
Dans la table, pour Attribut LDAP, sélectionnez :
- AD FS version 5.0 ou ultérieure : Groupes de jetons qualifiés par nom de domaine
- Versions d'AD FS antérieures à la version 5.0 : Groupes de jetons - Noms qualifiés
Dans Type de revendication sortante, sélectionnez :
- AD FS version 5.0 et ultérieure : Groupe
- Versions d'AD FS antérieures à la version 5.0 : groupes
Cliquez sur Terminer, puis sur Appliquer.

Enregistrer gcloud CLI et la console Google Cloud avec AD FS

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

Ouvrez une fenêtre PowerShell en mode Administrateur, puis entrez la commande suivante :

Grant-AdfsApplicationPermission `
     -ClientRoleIdentifier "CLIENT_ID" `
     -ServerRoleIdentifier SERVER_ROLE_IDENTIFIER `
     -ScopeName "allatclaims", "openid"

Remplacez les éléments suivants :

CLIENT_ID : ID client que vous avez obtenu précédemment.
SERVER_ROLE_IDENTIFIER : identifiant de revendication que vous avez saisi précédemment. L'identifiant suggéré était token-groups-claim.

Configurer `oidc` sur des clusters Anthos Clusters on VMware

Cette section s'adresse aux administrateurs de cluster.

Pour configurer l'authentification OIDC, vous devez configurer l'objet CRD ClientConfig de votre cluster avec les détails d'authentification associés à un cluster. Pour ce faire, modifiez l'objet KRM par défaut de type clientconfig dans l'espace de noms kube-public. Vous pouvez appliquer des configurations différentes à vos clusters d'administrateur et d'utilisateur ou utiliser la même configuration pour les deux, selon les besoins de votre entreprise.

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-public edit clientconfig default

Les détails de l'objet ClientConfig CRD permettent de configurer OIDC pour la console Google Cloud et le plug-in d'authentification pour Anthos. La configuration inclut l'information OIDC suivante :

authentication:
  - name: NAME_STRING
    oidc:
      certificateAuthorityData: CERTIFICATE_STRING
      clientID: CLIENT_ID
      clientSecret: CLIENT_SECRET
      cloudConsoleRedirectURI: "https://console.cloud.google.com/kubernetes/oidc"
      deployCloudConsoleProxy: PROXY_BOOLEAN
      extraParams: EXTRA_PARAMS
      groupsClaim: GROUPS_CLAIM
      groupPrefix: GROUP_PREFIX
      issuerURI: ISSUER_URI
      kubectlRedirectURI: KUBECTL_REDIRECT_URI
      scopes: SCOPES
      userClaim: USER_CLAIM
      userPrefix: USER_PREFIX
    proxy: PROXY_URL

Le tableau suivant décrit les champs de l'objet oidc ClientConfig CRD.

Champ	Requis	Description	Format
nom	oui	Nom de la configuration OIDC à créer.	String
certificateAuthorityData	Non	Certificat encodé au format PEM encodé en `base64` pour le fournisseur OIDC. Pour créer la chaîne, encodez le certificat, y compris les en-têtes, en `base64`. Incluez la chaîne obtenue dans `certificateAuthorityData` en tant que ligne unique. Exemple : `certificateAuthorityData: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tC...k1JSUN2RENDQWFT==`	String
clientID	Yes	ID de l'application cliente qui envoie des requêtes d'authentification au fournisseur OpenID.	String
clientSecret	Non	Secret partagé entre l'application cliente OIDC et le fournisseur OIDC.	String
extraParams	Non	Paramètres de clé-valeur supplémentaires à envoyer au fournisseur OpenID. Si vous autorisez un groupe, transmettez `resource=token-groups-claim`. Si votre serveur d'autorisation vous demande l'autorisation, pour l'authentification avec Microsoft Azure et Okta, définissez `extraParams` sur `prompt=consent`. Pour Cloud Identity, définissez `extraParams` sur `prompt=consent,access_type=offline`.	Liste d'éléments séparés par une virgule
groupsClaim	Non	Revendication JWT que le fournisseur utilise pour renvoyer vos groupes de sécurité.	String
groupPrefix	Non	Préfixe ajouté aux revendications de groupe pour éviter les conflits avec les noms existants. Par exemple, si vous avez deux groupes nommés `foobar`, ajoutez un préfixe `gid-`. Le groupe ainsi obtenu est `gid-foobar`.	String
issuerURI	Yes	URL où les requêtes d'autorisation sont envoyées à votre OpenID, telle que `https://example.com/adfs`. Le serveur de l'API Kubernetes utilise cette URL pour découvrir les clés publiques permettant de valider les jetons. L'URI doit utiliser le protocole HTTPS.	Chaîne d'URL
cloudConsoleRedirectURI	Yes	L'URL de redirection que `Google Cloud console` utilise pour l'autorisation. La valeur doit être `https://console.cloud.google.com/kubernetes/oidc`.	Chaîne d'URL
kubectlRedirectURI	Yes	L'URL de redirection que `kubectl` utilise pour l'autorisation.	Chaîne d'URL
scopes	Yes	Niveaux d'accès supplémentaires à envoyer au fournisseur OpenID. Microsoft Azure et Okta nécessitent le niveau d'accès `offline_access`.	Liste d'éléments séparés par une virgule
userClaim	Yes	Revendication JWT à utiliser comme nom d'utilisateur. Vous pouvez choisir d'autres revendications, telles que l'e-mail ou le nom, en fonction du fournisseur OpenID. Toutefois, les revendications autres que l'e-mail sont précédées de l'URL de l'émetteur pour éviter les conflits de noms.	String
userPrefix	Non	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 `userClaim` 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.	String
proxy	Non	Serveur proxy à utiliser pour la méthode `auth`, le cas échéant. Par exemple : `http://user:password@10.10.10.10:8888.`	String

Exemple : autoriser des utilisateurs et des groupes

De nombreux fournisseurs codent les propriétés d'identification des utilisateurs, telles que les e-mails et les ID utilisateur, dans un jeton. Cependant, ces propriétés présentent des risques implicites pour les stratégies d'authentification :

Les ID utilisateur peuvent compliquer la lecture et l'audit des stratégies.
Les e-mails peuvent créer un risque de disponibilité (si un utilisateur modifie son adresse e-mail principale) et éventuellement un risque de sécurité (si un e-mail peut être réattribué).

Par conséquent, il est recommandé d'utiliser des stratégies de groupe, car un ID de groupe peut être à la fois persistant et plus facile à auditer.

Supposons que votre fournisseur crée des jetons d'identité qui incluent les champs suivants :

{
  'iss': 'https://server.example.com'
  'sub': 'u98523-4509823'
  'groupList': ['developers@example.corp', 'us-east1-cluster-admins@example.corp']
  ...
}

Compte tenu de ce format de jeton, vous devez renseigner la spécification oidc de votre fichier de configuration comme suit :

issuerURL: 'https://server.example.com'
username: 'sub'
usernamePrefix: 'uid-'
group: 'groupList'
groupPrefix: 'gid-'
extraParams: 'resource=token-groups-claim'
...

Après avoir créé le cluster, vous pouvez accorder un accès privilégié aux utilisateurs authentifiés à l'aide du contrôle des accès basé sur les rôles Kubernetes (RBAC). Par exemple, vous pouvez créer un objet ClusterRole qui accorde à ses utilisateurs un accès en lecture seule aux secrets du cluster, et créer une ressource ClusterRoleBinding pour lier le rôle au groupe authentifié :

ClusterRole

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: secret-reader
rules:
- apiGroups: [""]
  # The resource type for which access is granted
  resources: ["secrets"]
  # The permissions granted by the ClusterRole
  verbs: ["get", "watch", "list"]

ClusterRoleBinding

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-secrets-admins
subjects:
  # Allows anyone in the "us-east1-cluster-admins" group to
  # read Secrets in any namespace within this cluster.
- kind: Group
  name: gid-us-east1-cluster-admins # Name is case sensitive
  apiGroup: rbac.authorization.k8s.io
  # Allows this specific user to read Secrets in any
  # namespace within this cluster
- kind: User
  name: uid-u98523-4509823
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

Notez que le serveur d'API Kubernetes traite une barre oblique inverse comme un caractère d'échappement. Par conséquent, si le nom de l'utilisateur ou du groupe contient une double barre oblique inversée (\\), le serveur d'API les lira sous la forme d'une seule \ lors de l'analyse de la valeur du champ. Pour vous assurer que le serveur d'API interprète correctement une \\ dans un champ de texte, vous devez la remplacer par \\\\. Par exemple, le serveur d'API Kubernetes analysera

"unique_name": "EXAMPLE\\\\cluster-developer" en tant que

"unique_name": "EXAMPLE\\cluster-developer"

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

Cette section s'adresse aux administrateurs de cluster.

Après avoir créé un cluster d'utilisateur, vous allez 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 gkectl suivante :

gkectl create-login-config --kubeconfig USER_CLUSTER_KUBECONFIG

Remplacez USER_CLUSTER_KUBECONFIG par le chemin d'accès au fichier kubeconfig de votre cluster d'utilisateur. Lorsque vous avez exécuté gkectl create cluster pour créer votre cluster d'utilisateur, 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 d'utilisateur 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 d'utilisateur supplémentaires :

Fusionnez les informations supplémentaires d'authentification de cluster d'utilisateur dans ce fichier de configuration d'authentification existant.
Combinez les informations supplémentaires d'authentification de cluster d'utilisateur 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 d'utilisateur supplémentaires à votre fichier de configuration d'authentification, procédez comme suit :

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é.
Exécutez la commande gkectl suivante pour fusionner ou combiner les informations de configuration :
```
gkectl create-login-config --kubeconfig USER_CLUSTER_KUBECONFIG \
--merge-from IN_AUTH_CONFIG_FILE --output OUT_AUTH_CONFIG_FILE
```
Remplacez les éléments suivants :
- USER_CLUSTER_KUBECONFIG spécifie le fichier kubeconfig du cluster d'utilisateur 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 d'utilisateur, vous devez leur donner accès à un ou plusieurs des 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.

Installer la CLI gcloud

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

Chaque développeur ou utilisateur devant s'authentifier auprès d'un cluster doit installer Google Cloud CLI sur sa propre machine. Les commandes d'authentification Anthos ont été intégrées à la CLI gcloud en tant que composant anthos-auth.

Si vous possédez une ancienne version du plug-in Anthos pour Kubectl, vous devez désinstaller ce plug-in avant d'installer gcloud CLI et le composant anthos-auth.
Si vous disposez d'une version de gcloud CLI, installez la dernière version et le 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 :

Installez gcloud CLI, mais ignorez la commande gcloud init.
Exécutez les commandes suivantes pour installer le composant anthos-auth :
```
gcloud components update
gcloud components install anthos-auth
```
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.

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 auprès de clusters d'utilisateur

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 :

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 USER_CLUSTER_KUBECONFIG
```
où :
- CLUSTER_NAME (facultatif) spécifie le nom de votre cluster d'utilisateur. Si cette option est omise, vous êtes invité à choisir parmi les clusters d'utilisateur 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
- USER_CLUSTER_KUBECONFIG (facultatif) spécifie le chemin d'accès personnalisé au fichier kubeconfig de votre cluster d'utilisateur. 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
```
Saisissez vos identifiants dans l'écran d'autorisation basé sur navigateur qui s'affiche.
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 USER_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 d'utilisateur.

S'authentifier via SSH depuis une machine distante

Supposons que vous souhaitiez vous connecter en SSH à une machine distante et vous authentifier auprès d'un cluster d'utilisateur à partir de celle-ci. 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 d'utilisateur.

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

kubectl --kubeconfig USER_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 :

Ouvrez la console Google Cloud.

Accéder à la page Clusters Kubernetes
Localisez votre cluster du service Anthos clusters on VMware dans la liste, puis cliquez sur Login (Connexion).
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 à la console Google Cloud ou l'autoriser à accéder à votre compte. Vous êtes ensuite de nouveau 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 parvient pas à lire la configuration OIDC de votre cluster, le bouton CONNEXION est 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 de Anthos clusters on VMware, puis générez à nouveau le fichier d'authentification du client avec l'option --extra-params prompt=consent.

Étapes suivantes

En savoir plus sur les champs d'application et les revendications.
En savoir plus sur les revendications personnalisées dans les jetons d'ID.

Assurer l'authentification avec OIDC et AD FS

Avant de commencer

Personas

Créer des URL de redirection

URL de redirection de la CLI gcloud

URL de redirection de la console Google Cloud

Configurer AD FS

Configurer des groupes de sécurité (facultatif)

Mapper des attributs LDAP à des noms de revendication

Enregistrer gcloud CLI et la console Google Cloud avec AD FS

Configurer oidc sur des clusters Anthos Clusters on VMware

Exemple : autoriser des utilisateurs et des groupes

ClusterRole

ClusterRoleBinding

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

Créer le fichier de configuration d'authentification

Ajouter plusieurs clusters au fichier de configuration d'authentification

Distribuer le fichier de configuration d'authentification

Linux

macOS

Windows

Linux

macOS

Windows

Configuration personnalisée

Installer la CLI gcloud

Supprimer les anciens plug-ins

Installer gcloud CLI et la CLI gcloud

Obtenir le fichier de configuration d'authentification

Linux

macOS

Windows

S'authentifier auprès de clusters d'utilisateur

S'authentifier via la CLI gcloud

S'authentifier via SSH depuis une machine distante

S'authentifier via Google Cloud Console

Résoudre les problèmes de configuration OIDC

Étapes suivantes

Configurer `oidc` sur des clusters Anthos Clusters on VMware