S'authentifier avec OpenID Connect (OIDC)

Cette page explique comment configurer GKE On-Prem pour utiliser un fournisseur OpenID pour l'authentification auprès des clusters d'utilisateur. Pour savoir comment utiliser OIDC avec AD FS, consultez la page Assurer l'authentification avec OIDC et AD FS. Pour savoir comment utiliser OIDC avec le fournisseur Google OpenID, consultez la page Procéder à l'authentification à l'aide d'OIDC et de Google.

Pour une présentation du processus d'authentification de GKE On-Prem, consultez la page Authentification.

Présentation

GKE On-Prem accepte OpenID Connect (OIDC) en tant que mécanisme d'authentification pour interagir avec le serveur d'API Kubernetes d'un cluster d'utilisateur. 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 d'employés.

Un employé peut utiliser le processus d'authentification OIDC de deux façons :

  • Il peut utiliser kubectl pour lancer un processus OIDC. Pour que ce processus soit automatique, GKE On-Prem fournit le plug-in Anthos pour Kubectl, un plug-in kubectl.
  • Il peut utiliser Google Cloud Console pour lancer un processus d'authentification OIDC.

Dans cet exercice, vous allez configurer les deux options : kubectl et la console Google Cloud.

Avant de commencer

Dans cette rubrique, nous partons du principe que vous connaissez bien OAuth 2.0 et OpenID Connect. Dans cette rubrique, nous partons du principe que vous connaissez bien les champs d'application et les revendications OpenID.

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.

Choisir un fournisseur OpenID

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

Vous pouvez utiliser n'importe quel fournisseur OpenID de votre choix. Pour obtenir la liste des fournisseurs certifiés, consultez la page Certification OpenID.

Une possibilité consiste à utiliser Active Directory Federated Services (ADFS) en tant que fournisseur OpenID, et utiliser une instance sur site d'Active Directory comme base de données des employés. Pour en savoir plus, consultez la page Assurer l'authentification avec OIDC et AD FS.

Il est également possible d'utiliser Google en tant que fournisseur OpenID.

Créer une URL de redirection pour le plug-in Anthos pour Kubectl

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

Dans le cadre de l'établissement d'une relation avec votre fournisseur OpenID, vous devez spécifier une URL de redirection permettant au fournisseur de renvoyer des jetons d'ID au plug-in Anthos pour Kubectl. Le plug-in Anthos pour Kubectl est exécuté sur la machine locale de chaque développeur et écoute sur le port de votre choix. Choisissez un numéro de port supérieur à 1 024 et adapté à cet usage. L'URL de redirection est alors la suivante :

http://localhost:[PORT]/callback

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

Lorsque vous configurez votre fournisseur OpenID, spécifiez http://localhost:[PORT]/callback comme l'une de vos URL de redirection. La procédure à suivre pour cela dépend de votre fournisseur.

Configurer une URL de redirection pour la console Google Cloud

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

En plus de disposer d'une URL de redirection pour kubectl, vous avez besoin d'une URL de redirection pour 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 fournisseur OIDC, spécifiez https://console.cloud.google.com/kubernetes/oidc comme URL de redirection. La procédure à suivre pour cela dépend de votre fournisseur.

Enregistrer des applications clientes auprès du fournisseur OpenID

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

