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


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.

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 :

  1. Activez Identity Service pour GKE sur un cluster.
  2. Configurez Identity Service pour GKE.
  3. 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.

  1. Téléchargez l'objet ClientConfig default :

    kubectl get clientconfig default -n kube-public -o yaml > client-config.yaml
    
  2. 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.
  3. 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.

  4. Créez une copie du fichier de configuration client-config.yaml :

    cp client-config.yaml login-config.yaml
    
  5. 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.

  6. 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 :

  1. 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.
  2. Si le fichier gke-oidc-envoy est créé en tant qu'équilibreur de charge interne, exposez-le sur votre VPC.
  3. 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.

  1. 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"]
    
  2. Appliquez le fichier manifeste ClusterRole :

    kubectl apply -f secret-viewer-cluster-role.yaml
    
  3. 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.
  4. 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.

  1. Téléchargez le fichier login-config.yaml fourni par votre administrateur.

  2. 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
    
  3. 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.

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