Utiliser des fournisseurs d'identité externes pour s'authentifier auprès de GKE

Standard

Ce document explique comment configurer un fournisseur d'identité externe pour s'authentifier sur des clusters Google Kubernetes Engine (GKE).

Présentation

Identity Service pour GKE étend vos solutions d'identité existantes pour l'authentification à vos clusters GKE. Grâce à la compatibilité avec OpenID Connect (OIDC), vous pouvez 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. Identity Service pour GKE est limité aux fournisseurs d'identité OIDC.

Avant de commencer

Avant de lire ce document, assurez-vous de connaître les concepts d'authentification et OpenID suivants :
Les systèmes sans interface graphique ne sont pas compatibles. Un processus d'authentification basé sur navigateur est utilisé pour vous demander votre autorisation et pour autoriser votre compte utilisateur.

Avant de commencer, effectuez les tâches suivantes :

Activez l'API Google Kubernetes Engine.

Activer l'API Google Kubernetes Engine

Si vous souhaitez utiliser Google Cloud CLI pour cette tâche, installez puis initialisez gcloud CLI. Si vous avez déjà installé gcloud CLI, assurez-vous de disposer de la dernière version en exécutant la commande gcloud components update.
Remarque : Pour les installations de gcloud CLI existantes, veillez à définir les propriétés compute/region et compute/zone. En définissant des emplacements par défaut, vous pouvez éviter les erreurs gcloud CLI telles que celle-ci : One of [--zone, --region] must be supplied: Please specify location.

Qui utilise Identity Service pour GKE ?

Les tâches de ce document s'appliquent à vous si vous êtes l'un des éléments suivants :

Administrateur de cluster : 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 : exécute les charges de travail sur un ou plusieurs clusters et s'authentifie à l'aide d'OIDC.

Fonctionnement

Pour configurer et utiliser Identity Service pour GKE sur votre cluster GKE, les administrateurs de cluster effectuent les opérations suivantes :

Activez Identity Service pour GKE sur un cluster.
Configurez Identity Service pour GKE.
Créez une règle RBAC pour votre cluster.

Une fois que les administrateurs de cluster ont configuré Identity Service pour GKE, les développeurs peuvent se connecter et s'authentifier auprès du cluster.

Activer Identity Service pour GKE sur un cluster

Cette section s'adresse aux administrateurs de cluster.

Par défaut, Identity and Access Management (IAM) est configuré en tant que fournisseur d'identité pour l'authentification sur les clusters. Si vous souhaitez utiliser OIDC avec des fournisseurs d'identité tiers, vous pouvez activer Identity Service pour GKE sur des clusters nouveaux ou existants à l'aide de Google Cloud CLI.

Activer Identity Service pour GKE sur un nouveau cluster

Pour créer un cluster avec Identity Service pour GKE activé, exécutez la commande suivante :

gcloud container clusters create CLUSTER_NAME \
    --enable-identity-service

Remplacez CLUSTER_NAME par le nom de votre nouveau cluster.

Activer Identity Service pour GKE sur un cluster existant

Pour activer Identity Service pour GKE sur un cluster existant, exécutez la commande suivante :

gcloud container clusters update CLUSTER_NAME \
    --enable-identity-service

Remplacez CLUSTER_NAME par le nom de votre cluster.

Objets Kubernetes créés par Identity Service pour GKE

Le tableau suivant décrit les objets Kubernetes créés lorsque vous activez Identity Service pour GKE sur un cluster :