Pour que vos développeurs puissent utiliser le plug-in Anthos pour Kubectl ou la console Google Cloud avec votre fournisseur OpenID, vous devez enregistrer ces deux clients auprès du fournisseur OpenID. L'enregistrement comprend les étapes suivantes :

  • Découvrir l'URI d'émetteur du fournisseur. C'est là que le plug-in Anthos pour Kubectl ou la console Google Cloud envoie des requêtes d'authentification.

  • Indiquer au fournisseur l'URL de redirection du plug-in Anthos pour Kubectl.

  • Indiquer au fournisseur l'URL de redirection de la console Google Cloud. Il s'agit de https://console.cloud.google.com/kubernetes/oidc.

  • Établir un ID client unique. Il s'agit de l'ID utilisé par le fournisseur pour identifier à la fois le plug-in Anthos pour Kubectl et la console Google Cloud.

  • Établir un code secret de client unique. Le plug-in Anthos pour Kubectl et la console Google Cloud utilisent tous deux ce code secret pour s'authentifier auprès du fournisseur OpenID.

  • Établir un champ d'application personnalisé que le plug-in Anthos pour Kubectl ou la console Google Cloud peut utiliser pour demander les groupes de sécurité de l'utilisateur.

  • Établir un nom de revendication personnalisé que le fournisseur utilisera pour renvoyer les groupes de sécurité de l'utilisateur.

La procédure à suivre dépend de votre fournisseur OpenID. Pour savoir comment procéder à l'enregistrement avec AD FS, consultez la page Assurer l'authentification avec OIDC et AD FS.

Remplir la spécification oidc dans le fichier de configuration GKE On-Prem

Cette section s'adresse aux administrateurs de cluster.

Avant de créer un cluster d'utilisateur, générez un fichier de configuration GKE On-Prem avec gkectl create-config. La configuration inclut la spécification oidc suivante. Renseignez oidc avec des valeurs propres à votre fournisseur :

oidc:
  issuerurl:
  kubectlredirecturl:
  clientid:
  clientsecret:
  username:
  usernameprefix:
  group:
  groupprefix:
  scopes:
  extraparams:
  usehttpproxy:
  capath:
  • issuerurl : valeur obligatoire. URL de votre fournisseur OpenID, telle que "https://example.com/adfs". Les applications clientes, telles que le plug-in Anthos pour Kubectl et la console Google Cloud, envoient des demandes d'autorisation à cette URL. Le serveur d'API Kubernetes utilise cette URL pour découvrir des clés publiques permettant de valider les jetons. Vous devez utiliser HTTPS.
  • kubectlredirecturl: valeur obligatoire. URL de redirection configurée précédemment pour le plug-in Anthos pour Kubectl.
  • clientid : valeur obligatoire. ID de l'application cliente qui envoie des requêtes d'authentification au fournisseur OpenID. Le plug-in Anthos pour Kubectl et la console Google Cloud utilisent cet ID.
  • clientsecret : facultatif. Code secret de l'application cliente. Le plug-in Anthos pour Kubectl et la console Google Cloud utilisent ce code secret.
  • username : facultatif. Revendication JWT à utiliser comme nom d'utilisateur. La valeur par défaut est sub, qui est censé être un identifiant unique de l'utilisateur final. Vous pouvez choisir d'autres revendications, telles que email ou name, en fonction du fournisseur OpenID. Toutefois, les revendications autres que email sont précédées de l'URL de l'émetteur afin d'éviter les conflits de noms avec d'autres plug-ins.
  • 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 : facultatif. Revendication JWT que le fournisseur utilisera pour renvoyer vos groupes de sécurité.
  • groupprefix : facultatif. Préfixe ajouté aux revendications de groupe pour éviter les conflits avec les noms existants. Par exemple, pour un groupe foobar et un préfixe gid- donnés, gid-foobar. Par défaut, cette valeur est vide et il n'y a pas de préfixe.
  • scopes : facultatif. Champs d'application supplémentaires à envoyer au fournisseur OpenID sous forme de liste délimitée par des virgules.
    • Pour l'authentification avec Microsoft Azure ou Okta, transmettez offline_access.

  • extraparams : facultatif. Paramètres de clé-valeur supplémentaires à envoyer au fournisseur OpenID sous forme de liste délimitée par des virgules.
  • usehttpproxy : facultatif. Spécifie si un proxy inverse doit être déployé dans le cluster pour permettre à Google Cloud Console d'accéder au fournisseur OIDC sur site afin d'authentifier les utilisateurs. La valeur doit être une chaîne : "true" ou "false". Si votre fournisseur d'identité n'est pas accessible sur l'Internet public et que vous souhaitez vous authentifier à l'aide de Google Cloud Console, ce champ doit être défini sur "true". Si ce champ n'est pas renseigné, il prend par défaut la valeur "false".

  • capath : facultatif. Chemin d'accès au certificat de l'autorité de certification qui a émis le certificat Web de votre fournisseur d'identité. Cette valeur peut ne pas être nécessaire. Par exemple, si le certificat de votre fournisseur d'identité a été émis par une autorité de certification publique connue, vous n'avez pas besoin de fournir une valeur ici. Cependant, si usehttpproxy est "true", cette valeur doit être fournie, même pour une autorité de certification publique connue.

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']
  ...
}

