Procéder à l'authentification à l'aide d'OIDC et d'ADFS

Alpha

Ce produit ou cette fonctionnalité est soumis aux "Conditions des offres de pré-DG" dans la section "Conditions d'utilisation générales" des Conditions spécifiques au service. Les produits et fonctionnalités pré-DG sont disponibles "en l'état" et peuvent bénéficier d'une assistance limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Cette page explique comment utiliser OIDC (OpenID Connect) avec ADFS (Active Directory Federation Services) pour configurer l'authentification pour les clusters d'utilisateurs GKE On-Prem.

Pour une présentation du flux d'authentification, consultez la page Authentification.

Présentation

GKE On-Prem est compatible avec OpenID Connect (OIDC) en tant que mécanisme d'authentification pour interagir avec le serveur d'API Kubernetes d'un cluster d'utilisateur. Pour que ce flux d'authentification soit automatique pour les utilisateurs de cluster, GKE On-Prem fournit le plug-in Kubectl pour OIDC, un plug-in kubectl.

Dans cet exercice, vous allez utiliser un ensemble d'assistants de gestion ADFS pour configurer une relation entre l'outil de ligne de commande kubectl, votre serveur ADFS et votre base de données AD d'employés.

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.

Cette rubrique concerne les entreprises disposant de l'infrastructure suivante :

• L'entreprise utilise Active Directory (AD) pour sa base de données d'employés.
• L'entreprise exécute un serveur Active Directory Federation Services (ADFS).
• Le serveur ADFS agit en tant que fournisseur OpenID.

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

Téléchargez le plug-in et définissez les autorisations d'accès :

Linux

gsutil cp gs://gke-on-prem-release/oidc-plugin/v1.1alpha/linux_amd64/kubectl-oidc .
chmod +x kubectl-oidc

Windows

gsutil cp gs://gke-on-prem-release/oidc-plugin/v1.1alpha/windows_amd64/kubectl-oidc .

macOS

gsutil cp gs://gke-on-prem-release/oidc-plugin/v1.1alpha/darwin_amd64/kubectl-oidc .
chmod +x kubectl-oidc

Installer le plug-in

Installez le plug-in en déplaçant le fichier exécutable à n'importe quel emplacement de votre PATH. Le fichier exécutable doit être nommé kubectl-oidc. Pour en savoir plus, consultez la section Installer des plug-ins Kubectl.

Créer un URI de redirection

Vous devez fournir un URI de redirection que le fournisseur OpenID peut utiliser pour renvoyer des jetons d'ID. Les jetons sont envoyés au plug-in Kubectl pour OIDC, qui s'exécute sur la machine locale de chaque employé et écoute sur le port de votre choix. Choisissez un numéro de port supérieur à 1 024 et adapté à cet usage. Ainsi, l'URI de redirection est :

http://localhost:[PORT]/callback

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

Configurer ADFS

Les sections suivantes expliquent comment configurer ADFS pour GKE On-Prem.

Définir l'URI de redirection

1. Ouvrez le volet de gestion ADFS.

2. Sélectionnez Groupes d'applications > Actions > Ajouter un groupe d'applications.

3. Sélectionnez Application de serveur. Saisissez le nom et la description de votre choix. Cliquez sur Suivant.

4. Saisissez votre URI de redirection. Vous recevez un ID client. C'est par ce biais que le fournisseur OpenID identifie l'application kubectl. Notez l'ID client pour pouvoir l'utiliser ultérieurement.

5. Sélectionnez Générer une clé secrète partagée. L'application kubectl utilise cette clé secrète pour s'authentifier auprès du fournisseur OpenID. Enregistrez la clé secrète pour plus tard.

Configurer des groupes de sécurité (facultatif)

1. Dans la gestion ADFS, sélectionnez Approbations par un tiers de confiance > Ajouter une approbation par un tiers de confiance.

2. Sélectionnez Prise en charge des revendications, puis cliquez sur Démarrer.

3. Sélectionnez Saisir manuellement les données concernant le tiers de confiance.

4. Saisissez un nom à afficher.

5. Ignorez les deux étapes suivantes.

6. Saisissez un identifiant d'approbation par un tiers de confiance. Suggestion : token-groups-claim.

7. Pour Stratégie de contrôle d'accès, sélectionnez Autoriser tout le monde. Cela signifie que tous les employés partagent leurs informations de groupe de sécurité avec kubectl oidc.

8. Cliquez sur Terminer.

Mapper des attributs LDAP à des noms de revendication

1. Dans la gestion ADFS, sélectionnez Approbations par des tiers de confiance > Éditer la stratégie d'émission de revendication.

2. Sélectionnez Envoyer les attributs LDAP en tant que revendications, puis cliquez sur Suivant.

3. Dans Nom de la règle de revendication, saisissez groups.

4. Dans Liste des attributs, sélectionnez Active Directory.

5. Dans le tableau, pour Attribut LDAP, sélectionnez Token Groups - Qualified Names (Groupes de jetons - Noms de qualification). Pour Outgoing Claim Type (Type de revendication sortante), sélectionnez groupes.