Objets Kubernetes
`anthos-identity-service`	`Namespace` Utilisé pour les déploiements Identity Service pour GKE.
`kube-public`	`Namespace` Utilisé pour le fichier de configuration client `default`.
`gke-oidc-envoy`	`LoadBalancer` Point de terminaison des requêtes OIDC. Externe par défaut. S'il est créé dans un cluster privé ou un cluster avec une règle de réseau stricte, le point de terminaison est interne au cloud privé virtuel du cluster. Créé dans l'espace de noms `anthos-identity-service`.
`gke-oidc-service`	`ClusterIP` Permet de communiquer entre le déploiement `gke-oidc-envoy` et le déploiement `gke-oidc-service`. Créé dans l'espace de noms `anthos-identity-service`.
`gke-oidc-envoy`	`Deployment` Exécute un proxy exposé à la ressource LoadBalancer `gke-oidc-envoy`. Il communique avec `gke-oidc-service` pour valider les jetons d'identité. Sert de proxy pour le serveur d'API Kubernetes et emprunte l'identité des utilisateurs lors de la transmission de requêtes au serveur d'API. Créé dans l'espace de noms `anthos-identity-service`.
`gke-oidc-service`	`Deployment` Valide les jetons d'identité et fournit un webhook d'admission de validation pour les ressources `ClientConfig`. Créé dans l'espace de noms `anthos-identity-service`.
`gke-oidc-operator`	`Deployment` Rapproche la configuration du client et la ressource LoadBalancer `gke-oidc-envoy`. Créé dans l'espace de noms `anthos-identity-service`.
`gke-oidc-certs`	`Secret` Contient l'autorité de certification de cluster et les certificats TLS pour l'équilibreur de charge. Créé dans l'espace de noms `anthos-identity-service`
`default`	`ClientConfig CRD` Contient des paramètres OIDC tels que la méthode d'authentification préférée, la configuration du fournisseur d'identité et les mappages des revendications des utilisateurs et des groupes. Utilisé pour la validation des jetons d'identité. Permet aux administrateurs de cluster de configurer les paramètres OIDC avant de les distribuer aux développeurs. Créé dans l'espace de noms `kube-public`

Configurer Identity Service pour GKE

Cette section s'adresse aux administrateurs de cluster.

Vous pouvez configurer le paramètre Identity Service pour GKE en téléchargeant et en modifiant le fichier ClientConfig default.

Téléchargez l'objet ClientConfig default :

kubectl get clientconfig default -n kube-public -o yaml > client-config.yaml

Mettez à jour la section spec.authentication avec les paramètres de votre choix :
```
apiVersion: authentication.gke.io/v2alpha1
kind: ClientConfig
metadata:
  name: default
  namespace: kube-public
spec:
  name: cluster-name
  server: https://192.168.0.1:6443
  authentication:
  - name: oidc
    oidc:
      clientID: CLIENT_ID
      certificateAuthorityData: OIDC_PROVIDER_CERTIFICATE
      extraParams: EXTRA_PARAMS
      issuerURI:  ISSUER_URI
      cloudConsoleRedirectURI: https://console.cloud.google.com/kubernetes/oidc
      kubectlRedirectURI: KUBECTL_REDIRECT_URL
      scopes: SCOPES
      userClaim: USER
      groupsClaim: GROUPS
      userPrefix: USER_PREFIX
      groupPrefix: GROUP_PREFIX
```
Remplacez les éléments suivants :
- CLIENT_ID : ID de l'application cliente qui envoie des requêtes d'authentification au fournisseur OIDC.
- OIDC_PROVIDER_CERTIFICATE : (facultatif) certificat PEM pour le fournisseur OIDC. Ce champ peut être utile si votre fournisseur OIDC utilise des certificats autosignés. Identity Service pour GKE inclut un ensemble de racines publiques par défaut.
- EXTRA_PARAMS : paramètres de clé-valeur supplémentaires à envoyer au fournisseur OIDC.
  - Pour autoriser des groupes, utilisez resource=token-groups-claim.
  - Pour authentifier Microsoft Azure et Okta, utilisez prompt=consent.
  - Pour Cloud Identity, utilisez prompt=consent,access_type=offline.
