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 :
- 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
.
- 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.
Pour autoriser une action, GKE recherche d'abord une stratégie RBAC. En l'absence de stratégie RBAC, GKE recherche les autorisations IAM.
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
RoleBinding
ouClusterRoleBinding
. - 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
Role
ouClusterRole
à 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 de 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
Vérifier l'accès à l'API à l'aide de kubectl
kubectl
fournit la sous-commande auth can-i
pour interroger rapidement la couche d'autorisation de l'API. En tant qu'administrateur de plate-forme, vous devrez peut-être emprunter l'identité des utilisateurs pour déterminer les actions qu'ils peuvent effectuer. Vous pouvez utiliser auth can-i
et transmettre une option --as
supplémentaire.
Lorsque vous exécutez la commande kubectl auth can-i
sans l'option --as
, Identity and Access Management (IAM) effectue l'autorisation. En revanche, lorsque vous ajoutez l'option --as
, Kubernetes RBAC effectue l'autorisation. Par conséquent, vous devrez créer les objets Role
et RoleBinding
nécessaires pour RBAC.
Pour en savoir plus, consultez la section Vérifier l'accès à l'API.
Utilisation de l'API et exemples
Pour obtenir des informations complètes sur l'utilisation de l'API Kubernetes lors 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, les journaux du serveur d'API enregistrent 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_EMAIL
Par exemple, le résultat suivant affiche l'ID
uniqueId
pour 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
uniqueId
du 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
escalate
sur 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
bind
sur 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 d'autorisation IAM au lieu du 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.