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 :
- 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
.
- Pour autoriser des groupes, utilisez
ISSUER_URI
: URL permettant d'envoyer des requêtes d'autorisation OIDC, telles quehttps://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, utilisezhttps://accounts.google.com
.KUBECTL_REDIRECT_URL
: URL de redirection quekubectl oidc login
utilise pour l'autorisation. Il s'agit généralement du formathttp://localhost:PORT/callback
, oùPORT
est un port supérieur au port1024
qui sera disponible sur les postes de travail des développeurs, par exemplehttp://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 revendicationemail
.
- Microsoft Azure et Okta nécessitent le niveau d'accès
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 champuserID
donné au serveur d'API Kubernetes (sauf si la revendication utilisateur estemail
). L'identifiant utilisateur obtenu estISSUER_URI#USER
. Nous vous recommandons d'utiliser un préfixe, mais vous pouvez le désactiver en définissantUSER_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ésfoobar
, ajoutez un préfixegid-
. Le groupe ainsi obtenu estgid-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 champspec.server
doit être l'adresse IP de l'équilibreur de charge. Si vous modifiez le champspec.server
, les commandeskubectl
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ètreclientSecret
dans la sectionspec.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 validationClientConfig
. - 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éploiementgke-oidc-envoy
de communiquer avec le déploiementgke-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ôlesecret-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 depuisspec.authentication.oidc.issuerURI
dans le fichier de configuration du client.USER
: identifiant d'utilisateur dans le jeton situé sous le nom de revendication configuré dansspec.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.