Avec ce format de jeton, vous devez remplir la spécification oidc de votre fichier de configuration comme suit :

issueruri: 'https://server.example.com'
username: 'sub'
usernameprefix: 'uid-'
group: 'groupList'
groupprefix: 'gid-'
extraparams: 'resource=token-groups-claim'
...

Une fois le cluster utilisateur créé, vous pouvez utiliser le contrôle des accès basé sur les rôles Kubernetes (RBAC) pour accorder un accès privilégié aux utilisateurs authentifiés. Par exemple, vous pouvez créer un objet ClusterRole qui accorde à ses utilisateurs un accès en lecture seule aux codes 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

Créer votre premier fichier de configuration d'authentification

Cette section s'adresse aux administrateurs de cluster.

Une fois que vous avez créé un cluster d'utilisateur, créez un fichier de configuration d'authentification pour votre cluster :

gkectl create-login-config --kubeconfig [USER_CLUSTER_KUBECONFIG]

où [USER_CLUSTER_KUBECONFIG] est le chemin d'accès au fichier de votre cluster d'utilisateur. Lorsque vous avez créé votre cluster d'utilisateur, gkectl create cluster a généré un fichier kubeconfig pour le cluster.

La commande précédente crée un fichier nommé kubectl-anthos-config.yaml dans le répertoire actuel.

Ajouter des clusters supplémentaires à votre fichier de configuration d'authentification

Cette section s'adresse aux administrateurs de cluster.

Vous pouvez stocker la configuration d'authentification pour plusieurs clusters dans un même fichier. Vous pouvez ensuite distribuer ce fichier aux développeurs qui ont besoin d'accéder à tous ces clusters.

Commencez avec un fichier de configuration d'authentification existant. Exécutez ensuite la commande suivante pour fusionner ce fichier avec la configuration d'un cluster supplémentaire :

gkectl create-login-config --kubeconfig [USER_CLUSTER_KUBECONFIG] \
    --merge-from [IN_AUTH_CONFIG_FILE] --output [OUT_AUTH_CONFIG_FILE]

Où :

  • [USER_CLUSTER_KUBECONFIG] est le fichier kubeconfig du cluster supplémentaire.

  • [IN_AUTH_CONFIG_FILE] est le chemin d'accès au fichier de configuration d'authentification existant.

  • [OUT_AUTH_CONFIG_FILE] correspond au chemin dans lequel vous souhaitez enregistrer le fichier contenant la configuration fusionnée. Il peut s'agir de la même valeur que [IN_AUTH_CONFIG_FILE].

Distribuer le fichier de configuration d'authentification

Cette section s'adresse aux administrateurs de cluster.

Le fichier de configuration d'authentification que vous distribuez à vos développeurs doit être nommé kubectl-anthos-config.yaml. Vous pouvez le distribuer de plusieurs manières :

  • Transmettez manuellement le fichier à chaque développeur.

  • Hébergez le fichier sur une URL, afin que les développeurs puissent le télécharger.

  • Transférez le fichier à la machine de chaque développeur.

Quel que soit votre mode de distribution, pour une configuration par défaut, le fichier de configuration d'authentification doit être placé à cet emplacement sur la machine de chaque développeur :

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

