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

Configurer des clusters membres du parc pour l'authentification LDAP

Ce document explique comment les administrateurs de cluster ou les opérateurs d'application peuvent configurer des clusters Kubernetes pour qu'ils soient compatibles avec l'authentification à partir d'un fournisseur LDAP (Lightweight Directory Access Protocol) tiers, tel que Microsoft Entra ID ou Google LDAP. Pour en savoir plus, consultez À propos de l'authentification à l'aide d'identités tierces.

Limites

Vous devez utiliser un type de cluster compatible avec LDAP.

Avant de commencer

Install the Google Cloud CLI.
Si vous utilisez un fournisseur d'identité (IdP) externe, vous devez d'abord vous connecter à la gcloud CLI avec votre identité fédérée.
Pour initialiser la gcloud CLI, exécutez la commande suivante :
```
gcloud init
```
Après avoir initialisé la gcloud CLI, mettez-la à jour et installez les composants requis :
```
gcloud components update
gcloud components install kubectl
```
Assurez-vous que l'administrateur de votre plate-forme vous a fourni toutes les informations nécessaires sur le fournisseur. Pour en savoir plus, consultez Configurer des fournisseurs LDAP pour l'authentification auprès des clusters.

Tout au long de cette configuration, vous devrez peut-être consulter la documentation de votre serveur LDAP. Les guides d'administration suivants expliquent la configuration de certains fournisseurs LDAP courants, et indiquent où trouver les informations dont vous avez besoin pour vous connecter au serveur LDAP et configurer vos clusters :

Générer le secret du compte de service LDAP

Votre cluster a besoin d'un secret de compte de service pour s'authentifier auprès du serveur LDAP et récupérer les informations utilisateur. L'authentification LDAP est compatible avec les mécanismes suivants :

Authentification de base, où vous utilisez un nom d'utilisateur et un mot de passe.
Authentification par certificat client, où vous utilisez une clé privée et un certificat client.