6. Cliquez sur Terminer, puis sur Appliquer.

Enregistrer kubectl avec ADFS

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"

où :

• [CLIENT_ID] est l'ID client kubectl que vous avez obtenu précédemment.

• [SERVER_ROLE_IDENTIFIER] est l'identifiant de revendication que vous avez saisi précédemment. Rappelez-vous que l'identifiant suggéré était token-groups-claim.

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

Pendant l'installation, vous générez un fichier de configuration GKE On-Prem à l'aide de gkectl create-config. La configuration inclut la spécification oidc suivante. Renseignez "oidc" avec des valeurs spécifiques à votre fournisseur :

oidc:
  issuerurl:
  kubectlredirecturl:
  clientid:
  clientsecret:
  username:
  usernameprefix:
  group:
  groupprefix:
  scopes:
  extraparams:
  usehttpproxy:
  capath:

• issuerurl : URL de votre fournisseur OpenID, telle que https://example.com/adfs. Les applications clientes, telles que le plug-in Kubectl pour OIDC, envoient des requêtes d'autorisation à cette URL. Le serveur de l'API Kubernetes utilise cette URL pour découvrir les clés publiques permettant de valider les jetons. Vous devez utiliser HTTPS. Ce champ est obligatoire.
• kubectlredirecturl : URL de redirection de l'hôte local, pour le plug-in Kubectl pour OIDC. Vous devez enregistrer l'URL de redirection auprès de votre fournisseur OpenID pour l'utiliser par l'ID client attribué à ce cluster. Ce champ est obligatoire.
• clientid : ID de l'application cliente, tel que le plug-in Kubectl pour OIDC, qui envoie des requêtes d'authentification au fournisseur OpenID. Ce champ est obligatoire.
• clientsecret : clé secrète de l'application cliente. Ce champ est obligatoire.
• usehttpproxy : choisissez de déployer un proxy inverse dans le cluster pour permettre à l'agent Connect d'accéder au fournisseur OIDC sur site pour authentifier les utilisateurs. La valeur doit être une chaîne : "true" ou "false". Ce champ est obligatoire.
• username : 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 OIDC. Toutefois, les revendications autres que email sont précédées de l'URL de l'émetteur afin d'éviter les conflits avec les noms d'autres plug-ins.
• usernameprefix : préfixe précédé des revendications de nom d'utilisateur pour éviter les conflits avec les noms existants. Si vous n'ajoutez pas cet indicateur et que username est une valeur autre que l'adresse e-mail, le préfixe est défini par défaut sur issueruri#. La valeur - peut être utilisée pour désactiver tout préfixe.
• group : revendication JWT à utiliser comme groupe de l'utilisateur. Si la revendication est présente, il doit s'agir d'un tableau de chaînes.
• groupprefix : 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.
• scopes : champs d'application supplémentaires à envoyer au fournisseur OpenID sous forme de liste séparée par des virgules.
• extraparams : paramètres de clé-valeur supplémentaires à envoyer au fournisseur OpenID.
• capath: chemin d'accès au certificat de l'autorité de certification qui a signé le certificat Web de votre fournisseur d'identité.

  Les clusters GKE On-Prem utilisent le protocole TLS pour sécuriser la communication entre leurs composants. Pour que Kubernetes génère automatiquement des certificats clients lors de l'installation et de l'amorçage des nœuds, GKE On-Prem doit être installé avec une autorité de certification.

  Par défaut, GKE On-Prem crée une autorité de certification lors de l'installation qui génère des certificats TLS. L'autorité de certification et les certificats générés sont stockés localement dans le cluster d'administration.

Exemple : Authentifier et autoriser un groupe

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 le GID peut être à la fois persistant et plus facile à contrôler.

Supposons que votre fournisseur crée des jetons OpenID qui incluent les champs suivants :

{
  'iss': 'https://server.example.com'
  'sub': 'u98523-4509823'
  'groupList: ['[e-mail]', '[e-mail]']
  ...
}

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

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 le certificat CA (autorité de certification) du serveur

Le fichier kubeconfig de votre cluster utilisateur stocke les données de l'autorité de certification de son hôte dans son champ certificate-authority-data. Vous devez décoder cette valeur et la stocker dans un fichier local, tel que server-ca-cert :

cat [USER_CLUSTER_KUBECONFIG]  | grep certificate-authority-data | awk '{ print $2}' | base64 --decode > server-ca-cert

Générer le fichier de configuration d'authentification du client

Une fois que vous avez configuré votre cluster utilisateur pour OpenID et créé celui-ci, un utilisateur peut se connecter au cluster en transmettant un fichier de configuration d'authentification client à kubectl oidc login. Pour générer un fichier de configuration d'authentification client, saisissez la commande suivante :

PowerShell

