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

Configurer GKE Identity Service avec LDAP

Ce document est destiné aux administrateurs de cluster ou aux opérateurs d'application qui configurent GKE Identity Service sur leurs clusters. Il vous explique comment configurer GKE Identity Service sur vos clusters avec votre fournisseur LDAP (Lightweight Directory Access Protocol) préféré, y compris Microsoft Active Directory. Nous partons du principe que vous ou votre administrateur de plate-forme avez déjà reçu les informations de connexion de votre fournisseur LDAP en suivant les instructions de la section Configurer un fournisseur LDAP pour GKE Identity Service.

Pour en savoir plus sur le fonctionnement de GKE Identity Service et sur les autres options de configuration, consultez la page de présentation. Pour savoir comment accéder à un cluster en utilisant ce service en tant que développeur ou utilisateur de cluster, consultez la page Accéder aux clusters à l'aide de GKE Identity Service.

GKE Identity Service avec LDAP ne peut actuellement être utilisé qu'avec GKE sur VMware (clusters d'utilisateur) et GKE sur Bare Metal.

Avant de commencer

Assurez-vous que les outils de ligne de commande suivants sont installés :
- La dernière version de Google Cloud CLI, qui inclut gcloud, l'outil de ligne de commande qui permet d'interagir avec Google Cloud. Si vous devez installer Google Cloud CLI, consultez le guide d'installation.
- kubectl pour exécuter des commandes sur les clusters Kubernetes. Si vous devez installer kubectl, reportez-vous au guide d'installation.
Si vous utilisez Cloud Shell comme environnement shell pour interagir avec Google Cloud, ces outils sont installés pour vous.
Assurez-vous d'avoir initialisé gcloud CLI à utiliser avec votre projet.

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

GKE Identity Service a besoin d'un secret de compte de service pour s'authentifier auprès du serveur LDAP et récupérer les informations utilisateur. Il existe deux types de comptes de service autorisés dans l'authentification LDAP : l'authentification de base (à l'aide d'un nom d'utilisateur et d'un mot de passe pour s'authentifier auprès du serveur) ou le certificat client (à l'aide d'une clé privée du client et d'un certificat client). Vous (ou l'administrateur de votre plate-forme) devez avoir reçu ces informations sur votre fournisseur dans la section Configurer un fournisseur LDAP pour GKE Identity Service.

Pour rendre les informations de connexion du serveur LDAP disponibles pour GKE Identity Service, vous devez créer une ressource Secret Kubernetes contenant les informations de connexion obtenues dans la section Configurer un fournisseur LDAP pour GKE Identity Service.

Les exemples suivants montrent comment configurer des secrets pour les deux types de compte de service. 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 ...

SERVICE_ACCOUNT_SECRET_NAME est 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 la clé secrète appliquée à l'espace de noms anthos-identity-service, ce qui est l'approche que nous recommandons. En effet, par défaut, GKE Identity Service est autorisé à lire les secrets dans anthos-identity-service. Si vous souhaitez utiliser un autre espace de noms, modifiez les métadonnées du secret, puis ajoutez une nouvelle stratégie RBAC pour accorder au service d'identité GKE l'autorisation de lire les secrets dans cet espace de noms, comme suit:

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

GKE Identity Service utilise un type de ressource personnalisée (CRD) Kubernetes spécial pour configurer vos clusters appelés ClientConfig, avec des champs d'informations sur le fournisseur d'identité et les paramètres nécessaires pour renvoyer des informations utilisateur. Votre configuration ClientConfig inclut également le nom et l'espace de noms du secret que vous avez créés et appliqués dans la section précédente, ce qui permet à GKE Identity Service de s'authentifier auprès du serveur LDAP.

Pour appliquer la configuration à votre cluster, modifiez l'objet KRM par défaut de type clientconfig dans l'espace de noms kube-public :

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

... où USER_CLUSTER_KUBECONFIG représente le chemin du fichier kubeconfig pour le 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 :

authentication:
  - name: NAME_STRING
    ldap:
      host: HOST_NAME
      certificateAuthorityData: CERTIFICATE_AUTHORITY_DATA
      connectionType: CONNECTION_TYPE
      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

Le tableau suivant décrit les champs de l'objet CRD ClientConfig :

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
saisir	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
user
baseDN	Oui	Emplacement de la sous-arborescence du répertoire LDAP dans lequel rechercher les entrées utilisateur.	chaîne
filter	no	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	no	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 l'identifiant d'identification 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 elle sera unique pour chaque utilisateur. Si aucune valeur n'est spécifiée, la valeur par défaut est `userPrincipalName`.	chaîne
loginAttribute	no	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
filter	no	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	no	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, passez à la section Configurer l'accès des utilisateurs aux clusters avec GKE Identity Service.