Cette page explique comment autoriser des actions sur les ressources de vos clusters Google Kubernetes Engine (GKE) à l'aide du mécanisme intégré de contrôle des accès basé sur les rôles (RBAC) dans Kubernetes.
RBAC est une fonctionnalité de sécurité de base de Kubernetes qui vous permet de créer des autorisations précises pour gérer les actions que les utilisateurs et les charges de travail peuvent effectuer sur les ressources de vos clusters. En tant qu'administrateur de plate-forme, vous créez des rôles RBAC et associez ces rôles à des objets, qui sont des utilisateurs authentifiés, tels que des comptes de service ou des groupes. Le contrôle Kubernetes RBAC est activé par défaut.
Avant de commencer
Avant de commencer, effectuez les tâches suivantes :
- Assurez-vous d'avoir activé l'API Google Kubernetes Engine. Activer l'API Google Kubernetes Engine
- Assurez-vous d'avoir installé Google Cloud CLI.
- Configurez les paramètres par défaut de Google Cloud CLI pour votre projet en utilisant l'une des méthodes suivantes :
- Utilisez
gcloud initsi vous souhaitez suivre les étapes de définition des paramètres par défaut du projet. - Utilisez
gcloud configpour définir individuellement l'ID, la zone et la région de votre projet. -
Exécutez
gcloud initet suivez les instructions :gcloud init
Si vous utilisez SSH sur un serveur distant, utilisez l'option
--console-onlypour empêcher la commande d'ouvrir un navigateur :gcloud init --console-only
- Suivez les instructions pour autoriser gcloud CLI à utiliser votre compte Google Cloud.
- Créez ou sélectionnez une configuration.
- Choisissez un projet Google Cloud.
- Choisissez une zone Compute Engine par défaut.
- Choisissez une région Compute Engine par défaut.
- Définissez votre ID de projet par défaut :
gcloud config set project PROJECT_ID
- Définissez votre région Compute Engine par défaut (par exemple,
us-central1) :gcloud config set compute/region COMPUTE_REGION
- Définissez votre zone Compute Engine par défaut (par exemple,
us-central1-c) :gcloud config set compute/zone COMPUTE_ZONE
- Mettez à jour
gcloudvers la dernière version :gcloud components update
gcloud init
gcloud config
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.
- Consultez la page Bonnes pratiques pour GKE RBAC pour savoir comment améliorer la conception de vos stratégies RBAC.
Interagir avec la gestion de l'authentification et des accès
Vous pouvez contrôler l'accès à votre cluster GKE à l'aide d'Identity and Access Management (IAM) et de Kubernetes RBAC :
IAM n'est pas spécifique à Kubernetes. Cette solution fournit des fonctions de gestion des identités pour de nombreux produits Google Cloud et fonctionne principalement au niveau du projet Google Cloud.
Kubernetes RBAC est un composant essentiel de Kubernetes qui vous permet de créer et d’attribuer des rôles (ensembles d’autorisations) à tout objet ou type d’objet au sein d'un cluster.
Dans GKE, IAM et Kubernetes RBAC sont intégrés pour permettre aux utilisateurs d'effectuer des actions s’ils disposent des autorisations suffisantes selon chaque outil. C'est un élément important pour l'amorçage d'un cluster GKE, car par défaut, les utilisateurs Google Cloud ne disposent pas d'autorisation Kubernetes RBAC associée à des rôles (RoleBindings).
Pour autoriser des utilisateurs de comptes Google Cloud, le client doit d'abord être correctement configuré pour s'authentifier à l'aide de ces comptes. Par exemple, si vous utilisez kubectl, vous devez configurer la commande kubectl pour vous authentifier auprès de Google Cloud avant d'exécuter des commandes nécessitant une autorisation.
Dans presque tous les cas, Kubernetes RBAC peut être utilisé à la place d'IAM.
Les utilisateurs de GKE nécessitent au minimum l'autorisation IAM container.clusters.get dans le projet qui contient le cluster.
Cette autorisation est incluse dans le rôle container.clusterViewer ainsi que dans d'autres rôles disposant de privilèges plus élevés. L'autorisation container.clusters.get est requise pour que les utilisateurs puissent s'authentifier auprès des clusters du projet, mais ne les autorise à effectuer aucune action dans ces clusters. L'autorisation peut alors être fournie par IAM ou Kubernetes RBAC.
Définir et attribuer des autorisations
Vous pouvez définir des règles RBAC dans les objets ClusterRole et Role, puis les attribuer avec les objets ClusterRoleBinding et RoleBinding comme suit :
- ClusterRole : regroupement au niveau du cluster de ressources et d'opérations autorisées que vous pouvez attribuer à un utilisateur ou à un groupe à l'aide d'une liaison
RoleBindingouClusterRoleBinding. - Role : regroupement d'espace de noms de ressources et d'opérations autorisées pouvant être attribuées à un utilisateur ou à un groupe d'utilisateurs à l'aide d'une liaison
RoleBinding. - ClusterRoleBinding : attribuez un rôle
ClusterRoleà un utilisateur ou à un groupe pour tous les espaces de noms du cluster. - RoleBinding : attribuez un rôle
RoleouClusterRoleà un utilisateur ou à un groupe au sein d'un espace de noms spécifique.
Lorsque vous utilisez une liaison RoleBinding pour attribuer un rôle ClusterRole à un utilisateur ou à un groupe, ces utilisateurs et groupes ne peuvent accéder qu'aux ressources de l'espace de noms que vous spécifiez dans la liaison RoleBinding. Si vous souhaitez que les utilisateurs ou les groupes accèdent aux ressources sur tous les espaces de noms, utilisez plutôt une liaison ClusterRoleBinding.
Définir des autorisations à l'aide de Roles ou de ClusterRoles
Vous définissez des autorisations dans un objet Role ou ClusterRole. Un objet Role définit l'accès aux ressources dans un seul espace de noms, tandis qu'un objet ClusterRole définit l'accès aux ressources dans l'ensemble du cluster.
Les objets Role et ClusterRole ont la même syntaxe. Chacun comporte une section rules dans laquelle vous définissez les ressources auxquelles la règle s'applique et les opérations autorisées pour le rôle. Par exemple, l'objet Role suivant accorde un accès en lecture (get, watch et list) à tous les pods de l'espace de noms accounting :
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: accounting
name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
resources: ["pods"]
verbs: ["get", "watch", "list"]
Reportez-vous à la documentation sur l'API Role et ClusterRole pour obtenir la liste complète des champs autorisés.
Role vs ClusterRole
Sachant que les autorisations ClusterRole s'appliquent à l'ensemble du cluster, elles peuvent servir à contrôler l'accès à des types de ressources différents de ceux contrôlables avec un objet Role, y compris :
- Ressources à l'échelle du cluster, telles que les nœuds
- Points de terminaison REST hors ressources, tels que
/healthz - Ressources en espace de noms sur tous les espaces de noms (par exemple, tous les pods de l'ensemble du cluster, quel que soit l'espace de noms)
Attribuer des rôles avec RoleBinding ou ClusterRoleBinding
Après avoir créé un objet Role ou ClusterRole, vous l'attribuez à un utilisateur ou à un groupe d'utilisateurs en créant un objet RoleBinding ou ClusterRoleBinding. Les utilisateurs et les groupes sont appelés subjects et peuvent être l’un des éléments suivants :
| Type d'objet | Valeur de kind |
Valeur de name |
|---|---|---|
| Compte utilisateur Google Cloud | User |
Adresse e-mail enregistrée dans Google Cloud |
| Compte de service Kubernetes | ServiceAccount |
Nom d'un objet Kubernetes ServiceAccount dans le cluster |
| Compte de service IAM | User |
Adresse e-mail du compte de service IAM générée automatiquement |
| Adresse du groupe Google sur un domaine validé | Group |
Adresse e-mail d'un groupe Google Workspace membre du groupe gke-security-groups. Pour obtenir des instructions sur la configuration de Google Groupes pour RBAC, consultez la page Configurer Google Groupes pour RBAC. |
L'objet RoleBinding suivant attribue le rôle pod-reader à un utilisateur, à un compte de service Kubernetes, à un compte de service IAM et à un groupe Google Groupes :
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: pod-reader-binding
namespace: accounting
subjects:
# Google Cloud user account
- kind: User
name: janedoe@example.com
# Kubernetes service account
- kind: ServiceAccount
name: johndoe
# IAM service account
- kind: User
name: test-account@test-project.iam.gserviceaccount.com
# Google Group
- kind: Group
name: accounting-group@example.com
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.io
Utilisation de l'API et exemples
Pour obtenir des informations complètes sur l'utilisation de l'API Kubernetes dans le cadre de la création des objets Role, ClusterRole, RoleBinding et ClusterRoleBinding nécessaires pour le contrôle RBAC, consultez la section Utiliser l'autorisation de contrôle des accès basé sur les rôles de la documentation de Kubernetes.
Dépannage et débogage
Pour déboguer les problèmes liés à RBAC, utilisez le journal d'audit des activités d'administration, qui est activé par défaut sur tous les clusters. Si l'accès à une ressource ou à une opération est refusé en raison d'autorisations insuffisantes, le serveur d'API enregistre une erreur RBAC DENY, ainsi que des informations supplémentaires telles que l'appartenance implicite et explicite de l'utilisateur à un groupe. Si vous utilisez Google Groupes pour RBAC, google groups apparaît dans le message de journal.
Limites
Les sections suivantes décrivent des mises en garde concernant l'utilisation de Kubernetes RBAC et d'IAM.
Rôles de découverte par défaut
Les clusters sont créés avec un ensemble de ClusterRoles et ClusterRoleBindings par défaut.
Les requêtes effectuées avec des identifiants valides sont placées dans le groupe system:authenticated, tandis que toutes les autres requêtes appartiennent à system:unauthenticated.
Le ClusterRole system:basic-user permet aux utilisateurs de faire en sorte que SelfSubjectAccessReviews teste leurs autorisations dans le cluster. Le rôle system:discovery permet aux utilisateurs de lire les API de découverte, qui peuvent révéler des informations sur les définitions de ressources personnalisées (CustomResourceDefinitions) ajoutées au cluster.
Les utilisateurs anonymes (system:unauthenticated) reçoivent à la place le ClusterRole system:public-info-viewer, qui accorde un accès en lecture seule aux API /healthz et /version.
Pour afficher les points de terminaison d'API autorisés par le ClusterRole system:discovery, exécutez la commande suivante :
kubectl get clusterroles system:discovery -o yaml
Erreur Forbidden pour les comptes de service sur les instances de VM Google Cloud
L'erreur suivante peut se produire lorsque l'instance de VM ne dispose pas du niveau d'accès userinfo-email :
Error from server (Forbidden): error when creating ... "role-name" is forbidden: attempt to grant extra privileges:...
Supposons par exemple que la VM dispose du niveau d'accès cloud-platform, et non du niveau d'accès userinfo-email. Lorsque la VM obtient un jeton d'accès, Google Cloud associe ce jeton au niveau d'accès cloud-platform. Lorsque le serveur de l'API Kubernetes demande à Google Cloud l'identité associée au jeton d'accès, il reçoit l'ID unique du compte de service, et non l'adresse e-mail du compte de service.
Pour effectuer l'authentification, créez une VM avec le niveau d'accès userinfo-email ou créez une liaison de rôle utilisant l'ID unique.
Pour créer une instance de VM avec le niveau d'accès userinfo-email, exécutez la commande suivante :
gcloud compute instances create INSTANCE_NAME \
--service-account SERVICE_ACCOUNT_EMAIL \
--scopes userinfo-email
Pour créer une liaison de rôle utilisant l'ID unique d'un compte de service pour une VM existante, procédez comme suit :
Identifiez l'ID unique du compte de service :
gcloud iam service-accounts describe SERVICE_ACCOUNT_EMAILPar exemple, le résultat suivant affiche l'ID
uniqueIdpour le compte de servicemy-iam-account@somedomain.com:displayName: Some Domain IAM service account email: my-iam-account@somedomain.com etag: BwWWja0YfJA name: projects/project-name/serviceAccounts/my-iam-account@somedomain.com oauth2ClientId: '123456789012345678901' projectId: project-name uniqueId: '123456789012345678901'Créez une liaison de rôle à l'aide de l'ID
uniqueIddu compte de service :kubectl create clusterrolebinding CLUSTERROLEBINDING_NAME \ --clusterrole cluster-admin \ --user UNIQUE_ID
Autorisation de créer ou de mettre à jour des rôles et des liaisons de rôles
Dans Kubernetes, vous ne pouvez créer ou mettre à jour un rôle ou une liaison de rôle avec des autorisations spécifiques que si vous remplissez les conditions suivantes :
- Créer ou mettre à jour un rôle : vous devez disposer des mêmes autorisations que celles à attribuer au rôle. Autrement, vous devez être autorisé à exécuter le verbe
escalatesur le rôle. - Créer ou mettre à jour une liaison de rôle : vous devez disposer des mêmes autorisations que celles accordées dans le rôle lié, avec le même niveau d'accès que la liaison de rôle. Autrement, vous devez être autorisé à exécuter le verbe
bindsur le rôle référencé.
Si les autorisations que vous accordez dans le rôle vous ont été initialement accordées à l'aide d'une stratégie IAM au lieu de RBAC, votre demande de rôle ou de liaison de rôle peut échouer. Par exemple, considérons la requête de création de rôle suivante, provenant d'un utilisateur disposant des autorisations IAM container.pods.* et container.roles.create :
kubectl create role allowed-to-view-pods --resource pods --verb list,get
Si l'utilisateur n'a reçu les autorisations qu'en utilisant IAM, l'erreur suivante peut se produire :
Error from server (Forbidden): clusterroles.rbac.authorization.k8s.io "allowed-to-view-pods" is forbidden:
user "caller@example.com" (groups=["system:authenticated"]) is attempting to grant RBAC permissions not currently held:
{APIGroups:[""], Resources:["pods"], Verbs:["list" "get"]}
Pour contourner cette limitation, accordez à l'appelant les autorisations du rôle en utilisant RBAC au lieu d'IAM.
Vous pouvez également utiliser RBAC ou IAM pour accorder à l'appelant le verbe escalate, le verbe bind ou les deux. Toutefois, GKE ne recommande pas cette approche, car l'appelant peut ensuite accorder n'importe quelle autorisation à n'importe quel rôle.
Étapes suivantes
- Découvrez comment créer des stratégies IAM.
- Apprenez à configurer Google Groupes pour RBAC.