kubectl oidc client-config `
--issuer-uri [ISSUER_URI] `
--redirect-uri [REDIRECT_URI] `
--client-id [CLIENT_ID] `
--client-secret [CLIENT_SECRET] `
--scopes "allatclaims" `
--cluster-name [USER_CLUSTER_NAME] `
--server [CLUSTER_URL] `
--server-ca-file server-ca-cert `
--issuer-ca-file [ADFS_CA_CERT] `
--extra-params "resource=token-groups-claim"
> client-config.yaml

• [ISSUER_URI] est votre URI d'émetteur.
• [REDIRECT_URI] est votre URI de redirection.
• [CLIENT_ID] est l'ID client pour l'application "kubectl".
• [CLIENT_SECRET] est le code secret du client qui a été généré automatiquement.
• [USER_CLUSTER_NAME] est le nom de votre cluster d'utilisateur.
• [CLUSTER_URL] est l'URL du serveur d'API Kubernetes de votre cluster.
• --server-ca-file accepte le chemin d'accès au fichier CA que vous avez créé dans la section précédente.
• [ADFS_CA_CERT] correspond au chemin d'accès au fichier de certificat public de l'autorité de certification ADFS.
• --extra-param envoie une paire clé-valeur avec la requête d'authentification au fournisseur OIDC.

Linux

kubectl oidc client-config \
--issuer-uri [ISSUER_URI] \
--redirect-uri [REDIRECT_URI] \
--client-id [CLIENT_ID] \
--client-secret [CLIENT_SECRET] \
--scopes "allatclaims" \
--cluster-name [USER_CLUSTER_NAME] \
--server [CLUSTER_URL] \
--server-ca-file server-ca-cert \
--issuer-ca-file [ADFS_CA_CERT] \
--extra-params "resource=token-groups-claim"
> client-config.yaml

• [ISSUER_URI] est votre URI d'émetteur.
• [REDIRECT_URI] est votre URI de redirection.
• [CLIENT_ID] est l'ID client pour l'application "kubectl".
• [CLIENT_SECRET] est le code secret du client qui a été généré automatiquement.
• [USER_CLUSTER_NAME] est le nom de votre cluster d'utilisateur.
• [CLUSTER_URL] est l'URL du serveur d'API Kubernetes de votre cluster.
• --server-ca-file accepte le chemin d'accès au fichier CA que vous avez créé dans la section précédente.
• [ADFS_CA_CERT] correspond au chemin d'accès au fichier de certificat public de l'autorité de certification ADFS.
• --extra-param envoie une paire clé-valeur avec la requête d'authentification au fournisseur OIDC.

Remarque:Microsoft vous recommande d'avoir appliqué la mise à jour de sécurité KB4019472 si vous utilisez le champ d'application allatclaims.

Cette commande génère un fichier d'authentification client appelé client-config.yaml. Ne modifiez pas manuellement ce fichier. Chaque employé qui doit s'authentifier auprès du cluster d'utilisateurs doit recevoir client-config.yaml.

Authentifier contre un cluster utilisateur à l'aide du plug-in Kubectl pour OIDC

Pour vous authentifier auprès d'un cluster d'utilisateurs à l'aide du fichier d'authentification client, procédez comme suit à partir de votre machine locale ou VM :

1. Initialisez le plug-in à l'aide du fichier client-config.yaml :

   kubectl oidc login --clientconfig-file=client-config.yaml --user [NAME] \
   --kubeconfig [KUBECONFIG_OUTPUT_PATH]
   

   où :

   • [NAME] est le nom d'utilisateur choisi.
   • [KUBECONFIG_OUTPUT_PATH] est l'emplacement de sortie du fichier kubeconfig où les identifiants sont stockés.

   kubectl oidc login lance un navigateur dans lequel l'utilisateur ou l'employé peut saisir ses 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.

   Remarque:Les utilisateurs Windows devront peut-être exécuter la commande kubectl-oidc.exe login au lieu de kubectl oidc login
   .

2. Vous devriez maintenant être authentifié. Pour savoir si vous êtes authentifié, saisissez n'importe quelle commande kubectl. Exemple :

   kubectl get nodes --kubeconfig [KUBECONFIG_OUTPUT_PATH]
   

Résumé

Votre entreprise exécute un serveur ADFS qui fait office de fournisseur OpenID. Votre fournisseur OpenID connaît l'application kubectl et sait que kubectl peut demander les champs d'application openid et allatclaims.

L'attribut LDAP Token-Groups Qualified Names de votre base de données AD est mappé sur la revendication groups de votre fournisseur OpenID. Le fournisseur renvoie les jetons qui incluent l'ID de l'employé, l'identifiant de l'émetteur, la revendication openid et la revendication groups. La revendication groups répertorie les groupes de sécurité auxquels un employé appartient.

Étapes suivantes

• Consultez la présentation de l'authentification avec OpenID Connect dans GKE On-Prem.

• Découvrez-en davantage sur OAuth 2.0.

• Découvrez-en davantage sur OpenID Connect.

• En savoir plus sur les champs d'application et les revendications.

• En savoir plus sur les revendications personnalisées dans les jetons d'ID.