Une nouvelle version d'Anthos clusters on AWS (GKE sur AWS) a été publiée le 3 février. Pour en savoir plus, consultez les notes de version.

S'authentifier avec OpenID Connect (OIDC)

Découvrez comment configurer Anthos clusters on AWS (GKE sur AWS) afin d'utiliser OpenID Connect (OIDC) pour l'authentification auprès des clusters d'utilisateur. Cet article aborde le processus en général pour vous aider à comprendre comment configurer un fournisseur OpenID.

Pour obtenir une présentation du flux d'authentification d'Anthos clusters on AWS, consultez la page Authentification.

Présentation

Anthos clusters on AWS est compatible avec OIDC en tant que mécanisme d'authentification permettant d'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 :

  • Le SDK Cloud et l'outil de ligne de commande gcloud doivent être installés 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 l'outil gcloud. 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 OpenID Certification (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 l'outil gcloud et pour Cloud Console.

Définir l'URL de redirection de l'outil 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 Cloud Console

L'URL de redirection de Cloud Console 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 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 l'outil de ligne de commande gcloud ou Cloud Console 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. L'outil gcloud ou Cloud Console envoie des requêtes d'authentification à cet URI.

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

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

  • Créez un seul ID client que votre fournisseur utilise pour identifier à la fois l'outil de ligne de commande gcloud et Cloud Console.

  • Créez un code secret client unique que l'outil gcloud et Cloud Console utilisent pour s'authentifier auprès du fournisseur OpenID.

  • Créez un champ d'application personnalisé que l'outil gcloud ou Cloud Console 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 votre cluster

Cette section s'adresse aux administrateurs de cluster.

Pour configurer l'authentification OIDC, vous devez configurer l'objet CRD AWSAWS de votre cluster d'utilisateur avec les détails d'authentification d'un cluster. Les détails d'AWSCluster permettent de configurer OIDC pour Cloud Console et le plug-in d'authentification pour Anthos. 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

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. Nom de ressource Amazon (ARN) des identités IAM AWS (utilisateurs ou rôles) ayant reçu l'accès administrateur au cluster par Anthos clusters on 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 HTTP_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 HTTP_PROXY=http://localhost:8118 \
    anthos-gke aws clusters get-credentials CLUSTER_NAME

  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 l'outil gcloud. 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 l'outil gcloud pour accéder au cluster.

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 l'outil gcloud 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
    

Authentification

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

  • Avec l'outil gcloud sur votre ordinateur local.
  • Avec l'outil gcloud 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. L'outil gcloud é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 HTTP_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. L'outil gcloud 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 Google Cloud Console, lancer la procédure d'authentification à partir de la page des clusters Kubernetes dans Cloud Console :

  1. Ouvrez Cloud Console :

    Accéder à la page Clusters Kubernetes

  2. Localisez votre cluster du service Anthos clusters on AWS dans la liste, puis cliquez sur Login (Connexion).

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

    Vous êtes redirigé vers le fournisseur de l'identité. Vous devrez peut-être vous connecter ou autoriser Cloud Console à accéder à votre compte. Vous êtes ensuite redirigé vers la page Clusters Kubernetes dans Cloud Console.

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:   AUTHORITY_DATA
      issuerURI: https://adfs.contoso.com/adfs
      kubectlRedirectURI: http://redirect.kubectl.com/
      scopes: allatclaim,group
      userClaim: "sub"
      groupsClaim: "groups"
  certificateAuthorityData: CERTIFICATE_AUTHORITY_DATA
  name: projects/my-project/locations/global/membership/cluster-0
  server: https://192.168.0.1:PORT
  preferredAuthentication: oidc

Étape suivante

Déployez votre première charge de travail sur Anthos clusters on AWS.