S'authentifier avec OpenID Connect (OIDC)

Découvrez comment configurer GKE pour utiliser un système OpenID Connect (OIDC) pour l'authentification auprès des clusters d'utilisateurs. Cet article explique comment configurer GKE sur AWS avec n'importe quel fournisseur OpenID.

Pour mettre à niveau un cluster qui utilise l'authentification OIDC vers Kubernetes 1.21, consultez la page Mettre à niveau vers la version 1.21.

Pour en savoir plus sur le flux d'authentification GKE sur AWS, consultez la page Authentification.

Présentation

GKE sur AWS est compatible avec 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 utilisateur.

Avant de commencer

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

  • Google Cloud CLI doit être installé sur l'ordinateur local de chaque développeur.

  • Les systèmes sans interface graphique ne sont pas compatibles. Pour vous authentifier, vous devez ouvrir un navigateur sur l'ordinateur local exécutant gcloud CLI. Le navigateur vous invite ensuite à 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.

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.

Créer des URL de redirection

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

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

Définir l'URL de redirection de la CLI gcloud

Lorsque vous configurez votre fournisseur OpenID, spécifiez l'URL de redirection CLI comme suit : http://localhost:PORT/callback.

Remplacez PORT par votre numéro de port supérieur à 1024.

Définir l'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 fournisseur OIDC, spécifiez https://console.cloud.google.com/kubernetes/oidc comme l'une de vos URL de redirection.

Enregistrer vos applications clientes auprès du fournisseur OpenID

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

Pour que vos développeurs puissent utiliser Google Cloud CLI 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écouvrez l'URI d'émetteur de votre fournisseur. La console Google Cloud ou gcloud CLI envoie des requêtes d'authentification à cet URI.

  • Configurez votre fournisseur avec l'URL de redirection, y compris votre numéro de port, pour gcloud CLI.

  • Configurez votre fournisseur avec l'URL de redirection pour la console Google Cloud, https://console.cloud.google.com/kubernetes/oidc.

  • Créez un seul ID client que votre fournisseur utilise pour identifier à la fois Google Cloud CLI et la console Google Cloud.

  • Créez un code secret client unique que gcloud CLI et la console Google Cloud utilisent pour s'authentifier auprès du fournisseur OpenID.

  • Créez un champ d'application personnalisé que gcloud CLI ou la console Google Cloud peut utiliser pour demander les groupes de sécurité de l'utilisateur.

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

Configurer le cluster

Cette section s'adresse aux administrateurs de cluster.

Pour configurer l'authentification OIDC, vous devez configurer la ressource AWSCluster de votre cluster d'utilisateur avec les détails d'authentification d'un cluster. Les détails d'AWSCluster permettent de configurer OIDC pour la console Google Cloud et le plug-in d'authentification pour GKE Enterprise. La configuration inclut les informations OIDC suivantes :

authentication:
  awsIAM:
    adminIdentityARNs:
      - AWS_IAM_ARN
  oidc:
  -   certificateAuthorityData: CERTIFICATE_STRING
      clientID: CLIENT_ID
      clientSecret: CLIENT_SECRET 
      extraParams:  EXTRA_PARAMS
      groupsClaim:  GROUPS_CLAIM
      groupPrefix:  GROUP_PREFIX
      issuerURI:  ISSUER_URI
      kubectlRedirectURI:  KUBECTL_REDIRECT_URI
      scopes:  SCOPES
      userClaim:  USER_CLAIM
      userPrefix:  USER_PREFIX

Champs d'authentification

Le tableau suivant décrit les champs de l'objet authentication.awsIAM.adminIdentityARNs.

Le tableau suivant décrit les champs de l'objet oidc.
Champ Obligatoire Description Format
adminIdentityARNs Oui, si vous configurez OIDC. Amazon Resource Name (ARN) des identités AWS IAM (utilisateurs ou rôles) ayant reçu l'accès administrateur au cluster par GKE sur AWS. Exemple : arn:aws:iam::123456789012:group/Developers Chaîne
Champ Obligatoire Description Format
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== Chaîne
clientID Oui ID de l'application cliente qui envoie des requêtes d'authentification au fournisseur OpenID. Chaîne
clientSecret Non Clé secrète partagée entre l'application cliente OIDC et le fournisseur OIDC. Chaîne
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é. Chaîne
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 le préfixe gid- ; le groupe de résultats est gid-foobar. Chaîne
issuerURI Oui 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
kubectlRedirectURI Oui L'URL de redirection que "kubectl" utilise pour l'autorisation. Chaîne d'URL
scopes Oui 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 Non 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. Chaîne
userPrefix Non Préfixe ajouté aux revendications de nom d'utilisateur pour éviter les conflits avec les noms existants. Chaîne

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.
  • L'utilisation d'adresses e-mail peut créer à la fois un risque de disponibilité (si un utilisateur modifie son adresse e-mail principale) et un risque de sécurité (si un e-mail peut être réattribué).