- ISSUER_URI : URL permettant d'envoyer des requêtes d'autorisation OIDC, telles que https://example.com/adfs. Le serveur d'API Kubernetes utilise cette URL pour découvrir les clés publiques permettant de valider les jetons. L'URI doit utiliser le protocole HTTPS. Pour Cloud Identity, utilisez https://accounts.google.com.
- KUBECTL_REDIRECT_URL : URL de redirection que kubectl oidc login utilise pour l'autorisation. Il s'agit généralement du format http://localhost:PORT/callback, où PORT est un port supérieur au port 1024 qui sera disponible sur les postes de travail des développeurs, par exemple http://localhost:10000/callback. Vous devez enregistrer l'URL auprès de votre fournisseur OIDC en tant qu'URL de redirection autorisée pour l'application cliente. Si vous utilisez Google Identity comme fournisseur OIDC, consultez la page Définir un URI de redirection pour obtenir des instructions.
- SCOPES : Niveaux d'accès supplémentaires à envoyer au fournisseur OIDC.
  - Microsoft Azure et Okta nécessitent le niveau d'accès offline_access.
  - Pour Cloud Identity, utilisez openid, email pour obtenir les jetons d'ID contenant l'adresse e-mail dans la revendication email.
- USER : revendication de l'utilisateur à partir du jeton d'identité.
- GROUPS : revendication de groupe à partir du jeton d'identité.
- USER_PREFIX : préfixe ajouté aux revendications de nom d'utilisateur pour éviter les conflits avec les noms existants. Par défaut, un préfixe d'émetteur est ajouté au champ userID donné au serveur d'API Kubernetes (sauf si la revendication utilisateur est email). L'identifiant utilisateur obtenu est ISSUER_URI#USER. Nous vous recommandons d'utiliser un préfixe, mais vous pouvez le désactiver en définissant USER_PREFIX sur -.
- GROUP_PREFIX : 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 un préfixe gid-. Le groupe ainsi obtenu est gid-foobar.
Appliquez la configuration mise à jour :
```
kubectl apply -f client-config.yaml
```
Une fois cette configuration appliquée, Identity ervice pour GKE s'exécute dans votre cluster et diffuse les requêtes derrière l'équilibreur de charge gke-oidc-envoy. L'adresse IP figurant dans le champ spec.server doit être l'adresse IP de l'équilibreur de charge. Si vous modifiez le champ spec.server, les commandes kubectl peuvent échouer.
Créez une copie du fichier de configuration client-config.yaml :
```
cp client-config.yaml login-config.yaml
```
Mettez à jour le fichier de configuration login-config.yaml avec le paramètre clientSecret dans la section spec.authentication.oidc.
```
clientSecret: CLIENT_SECRET
```
Remplacez CLIENT_SECRET par la clé secrète partagée entre l'application cliente OIDC et le fournisseur OIDC.
Distribuez le fichier login-config.yaml mis à jour à vos développeurs.

Configurer Identity Service pour GKE sur des clusters avec des stratégies strictes

Pour configurer Identity Service pour GKE afin qu'il fonctionne comme prévu sur des clusters ayant des règles de réseau strictes, telles que des clusters privés, procédez comme suit :

Ajoutez une règle de pare-feu pour le port TCP 15000 afin de permettre à votre plan de contrôle de communiquer avec le webhook de validation ClientConfig.
Si le fichier gke-oidc-envoy est créé en tant qu'équilibreur de charge interne, exposez-le sur votre VPC.
Si vous avez des règles qui refusent le trafic au sein de votre cluster, ajoutez une règle de pare-feu pour le port TCP 8443 afin de permettre au déploiement gke-oidc-envoy de communiquer avec le déploiement gke-oidc-service.

Identity Service pour GKE version 0.2.20 et ultérieure n'utilise pas le port TCP 15000. Si la version de vos composants est 0.2.20 ou ultérieure, vous n'avez pas besoin d'ajouter de règle de pare-feu pour le port 15000. Pour vérifier la version de votre composant, exécutez la commande suivante :

kubectl describe deployment gke-oidc-envoy -n anthos-identity-service \
    | grep "components.gke.io/component-name: gke-oidc" -A1

Ajouter des propriétés personnalisées à l'équilibreur de charge