Vous (ou l'administrateur de votre plate-forme) devez avoir reçu ces informations sur votre fournisseur dans la section Configurer des fournisseurs LDAP pour l'authentification auprès des clusters. Pour rendre les informations de connexion du serveur LDAP disponibles pour le cluster, vous devez créer un secret Kubernetes contenant les identifiants LDAP. Les exemples suivants montrent comment configurer des secrets pour les deux types d'authentification. Les exemples montrent le secret appliqué à l'espace de noms anthos-identity-service.

Voici un exemple de configuration de secret d'authentification de base :

apiVersion: v1
kind: Secret
metadata:
  name: SERVICE_ACCOUNT_SECRET_NAME
  namespace: "anthos-identity-service"
type: kubernetes.io/basic-auth     # Make sure the type is correct
data:
  username: USERNAME  # Use a base64-encoded username
  password: PASSWORD  # Use a base64-encoded password

SERVICE_ACCOUNT_SECRET_NAME est le nom que vous avez choisi pour ce secret. Remplacez les valeurs de nom d'utilisateur et de mot de passe par le nom d'utilisateur et le mot de passe que vous avez obtenus à l'étape précédente. USERNAME est un nom d'utilisateur encodé en base64. PASSWORD est un mot de passe encodé en base64.

Voici un exemple de configuration de secret de certificat client :

apiVersion: v1
kind: Secret
metadata:
  name: SERVICE_ACCOUNT_SECRET_NAME
  namespace: anthos-identity-service
type: kubernetes.io/tls            # Make sure the type is correct
data:
  # the data is abbreviated in this example
  tls.crt: |
       MIIC2DCCAcCgAwIBAgIBATANBgkqh ...
  tls.key: |
       MIIEpgIBAAKCAQEA7yn3bRHQ5FHMQ ...

Remplacez SERVICE_ACCOUNT_SECRET_NAME par le nom que vous avez choisi pour ce secret. Remplacez le certificat et les valeurs de clé TLS par le certificat encodé et les valeurs de clé obtenues à l'étape précédente.

Les exemples montrent le secret appliqué à l'espace de noms anthos-identity-service. Par défaut, les composants système sont autorisés à lire les secrets dans cet espace de noms. Pour utiliser un autre espace de noms, modifiez les métadonnées dans le secret, puis ajoutez une règle RBAC pour autoriser le compte de service default dans l'espace de noms anthos-identity-service à lire les secrets de cet espace de noms, comme illustré ci-dessous :

---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: NAMESPACE
  name: ais-secret-reader-role
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get","list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: ais-secret-reader-role-binding
  namespace: NAMESPACE
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: ais-secret-reader-role
subjects:
- kind: ServiceAccount
  name: default
  namespace: anthos-identity-service
---

Configurer le cluster

Pour configurer l'authentification auprès d'un cluster à l'aide de LDAP, ajoutez les informations suivantes à une ressource personnalisée Kubernetes nommée ClientConfig :

Informations sur le fournisseur d'identité et les paramètres dont il a besoin pour renvoyer les informations utilisateur.
Nom et espace de noms du secret que vous avez créé et appliqué à l'étape précédente, ce qui permet au cluster de s'authentifier auprès du serveur LDAP.

Pour configurer votre cluster, modifiez le ClientConfig default dans l'espace de noms kube-public :

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

Remplacez USER_CLUSTER_KUBECONFIG par le chemin d'accès au fichier kubeconfig du cluster. S'il existe plusieurs contextes dans le fichier kubeconfig, le contexte actuel est utilisé. Vous devrez peut-être réinitialiser le contexte actuel sur le cluster approprié avant d'exécuter la commande.

Voici le format de configuration de ClientConfig :

apiVersion: authentication.gke.io/v2alpha1
kind: ClientConfig
metadata:
  name: default
  namespace: kube-public
spec:
  authentication:
  - name: NAME
    ldap:
      certificateAuthorityData: CERTIFICATE_AUTHORITY_DATA
      connectionType: CONNECTION_TYPE
      host: HOST_NAME
      serviceAccountSecret:
        name: SERVICE_ACCOUNT_SECRET_NAME
        namespace: NAMESPACE
        type: SECRET_FORMAT
      user:
        baseDN: BASE_DN
        filter: FILTER
        identifierAttribute: IDENTIFIER_ATTRIBUTE
        loginAttribute: LOGIN_ATTRIBUTE
      group:
        baseDN: BASE_DN
        filter: FILTER
        identifierAttribute: IDENTIFIER_ATTRIBUTE

Vous pouvez ajouter plusieurs configurations de fournisseurs d'identité OIDC, LDAP et SAML au même fichier ClientConfig. Le cluster tente de s'authentifier avec chaque configuration dans l'ordre dans lequel elles sont définies, et s'arrête après la première authentification réussie. L'exemple ClientConfig suivant définit plusieurs fournisseurs d'identité dans un ordre spécifique :

apiVersion: authentication.gke.io/v2alpha1
kind: ClientConfig
metadata:
  name: default
  namespace: kube-public
spec:
  authentication:
  - aws:
      region: us-west-2
    name: AWS Login
  - ldap:
  # Multiple lines are omitted here.
  - saml:
  # Multiple lines are omitted here.
  - azureAD:
  # Multiple lines are omitted here.
  - oidc:
    name: Okta OIDC
  # Multiple lines are omitted here.
  - oidc:
    name: Google OIDC
  # Multiple lines are omitted here.

Champs LDAP ClientConfig

Le tableau suivant décrit les champs de l'objet ldap ClientConfig. Les champs que vous devez ajouter dépendent des jetons de votre fournisseur d'identité et de la façon dont l'administrateur de votre plate-forme a configuré le fournisseur.

Champ	Obligatoire	Description	Format
nom	oui	Nom permettant d'identifier cette configuration LDAP	chaîne
hôte	oui	Nom d'hôte ou adresse IP du serveur LDAP. S'il n'est pas spécifié, le port est facultatif et est défini par défaut sur 389. Par exemple, `ldap.server.example.com` ou `10.10.10.10:389`.	chaîne
certificateAuthorityData	Obligatoire pour certains types de connexions LDAP	Contient un certificat d'autorité de certification, encodé en base64 et au format PEM pour le serveur LDAP. Ces éléments ne doivent être fournis que pour les connexions `ldaps` et `startTLS`.	chaîne
connectionType	oui	Type de connexion LDAP à utiliser lors de la connexion au serveur LDAP. La valeur par défaut est `startTLS`. Le mode `insecure` ne doit être utilisé que pour le développement, car toutes les communications avec le serveur sont en texte brut.	chaîne
serviceAccountSecret
nom	oui	Nom du secret Kubernetes qui stocke les identifiants pour le compte de service LDAP.	chaîne
espace de noms	oui	Espace de noms du secret Kubernetes qui stocke les identifiants du compte de service LDAP.	chaîne
type	oui	Définit le format du secret du compte de service afin d'accepter différents types de secrets. Si vous avez spécifié `basic-auth` dans la configuration du secret, il doit s'agir de `basic`. Sinon, il doit s'agir de `tls`. Si aucune valeur n'est spécifiée, `basic` est la valeur sur défaut.	chaîne
utilisateur
baseDN	oui	Emplacement de la sous-arborescence du répertoire LDAP dans lequel rechercher les entrées utilisateur.	chaîne
filtre	non	Filtre facultatif à appliquer lors de la recherche d'utilisateur. Il permet de restreindre les comptes utilisateur autorisés à se connecter. Si cette valeur n'est pas spécifiée, elle prend la valeur par défaut de `(objectClass=User)`.	chaîne
identifierAttribute	non	Détermine l'attribut à utiliser comme identité de l'utilisateur après son authentification. Ceci est différent du champ loginAttribute qui permet aux utilisateurs de se connecter avec un nom d'utilisateur, mais dont l'identifiant réel est une adresse e-mail ou un nom distinctif (DN). Par exemple, définir loginAttribute sur `sAMAccountName` et identifierAttribute sur `userPrincipalName` permet à un utilisateur de se connecter en tant que `bsmith`, mais les règles RBAC réelles pour l'utilisateur seraient écrites en tant que `bsmith@example.com`. L'utilisation de `userPrincipalName` est recommandée, car cette valeur sera unique pour chaque utilisateur. Si aucune valeur n'est spécifiée, la valeur par défaut est `userPrincipalName`.	chaîne
loginAttribute	non	Nom de l'attribut correspondant au nom d'utilisateur d'entrée. Cela permet de trouver l'utilisateur dans la base de données LDAP, par exemple `(<LoginAttribute>=<username>)`, et est combiné au champ de filtre facultatif. La valeur par défaut est `userPrincipalName`.	chaîne
group (champ facultatif)
baseDN	oui	Emplacement de la sous-arborescence du répertoire LDAP dans lequel rechercher les entrées de groupe.	chaîne
filtre	non	Filtre facultatif à utiliser lors de la recherche de groupes auxquels un utilisateur appartient. Il peut être utilisé pour ne rechercher explicitement que certains groupes afin de réduire le nombre de groupes renvoyés pour chaque utilisateur. La valeur par défaut est `(objectClass=Group)`.	chaîne
identifierAttribute	non	Nom d'identification de chaque groupe auquel un utilisateur appartient. Par exemple, si ce champ est défini sur `distinguishedName`, les RBAC et autres attentes du groupe doivent être écrites en tant que noms de domaine complets. Si aucune valeur n'est spécifiée, la valeur par défaut est `distinguishedName`.	chaîne

Étape suivante

Une fois la configuration appliquée, découvrez comment configurer l'accès des utilisateurs aux clusters à partir de fournisseurs externes.

Configurer des clusters membres du parc pour l'authentification LDAP Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.