Au lieu d'attribuer des ID utilisateur, nous recommandons des stratégies de groupe, qui peuvent être persistantes et plus faciles à contrôler.

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 :

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

Après avoir créé le cluster d'utilisateur, vous devez utiliser le contrôle d'accès basé sur les rôles Kubernetes (RBAC) pour accorder un accès privilégié aux utilisateurs authentifiés.

Dans l'exemple suivant, vous allez créer un objet ClusterRole qui accorde à ses utilisateurs un accès en lecture seule aux secrets du cluster et qui créée une ressource ClusterRoleBinding pour lier le rôle au groupe authentifié.

  1. Définissez un ClusterRole. Copiez le fichier YAML suivant dans un fichier nommé secret-reader-role.yaml.

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

  2. Définissez un élément ClusterRoleBinding. Copiez le fichier YAML suivant dans un fichier nommé secret-reader-admins.yaml.

    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

  3. Appliquez secret-reader-role.yaml et secret-reader-admins.yaml à votre cluster avec kubectl.

    env HTTPS_PROXY=http://localhost:8118 \
  kubectl apply -f secret-reader-role.yaml && \
  kubectl apply -f secret-reader-admins.yaml

    Les utilisateurs autorisés à accéder dans read-secrets-admins peuvent désormais lire les secrets de votre cluster.

Créer une configuration de connexion

Cette section s'adresse aux administrateurs de cluster.

Après avoir créé un cluster d'utilisateur, vous devez générer un fichier de configuration pour le cluster à l'aide de gcloud anthos create-login-config.

  1. À partir de votre répertoire anthos-aws, utilisez anthos-gke pour basculer vers le contexte de votre cluster d'utilisateur. 

    cd anthos-aws
env HTTPS_PROXY=http://localhost:8118 \
  anthos-gke aws clusters get-credentials CLUSTER_NAME
    Remplacez CLUSTER_NAME par le nom de votre cluster d'utilisateur.

  2. Créez la configuration à l'aide de la commande gcloud anthos.

    gcloud anthos create-login-config --kubeconfig usercluster-kubeconfig

    Remplacez usercluster-kubeconfig par le chemin d'accès au fichier kubeconfig de votre cluster d'utilisateur. Sous Linux et macOS, ce fichier est par défaut situé à l'adresse ~/.kube/config.

Cette commande génère un fichier (kubectl-anthos-config.yaml) contenant les informations de configuration que vos développeurs utiliseront pour s'authentifier auprès du cluster à l'aide de gcloud CLI. Vous ne devez pas modifier ce fichier.

Pour en savoir plus sur le contenu de kubectl-anthos-config.yaml, consultez l'annexe.

Distribuer la configuration de connexion

Distribuez le fichier de configuration aux utilisateurs devant s'authentifier auprès de vos clusters d'utilisateur. Vous pouvez distribuer la configuration en :

  • plaçant le fichier dans le répertoire par défaut ;
  • distribuant le fichier de façon sécurisée ;
  • hébergeant le fichier sur un serveur HTTPS.

Répertoires de configuration de connexion par défaut

Les emplacements par défaut pour le stockage du fichier de configuration pour chaque système d'exploitation sont les suivants :

Linux
$HOME/.config/google/anthos/kubectl-anthos-config.yaml, où $HOME est le répertoire d'accueil de l'utilisateur.
macOS
$HOME/Library/Preferences/google/anthos/kubectl-anthos-config.yaml, où $HOME est le répertoire d'accueil de l'utilisateur.
Windows
%APPDATA%/google/anthos/kubectl-anthos-config.yaml, où %APPDATA% est le répertoire de données de l'application de l'utilisateur.

Une fois la configuration de connexion distribuée, vos développeurs peuvent configurer gcloud CLI pour accéder au cluster.

Modifier le cluster après la mise à niveau vers Kubernetes 1.21

Après avoir mis à niveau votre cluster vers Kubernetes 1.21, vous devez configurer GKE Identity Service et supprimer vos informations OIDC de la configuration de votre cluster. Pour mettre à jour la configuration, procédez comme suit :

  1. Suivez la procédure décrite dans la section Mettre à niveau votre cluster.

  2. À partir de votre répertoire anthos-aws, utilisez anthos-gke pour basculer vers le contexte de votre cluster d'utilisateur. 

    cd anthos-aws
