Ce document décrit les comptes de service dans Google Kubernetes Engine (GKE) et explique comment ils fournissent des identités pour les applications. Vous découvrirez les différents types de comptes de service et quand utiliser chacun d'eux pour authentifier l'accès aux ressources dans GKE sans avoir recours à des identifiants personnels.
Ce document s'adresse aux spécialistes de la sécurité et aux opérateurs qui créent et gèrent des comptes de service pour interagir avec les applications GKE. Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans le contenu Google Cloud , consultez Rôles utilisateur et tâches courantes de GKE.
Les comptes de service Kubernetes et les comptes de service IAM
Le tableau suivant décrit les principales différences entre les comptes de service Kubernetes et les comptes de service IAM :
| Types de comptes de service dans GKE | |
|---|---|
| Compte de service Kubernetes |
|
| Compte de service IAM |
|
Comptes de service Kubernetes
Les comptes de service Kubernetes sont gérés au niveau du cluster et existent sur le serveur d'API Kubernetes en tant qu'objets ServiceAccount. La documentation Kubernetes et la documentation GKE utilisent souvent le terme ServiceAccount pour distinguer ces ressources Kubernetes des comptes de service d'autres environnements tels que IAM.
Vous créez un ServiceAccount Kubernetes dans un espace de noms, puis vous attribuez ce ServiceAccount à un pod à l'aide du champ serviceAccountName du fichier manifeste du pod. Le processus kubelet sur le nœud obtient un jeton de support de courte durée pour le ServiceAccount attribué et installe le jeton en tant que volume projeté dans le pod. Par défaut, ce volume projeté porte un nom qui commence par le préfixe kube-api-access-. Tous les volumes commençant par ce préfixe sont gérés par GKE, ce qui signifie que vous ne pouvez pas modifier leur taille. Pour une surveillance plus précise de l'utilisation du disque, excluez de votre configuration de surveillance les volumes qui commencent par le préfixe kube-api-access-.
Le jeton de support de courte durée est un jeton Web JSON (JWT) signé par le serveur d'API, qui est un fournisseur OpenID Connect (OIDC). Pour valider le jeton de support, obtenez la clé de validation publique du cluster en appelant la méthode projects.locations.clusters.getJwks dans l'API GKE.
- Pour découvrir les principes de base des ServiceAccount Kubernetes, consultez la page Comptes de service dans la documentation de Kubernetes.
- Pour savoir comment créer des ServiceAccount, accorder des autorisations à l'aide du contrôle d'accès basé sur les rôles (RBAC) et attribuer des ServiceAccount aux pods, consultez la page Configurer des comptes de service pour les pods.
- Pour connaître les bonnes pratiques concernant la gestion des ServiceAccount Kubernetes, consultez la section Bonnes pratiques pour le RBAC.
- Pour lire la configuration OIDC du serveur d'API Kubernetes pour un cluster, appelez la méthode
projects.locations.clusters.well-known.getOpenid-configurationdans l'API GKE.
Identifiants de compte de service Kubernetes compromis
Si les identifiants d'un compte de service Kubernetes sont compromis, utilisez l'une des options suivantes pour révoquer les identifiants :
- Recréez vos pods : le jeton de support est lié à chaque UID de pod unique. Par conséquent, la recréation des pods invalide les identifiants précédents.
- Recréer le compte de service Kubernetes : le jeton de support est lié à l'UID de l'objet ServiceAccount dans l'API Kubernetes. Supprimez le ServiceAccount et créez un ServiceAccount portant le même nom. Les jetons précédents ne sont plus valides, car l'UID du nouveau ServiceAccount est différent.
- Mettre en œuvre une rotation des identifiants : cette opération révoque tous les identifiants du compte de service Kubernetes de votre cluster. La rotation modifie également le certificat CA et l'adresse IP de votre cluster. Pour en savoir plus, consultez la section Rotation des identifiants.
Comptes de service IAM
Les comptes de service IAM sont gérés au niveau du projet à l'aide de l'API Cloud IAM. Vous pouvez utiliser ces comptes de service pour effectuer des actions telles que l'appel automatisé des API Google Cloudet la gestion des autorisations pour les applications exécutées dans les produits Google Cloud.
Pour en savoir plus, consultez la présentation des comptes de service IAM.
Agents de service GKE
Un agent de service IAM est un compte de service IAM géré par Google Cloud . GKE utilise les deux agents de service suivants :
Agent de service Kubernetes Engine
GKE utilise l'agent de service de Kubernetes Engine pour gérer le cycle de vie des ressources de cluster en votre nom, telles que les nœuds, les disques et les équilibreurs de charge. Cet agent de service dispose du domaine container-engine-robot.iam.gserviceaccount.com et du rôle Agent de service Kubernetes Engine (roles/container.serviceAgent) sur votre projet lorsque vous activez l'API GKE.
L'identifiant de cet agent de service est le suivant :
service-CLUSTER_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com
CLUSTER_PROJECT_NUMBER est le numéro de projet (numérique) du projet qui contient votre cluster GKE.
Agent de service de nœud par défaut Kubernetes Engine
GKE utilise l'agent de service de nœud par défaut Kubernetes Engine pour prendre en charge la journalisation et la surveillance des nœuds Kubernetes pour les clusters utilisant Kubernetes 1.33 et versions ultérieures. Cet agent de service dispose du domaine gcp-sa-gkenode.iam.gserviceaccount.com et du rôle Agent de service de nœud par défaut Kubernetes Engine (roles/container.defaultNodeServiceAgent) sur votre projet lorsque vous activez l'API GKE.
L'identifiant de cet agent de service est le suivant :
service-CLUSTER_PROJECT_NUMBER@gcp-sa-gkenode.iam.gserviceaccount.com
CLUSTER_PROJECT_NUMBER est le numéro de projet (numérique) du projet qui contient votre cluster GKE.
Si vous supprimez les autorisations de l'agent de service dans votre projet, vous pouvez les récupérer en suivant les instructions de la section Erreur 400/403 : autorisations de modification manquantes sur le compte.
Comptes de service de nœud
GKE utilise des comptes de service IAM associés à vos nœuds pour exécuter des tâches système telles que la journalisation et la surveillance. Au minimum, ces comptes de service de nœud doivent disposer du rôle Compte de service de nœud par défaut Kubernetes Engine (roles/container.defaultNodeServiceAccount) sur votre projet. Par défaut, GKE utilise le compte de service Compute Engine par défaut, qui est créé automatiquement dans votre projet, en tant que compte de service de nœud.
Si votre organisation applique la contrainte de règle d'administration iam.automaticIamGrantsForDefaultServiceAccounts, il est possible que le compte de service Compute Engine par défaut de votre projet n'obtienne pas automatiquement les autorisations requises pour GKE.
Si vous utilisez le compte de service Compute Engine par défaut pour d'autres fonctions dans votre projet ou votre organisation, il est possible qu'il dispose de plus d'autorisations que nécessaire pour GKE, ce qui peut vous exposer à des risques de sécurité.
Ne désactivez pas le compte de service Compute Engine par défaut, sauf si vous effectuez une migration vers des comptes de service gérés par l'utilisateur.
Adresses e-mail des comptes de service des nœuds
L'adresse e-mail de votre compte de service de nœud dépend du type de compte de service, comme suit :
Compte de service Compute Engine par défaut :
CLUSTER_PROJECT_NUMBER-compute@developer.gserviceaccount.comRemplacez
CLUSTER_PROJECT_NUMBERpar le numéro du projet contenant votre cluster, par exemple1234567890.Compte de service personnalisé :
SERVICE_ACCOUNT_NAME@SERVICE_ACCOUNT_PROJECT_ID.iam.gserviceaccount.comRemplacez les éléments suivants :
SERVICE_ACCOUNT_NAME: nom du compte de service.SERVICE_ACCOUNT_PROJECT_ID: ID du projet Google Cloud contenant le compte de service.
Comptes de service de nœud et agents de service de projet
Lorsque vous créez un cluster ou un pool de nœuds, les agents de service du projet de cluster utilisent le compte de service associé aux nœuds pour effectuer des tâches telles que l'extraction d'images. Par défaut, les agents de service du projet de cluster ont les accès suivants aux comptes de service de nœud de ce projet :
- L'agent de service Compute Engine d'un projet peut créer des jetons d'accès pour les comptes de service de nœud du même projet.
- L'agent de service GKE d'un projet peut emprunter l'identité des comptes de service de nœud du même projet.
Certaines organisations utilisent un projet dédié pour gérer tous les comptes de service. Si le compte de service de votre nœud ne se trouve pas dans le projet de votre cluster, les agents de service du projet de cluster ne peuvent pas créer de jetons ni emprunter l'identité de ce compte de service. Vous devez attribuer les rôles suivants aux agents de service de votre projet de cluster sur le compte de service :
- Créateur de jetons du compte de service (
roles/iam.serviceAccountTokenCreator) sur le compte de service de l'agent de service Compute Engine dans votre projet de cluster. - Utilisateur du compte de service (
roles/iam.serviceAccountUser) sur le compte de service de l'agent de service GKE dans le projet de votre cluster.
Pour en savoir plus, consultez Configurer l'utilisation des comptes de service dans plusieurs projets.
Quand utiliser un compte de service spécifique
Le type de compte de service que vous utilisez dépend du type d'identité que vous souhaitez fournir à vos applications, comme suit :
- Fournissez une identité à vos pods à utiliser dans le cluster : utilisez un ServiceAccount Kubernetes. Chaque espace de noms Kubernetes possède un ServiceAccount
default, mais nous vous recommandons de créer des ServiceAccount dotés de privilèges minimaux pour chaque charge de travail de chaque espace de noms. - Fournissez une identité que vos pods doivent utiliser en dehors du cluster : utilisez la fédération d'identité de charge de travail pour GKE. La fédération d'identité de charge de travail pour GKE vous permet de spécifier des ressources Kubernetes telles que des ServiceAccount en tant que comptes principaux dans les stratégies IAM. Par exemple, utilisez la fédération d'identité de charge de travail pour GKE lorsque vous appelez des API Google Cloud telles que Secret Manager ou Spanner à partir de vos pods.
- Fournissez une identité par défaut pour vos nœuds : utilisez un compte de service IAM personnalisé à droits minimaux lorsque vous créez vos clusters ou nœuds GKE. Si vous n'utilisez pas de compte de service IAM personnalisé, GKE utilise le compte de service Compute Engine par défaut.
Étapes suivantes
- Découvrez comment utiliser les comptes de service Google dotés de privilèges minimaux.
- Découvrez comment attribuer un rôle à un compte principal.