Après avoir configuré Identity Service pour GKE, vous pouvez ajouter des annotations et des propriétés personnalisées, telles qu'une adresse IP statique, à l'équilibreur de charge gke-oidc-envoy. Pour modifier l'objet Service gke-oidc-envoy, exécutez la commande suivante :

kubectl edit service gke-oidc-envoy -n anthos-identity-service

Consultez la documentation sur la configuration de l'équilibrage de charge TCP/UDP pour GKE.

Créer une règle RBAC pour votre cluster

Cette section s'adresse aux administrateurs de cluster.

Les administrateurs peuvent utiliser le contrôle des accès basé sur les rôles (RBAC) Kubernetes afin d'accorder l'accès aux utilisateurs authentifiés du cluster. Pour configurer des règles RBAC pour un cluster, vous devez attribuer des rôles RBAC à chaque développeur. Pour accorder l'accès aux ressources d'un espace de noms particulier, créez un Role et un RoleBinding. Pour accorder l'accès aux ressources de l'ensemble d'un cluster, créez un ClusterRole et un ClusterRoleBinding.

Prenons l'exemple d'un utilisateur qui a besoin d'afficher tous les objets Secret du cluster. Les étapes suivantes permettent d'attribuer les rôles RBAC requis à cet utilisateur.

Enregistrez le fichier manifeste ClusterRole suivant sous le nom secret-viewer-cluster-role.yaml. Une personne disposant de ce rôle peut obtenir, surveiller et répertorier tous les objets Secret du cluster.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: secret-viewer
rules:
- apiGroups: [""]
  # The resource type for which access is granted
  resources: ["secrets"]
  # The permissions granted by the ClusterRole
  verbs: ["get", "watch", "list"]

Appliquez le fichier manifeste ClusterRole :

kubectl apply -f secret-viewer-cluster-role.yaml

Enregistrez le fichier manifeste ClusterRoleBinding suivant sous le nom secret-viewer-cluster-role-binding.yaml. La liaison accorde le rôle secret-viewer à un nom d'utilisateur défini dans le fichier de configuration du client.
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name:  people-who-view-secrets
subjects:
- kind: User
  name: ISSUER_URI#USER
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-viewer
  apiGroup: rbac.authorization.k8s.io
```
Remplacez les éléments suivants :
- ISSUER_URI : URI de l'émetteur depuis spec.authentication.oidc.issuerURI dans le fichier de configuration du client.
- USER : identifiant d'utilisateur dans le jeton situé sous le nom de revendication configuré dans spec.authentication.oidc.userClaim dans le fichier de configuration du client.

Appliquez le fichier manifeste ClusterRoleBinding :

kubectl apply -f secret-viewer-cluster-role-binding.yaml

Se connecter au cluster et s'authentifier auprès de celui-ci

Cette section s'adresse aux développeurs.

Lorsque vous recevez le fichier de configuration OIDC de votre administrateur, vous pouvez vous authentifier auprès de vos clusters.

Téléchargez le fichier login-config.yaml fourni par votre administrateur.
Installez le SDK Google Cloud CLI, qui propose un composant OIDC distinct. Vous pouvez l'installer en exécutant la commande suivante :
```
gcloud components install kubectl-oidc
```
Authentifiez-vous sur votre cluster :
```
kubectl oidc login --cluster=CLUSTER_NAME --login-config=login-config.yaml
```
Cette commande ouvre un navigateur Web vous permettant de terminer le processus d'authentification.
Une fois authentifié, vous pouvez exécuter des commandes kubectl, par exemple :
```
kubectl get pods
```

Désactiver Identity Service pour GKE

Cette section s'adresse aux administrateurs de cluster.

Vous pouvez désactiver Identity Service pour GKE à l'aide de gcloud CLI. Pour désactiver Identity Service pour GKE, exécutez la commande suivante :

gcloud container clusters update CLUSTER_NAME \
    --no-enable-identity-service

Étape suivante

Découvrez comment déployer des charges de travail.
Découvrez-en davantage sur OpenID Connect.
En savoir plus sur les champs d'application et les revendications.