env HTTPS_PROXY=http://localhost:8118 \
  anthos-gke aws clusters get-credentials CLUSTER_NAME
    Remplacez CLUSTER_NAME par le nom de votre cluster d'utilisateur.

  3. Dans un éditeur de texte, ouvrez le fichier manifeste contenant la ressource AWSCluster. Gardez le fichier ouvert et utilisez les valeurs de l'objet oidc pour suivre les étapes décrites dans la section Configurer des clusters pour GKE Identity Service.

  4. À partir de votre répertoire anthos-aws, utilisez anthos-gke pour basculer vers le contexte de votre service de gestion. 

    cd anthos-aws
anthos-gke aws management get-credentials

  5. Dans un éditeur de texte, ouvrez le fichier YAML dans lequel vous avez créé votre AWSCluster. Si vous ne disposez pas de votre fichier YAML initial, vous pouvez utiliser kubectl edit.

    Modifier le fichier YAML

    Si vous avez suivi les instructions de la section Créer un cluster d'utilisateur, votre fichier YAML s'appelle cluster-0.yaml. Ouvrez ce fichier dans un éditeur de texte.

    Utiliser kubectl edit

    Pour modifier votre AWSCluster à l'aide de kubectl edit, exécutez la commande suivante :

    env HTTPS_PROXY=http://localhost:8118 \
  kubectl edit awscluster cluster-name

    Remplacez cluster-name par votre AWSCluster. Par exemple, pour modifier le cluster par défaut, cluster-0, exécutez la commande suivante :

    env HTTPS_PROXY=http://localhost:8118 \
  kubectl edit awscluster cluster-0

  6. Supprimez l'objet oidc du fichier manifeste de votre cluster.

  7. Enregistrez le fichier. Si vous utilisez kubectl edit, kubectl applique automatiquement les modifications. Si vous modifiez le fichier YAML, appliquez-le à votre service de gestion à l'aide de la commande suivante :

    env HTTPS_PROXY=http://localhost:8118 \
  kubectl apply -f cluster-0.yaml

    Le service de gestion met ensuite à jour l'AWSCluster.

Configurer gcloud pour accéder à votre cluster

Cette section est destinée aux développeurs ou aux administrateurs de cluster.

Prérequis

Pour terminer cette section, vous devez disposer des éléments suivants :

  • Une configuration de connexion.

  • Une version mise à jour de gcloud CLI avec les composants anthos-auth.

    gcloud components update
gcloud components install anthos-auth

  • Vérifiez que la CLI gcloud a bien été installée en exécutant la commande suivante, qui devrait fournir des détails sur les arguments requis et les options disponibles.

    gcloud anthos auth

S'authentifier auprès de votre cluster

Vous pouvez vous authentifier auprès de votre cluster des manières suivantes :

  • Avec gcloud CLI sur votre ordinateur local
  • Avec gcloud CLI sur une machine distante à l'aide d'un tunnel SSH

  • Avec Connect sur Google Cloud Console.

gcloud local

Utilisez gcloud anthos auth login pour vous authentifier auprès de votre cluster avec votre configuration de connexion.

Si vous avez placé la configuration de connexion à l'emplacement par défaut et que le nom du cluster est configuré, vous pouvez utiliser gcloud anthos auth login sans option. Vous pouvez également configurer le cluster, l'utilisateur et d'autres informations d'authentification avec des paramètres facultatifs.

Par défaut

gcloud anthos auth login --cluster CLUSTER_NAME

Remplacez CLUSTER_NAME par un nom de cluster complet. Par exemple, projects/my-gcp-project/locations/global/memberships/cluster-0-0123456a.

Paramètres facultatifs

gcloud anthos auth login accepte les paramètres facultatifs suivants :

gcloud anthos auth login --cluster CLUSTER_NAME \
--user USERNAME --login-config ANTHOS_CONFIG_YAML \
--login-config-cert LOGIN_CONFIG_CERT_PEM \
--kubeconfig=KUBECONFIG --dry-run

Les paramètres sont décrits dans le tableau suivant.