Si vous ne souhaitez pas utiliser la configuration par défaut, vous pouvez créer une configuration personnalisée.

Placer le fichier de configuration d'authentification

Cette section s'adresse aux développeurs.

Le fichier de configuration d'authentification contient les détails de tous les clusters auxquels vous pouvez vous authentifier. Ne modifiez pas le contenu de ce fichier.

Si l'administrateur de cluster vous a fourni un fichier de configuration d'authentification, placez-le dans le répertoire approprié. Si l'administrateur de cluster a déjà placé la configuration sur votre machine, vous pouvez ignorer cette section.

Copiez le fichier de configuration d'authentification à son 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.

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.

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.

Obtenir le plug-in Anthos pour Kubectl

Cette section s'adresse aux administrateurs de cluster.

Le plug-in Anthos pour Kubectl est inclus dans votre poste de travail administrateur à l'adresse :

Linux

/usr/bin/kubectl_anthos/v1.0beta/linux_amd64/kubectl-anthos

macOS

/usr/bin/kubectl_anthos/v1.0beta/darwin_amd64/kubectl-anthos

Windows

/usr/bin/kubectl_anthos/v1.0beta/windows_amd64/kubectl-anthos

Vous pouvez distribuer le plug-in à vos développeurs ou leur demander de le télécharger directement.

Télécharger le plug-in Anthos pour Kubectl

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

Tous les développeurs doivent disposer du plug-in Anthos pour Kubectl sur leur propre machine. Les développeurs peuvent télécharger le plug-in individuellement, ou l'administrateur du cluster peut télécharger le plug-in, puis le distribuer aux développeurs.

Remarque pour les développeurs : Demandez à l'administrateur de cluster quelle version du plug-in vous devez utiliser.

Téléchargez le plug-in Anthos pour Kubectl :

Linux

gsutil cp gs://gke-on-prem-release/kubectl-anthos/v1.0beta/linux_amd64/kubectl-anthos ./
chmod +x kubectl-anthos

macOS

gsutil cp gs://gke-on-prem-release/kubectl-anthos/v1.0beta/darwin_amd64/kubectl-anthos ./
chmod +x kubectl-anthos

Windows

gsutil cp gs://gke-on-prem-release/kubectl-anthos/v1.0beta/windows_amd64/kubectl-anthos ./
rename kubectl-anthos kubectl-anthos.exe.

Installer le plug-in Anthos pour Kubectl

Cette section s'adresse aux développeurs.

L'administrateur de cluster peut vous fournir le plug-in Anthos pour Kubectl. Il peut également vous demander de télécharger le plug-in vous-même.

Pour installer le plug-in Anthos pour Kubectl, déplacez le fichier exécutable vers n'importe quel emplacement de votre variable PATH. Pour Linux et macOS, le fichier exécutable doit être nommé kubectl-anthos. Pour Windows, il doit être nommé kubectl-anthos.exe. Pour en savoir plus, consultez la section Installer des plug-ins Kubectl.

Vérifiez que le plug-in Anthos pour Kubectl est installé :

kubectl plugin list
kubectl anthos version

Répertorier les clusters disponibles

Cette section s'adresse aux développeurs.

Si votre fichier de configuration d'authentification se trouve sur le chemin par défaut, saisissez la commande suivante pour répertorier les clusters auxquels vous pouvez vous authentifier :

kubectl anthos listclusters

Si votre fichier de configuration d'authentification ne se trouve pas sur le chemin par défaut, saisissez la commande suivante pour répertorier les clusters :

kubectl anthos listclusters --loginconfig [AUTH_CONFIG_FILE]

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

Utiliser le plug-in Anthos pour Kubectl pour s'authentifier

Cette section s'adresse aux développeurs.

Connectez-vous à un cluster d'utilisateur :

kubectl anthos login --cluster [CLUSTER_NAME] --user [USER_NAME] \
     --loginconfig [AUTH_CONFIG_FILE] --kubeconfig [USER_CLUSTER_KUBECONFIG]

où :

  • [CLUSTER_NAME] par le nom de votre cluster d'utilisateur. Ce nom doit être sélectionné dans la liste fournie par la commande kubectl anthos listclusters.

  • [USER_NAME] correspond au paramètre facultatif qui spécifie le nom d'utilisateur pour les identifiants stockés dans le fichier kubeconfig. La valeur par défaut est [CLUSTER_NAME]-anthos-default-user.

  • [AUTH_CONFIG_FILE] est le chemin d'accès à votre fichier de configuration d'authentification. Si votre fichier de configuration d'authentification se trouve à l'emplacement par défaut, vous pouvez omettre ce paramètre.

  • [USER_CLUSTER_KUBECONFIG] est le chemin d'accès au fichier kubeconfig de votre cluster d'utilisateur. Si aucun fichier kubeconfig n'existe, la commande génère un nouveau fichier kubeconfig à partir du fichier de configuration d'authentification, puis ajoute les jetons et les détails du cluster au fichier kubeconfig.

kubectl anthos login lance un navigateur dans lequel vous pouvez saisir vos identifiants.

Le fichier kubeconfig fourni contient désormais un jeton d'ID que kubectl peut utiliser pour s'authentifier auprès du serveur d'API Kubernetes sur le cluster d'utilisateur.

La commande kubectl anthos login comporte une option --dry-run facultative. Si vous incluez l'option --dry-run, la commande imprime les commandes kubectl qui ajouteraient des jetons au fichier kubeconfig, mais n'enregistre pas réellement ces jetons dans le fichier kubeconfig.

Vérifiez que l'authentification a abouti en saisissant une commande kubectl. Exemple :

kubectl get nodes --kubeconfig [USER_CLUSTER_KUBECONFIG]

Utiliser OIDC avec Google Cloud Console

Cette section s'adresse aux développeurs.

  1. Vérifiez que votre cluster est configuré pour OIDC.

  2. Vérifiez que votre cluster a été enregistré auprès de Google Cloud soit automatiquement lors de sa création, soit manuellement.

  3. Accédez à la page Clusters Kubernetes dans la console Google Cloud.

    Accéder à la page Clusters Kubernetes

  4. Dans la liste des clusters, localisez votre cluster GKE On-Prem, puis cliquez sur Connexion.

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

    Vous serez redirigé vers votre fournisseur d'identité, où vous devrez peut-être vous connecter ou autoriser la console Google Cloud à accéder à votre compte. Vous serez ensuite redirigé vers la page Clusters Kubernetes dans la console Google Cloud.

Configuration personnalisée

Par défaut, le plug-in Anthos pour Kubectl s'attend à ce que le fichier de configuration d'authentification se trouve à un certain emplacement. Si vous ne souhaitez pas placer le fichier de configuration d'authentification à l'emplacement par défaut, vous pouvez transmettre manuellement son chemin d'accès aux commandes du plug-in à l'aide de l'option --login-config. Pour voir un exemple, consultez la section Utiliser le plug-in Anthos pour Kubectl pour s'authentifier.

Résoudre les problèmes liés à OIDC dans GKE On-Prem

Configuration non valide

Si la console Google Cloud ne peut 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é n'est pas valide, un message d'erreur en provenance de votre fournisseur d'identité s'affiche lorsque vous cliquez sur CONNEXION. Suivez les instructions propres au fournisseur pour configurer correctement le fournisseur ou votre cluster.

Autorisations non valides

Si vous avez terminé le processus d'authentification, mais que vous ne voyez toujours pas les détails du cluster, assurez-vous que vous avez accordé les autorisations RBAC correctes 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. Indiquez le paramètre prompt=consent dans le champ oidc: extraparams du fichier de configuration de GKE On-Prem et regénérez le fichier d'authentification client avec l'option --extra-params prompt=consent.