Paramètre Description
cluster Nom du cluster sur lequel s'authentifier. Correspond par défaut au cluster dans "kubectl-anthos-config.yaml".
user Nom d'utilisateur pour les identifiants dans kubeconfig. La valeur par défaut est {cluster-name}-anthos-default-user.
login-config Soit le chemin d'accès au fichier de configuration généré par l'administrateur du cluster pour le développeur, soit une URL hébergeant le fichier. La valeur par défaut est kubectl-anthos-config.yaml.
login-config-cert Si vous utilisez une URL pour login-config, le chemin d'accès au fichier de certificat CA pour les connexions HTTPS.
kubeconfig Chemin d'accès au fichier kubeconfig contenant des jetons. La valeur par défaut est $HOME/.kube/config`.
simulation Testez vos options de ligne de commande sans modifier votre configuration ou votre cluster.

La commande gcloud anthos login lance un navigateur qui demande à l'utilisateur de se connecter avec ses identifiants d'entreprise, effectue un échange d'identifiants OIDC et obtient les jetons appropriés. gcloud CLI écrit ensuite les jetons dans un fichier kubeconfig. kubectl utilise ce fichier pour s'authentifier auprès du cluster d'utilisateur.

Pour vérifier que l'authentification a abouti, exécutez une commande kubectl avec votre fichier kubeconfig :

env HTTPS_PROXY=http://localhost:8118 \
  kubectl get nodes --kubeconfig my.kubeconfig

Tunnel gcloud

Si vous souhaitez vous authentifier auprès d'un cluster d'utilisateur depuis un ordinateur distant, vous pouvez effectuer l'authentification à l'aide d'un tunnel SSH. Pour utiliser un tunnel, 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 USERNAME@REMOTE_MACHINE -L LOCAL_PORT:localhost:REMOTE_PORT

Remplacez l'élément suivant :

  • USERNAME par un utilisateur disposant d'un accès SSH à la machine distante.

  • REMOTE_MACHINE par le nom d'hôte ou l'adresse IP de la machine distante.

  • LOCAL_PORT est un port disponible sur votre ordinateur local que ssh utilise pour créer un tunnel vers la machine distante.

  • REMOTE_PORT est le port que vous avez configuré pour votre URL de redirection OIDC. Le numéro de port fait partie du 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

Remplacez AUTH_CONFIG_FILE par le chemin d'accès de votre fichier de configuration d'authentification sur la machine distante. gcloud CLI exécute un serveur Web 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 de votre ordinateur distant dispose désormais du jeton permettant d'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

Console

Vous pouvez vous authentifier avec la console Google Cloud, puis lancer le flux d'authentification à partir de la page des clusters Kubernetes dans la console Google Cloud :

  1. Ouvrez la console Google Cloud.

    Accéder à la page Clusters Kubernetes

  2. Localisez votre cluster GKE sur AWS 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 à la console Google Cloud ou l'autoriser à accéder à votre compte. Vous êtes ensuite redirigé vers la page Clusters Kubernetes dans la console Google Cloud.

Mettre à jour la configuration OIDC

Pour mettre à jour la configuration OIDC sur votre cluster, exécutez la commande kubectl edit.

env HTTPS_PROXY=http://localhost:8118 \
  kubectl edit clientconfigs -n kube-public default

L'outil kubectl charge la ressource ClientConfig dans votre éditeur par défaut. Pour mettre à jour la configuration, enregistrez le fichier. L'outil kubectl met à jour la ressource ClientConfig sur votre cluster.

Pour en savoir plus sur le contenu de la ressource ClientConfig, consultez la section suivante.

Annexe : Exemple de configuration de connexion

Vous trouverez ci-après un exemple de kubectl-anthos-config.yaml, qui est donné pour en comprendre le contenu. Vous devez toujours générer le fichier avec gcloud anthos create-login-config.

apiVersion: authentication.gke.io/v2alpha1
kind: ClientConfig
metadata:
 name: default
 namespace: kube-public
spec:
  authentication:
  - name: oidc
    oidc:
      clientID: CLIENT_CONFIG
      clientSecret: CLIENT_SECRET
      extraParams: resource=k8s-group-claim,domain_hint=consumers
      certificateAuthorityData:   CERTIFICATE_STRING
      issuerURI: https://adfs.contoso.com/adfs
      kubectlRedirectURI: http://redirect.kubectl.com/
      scopes: allatclaim,group
      userClaim: "sub"
      groupsClaim: "groups"
    proxy: PROXY_URL #Optional
  certificateAuthorityData: CERTIFICATE_AUTHORITY_DATA
  name: projects/my-project/locations/global/membership/cluster-0
  server: https://192.168.0.1:PORT
  preferredAuthentication: oidc

Pour obtenir des explications sur le contenu des champs, consultez la section Champs d'authentification.

Étapes suivantes

Déployez votre première charge de travail sur GKE sur AWS.