Cette page présente le système de contrôle d'accès basé sur les rôles (RBAC) fourni par Kubernetes et explique comment utiliser Kubernetes RBAC dans Google Kubernetes Engine (GKE).
Présentation
Kubernetes comprend un mécanisme intégré de contrôle des accès basé sur les rôles (RBAC). Ce système vous permet de configurer des ensembles d'autorisations ultraprécises pour définir la façon dont un utilisateur ou groupe d'utilisateurs Google Cloud peut interagir avec chaque objet Kubernetes dans un cluster ou dans un espace de noms spécifique au sein du cluster.
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é le SDK Cloud.
Configurez les paramètres gcloud
par défaut à l'aide de l'une des méthodes suivantes :
- Utilisez
gcloud init
pour suivre les instructions permettant de définir les paramètres par défaut. - Utilisez
gcloud config
pour définir individuellement l'ID, la zone et la région de votre projet.
Utiliser gcloud init
Si le message d'erreur One of [--zone, --region] must be supplied: Please specify
location
s'affiche, effectuez les tâches ci-dessous.
-
Exécutez
gcloud init
et suivez les instructions :gcloud init
Si vous utilisez SSH sur un serveur distant, utilisez l'option
--console-only
pour empêcher la commande d'ouvrir un navigateur :gcloud init --console-only
- Suivez les instructions pour autoriser
gcloud
à 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.
Utiliser gcloud config
- Définissez votre ID de projet par défaut :
gcloud config set project PROJECT_ID
- Si vous utilisez des clusters zonaux, définissez votre zone de calcul par défaut :
gcloud config set compute/zone COMPUTE_ZONE
- Si vous utilisez des clusters régionaux, définissez votre région de calcul par défaut :
gcloud config set compute/region COMPUTE_REGION
- Mettez à jour
gcloud
vers la dernière version :gcloud components update
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.
Bien que Kubernetes RBAC puisse être utilisé à la place d'IAM dans presque tous les cas, les utilisateurs de GKE doivent au moins disposer de l'autorisation IAM container.clusters.get
dans le projet contenant le cluster. Cette autorisation est incluse dans le rôle container.clusterViewer
, ainsi que dans les autres rôles les plus privilégié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.
Google Groupes pour GKE
Auparavant, vous ne pouviez attribuer des rôles qu'aux comptes utilisateur Google Cloud ou aux comptes de service IAM. Google Groupes pour GKE (version bêta) vous permet d'attribuer des rôles aux membres d'un groupe Google Groups for Business. Avec ce mécanisme, les utilisateurs et les groupes eux-mêmes sont gérés par les administrateurs Google Workspace, complètement à l'extérieur de Kubernetes ou de Cloud Console. Ainsi, vos administrateurs de cluster n'ont pas besoin d'informations détaillées sur vos utilisateurs. Autre avantage, l'intégration avec vos pratiques de gestion des comptes utilisateur existantes, telles que la révocation d'accès lorsqu'un utilisateur quitte votre organisation.
Pour utiliser cette fonctionnalité, effectuez les tâches suivantes :
- Remplissez les conditions requises.
- Configurez Google Groupes.
- Créez un cluster avec la fonctionnalité activée.
- Associez les groupes Google Groupes à des ensembles d'autorisations de cluster.
Exigences
L'utilisation de Google Groupes pour GKE implique les exigences suivantes :
- Vous devez disposer d'un abonnement à Google Workspace ou à Cloud Identity.
Configurer Google Groupes pour une utilisation avec RBAC
La configuration de votre cluster pour l'utilisation de cette fonctionnalité et la syntaxe permettant de référencer un groupe Google dans Kubernetes RBAC sont détaillées plus bas sur cette page. Tout d'abord, vous devez configurer Google Groupes en procédant comme suit :
Dans votre domaine, créez un groupe Google nommé
gke-security-groups@yourdomain.com
. Le nom du groupe doit être exactementgke-security-groups
. Assurez-vous que le groupegke-security-groups
dispose de l'autorisation "Afficher la liste des membres" pour les "Membres du groupe". Consultez cet article pour découvrir comment définir ce paramètre dans la console d'administration Google Workspace.Vous pouvez également consulter le Centre d'aide Google Groupes pour en savoir plus sur la gestion des groupes dans Google Workspace.
S'ils n'existent pas déjà, créez des groupes qui représentent des groupes d'utilisateurs ou des groupes devant disposer d'autorisations différentes sur vos clusters. Chaque groupe doit disposer de l'autorisation "Afficher les membres" pour les "Membres du groupe".
Ajoutez ces groupes (pas les utilisateurs) comme membres de
gke-security-groups@yourdomain.com
.
Pour vérifier si un utilisateur donné est autorisé à créer, modifier ou afficher une ressource du cluster selon le groupe auquel il appartient, GKE vérifie si l'utilisateur est membre d'un groupe ayant accès à cette ressource et si ce groupe est membre direct du groupe gke-security-groups
dans votre domaine.
Les informations sur les membres du groupe Google sont mises en cache pendant une courte période. La propagation des modifications de membres de groupe à tous vos clusters peut prendre quelques minutes. En plus de la latence des modifications apportées aux groupes, la mise en cache standard des identifiants utilisateur sur le cluster dure environ une heure.
Configurer votre cluster pour utiliser Google Groupes pour GKE
Une fois que votre administrateur Google Groupes a configuré vos groupes, créez un cluster à l'aide de la commande gcloud
et ajoutez l'option --security-group="gke-security-groups@yourdomain.com"
en utilisant votre propre nom de domaine.
Voici un exemple de commande de création de cluster :
gcloud beta container clusters create cluster-name \
--security-group="gke-security-groups@yourdomain.com"
Vous êtes maintenant prêt à créer des objets Role, ClusterRole, RoleBinding et ClusterRoleBinding qui font référence à vos groupes Google.
Définir et attribuer des autorisations
Vous définissez vos autorisations RBAC en créant les types d’objets Kubernetes suivants :
- ClusterRole ou Role : définissent un ensemble de types de ressources et d'opérations pouvant être affectés à un utilisateur ou à un groupe d'utilisateurs au sein d'un cluster (ClusterRole) ou d'un espace de noms (Role), mais ne spécifient pas l'utilisateur ou le groupe d'utilisateurs.
- ClusterRoleBinding ou RoleBinding : attribuent un objet ClusterRole ou Role à un utilisateur ou à un groupe d'utilisateurs. Un objet ClusterRoleBinding fonctionne avec un objet ClusterRole, et un objet RoleBinding avec un objet ClusterRole ou Role.
Les rôles RBAC sont uniquement de nature "additive" : ils n'impliquent aucune règle de "refus". Lors de la structuration de vos rôles RBAC, votre objectif est le suivant : accorder aux utilisateurs l'accès aux ressources du cluster.
Définir des autorisations à l'aide d'un objet Role ou ClusterRole
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 l'espace de noms, le type de ressource 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
:
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
namespace: accounting
name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
resources: ["pods"]
verbs: ["get", "watch", "list"]
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 (version bêta) sur un domaine validé | Group |
Adresse e-mail d'un groupe Google Groupes, qui est lui-même membre du groupe Google Groupes gke-security-groups@yourdomain.com |
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-123456.google.com.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 GKE, google groups
apparaît dans le message de journal.
Problèmes de débogage liés à l'intégration de Google Groupes
Les instructions suivantes vous permettent d'afficher les journaux pour vérifier si vos clusters ont été correctement configurés pour utiliser Google Groupes dans les objets RoleBinding RBAC.
Prérequis
Avant de commencer à examiner les journaux, vérifiez les points suivants :
- Vous n'avez pas interagi avec le cluster que vous souhaitez tester (par exemple, vous n'avez pas exécuté de commandes
kubectl
) pendant au moins une heure. L'authentification est mise en cache pendant une heure et vous devez vous assurer que la requête est enregistrée à ce moment-là. - Vous êtes membre d'au moins un des groupes inclus dans
gke-security-groups
. Cela garantit que certaines informations Google Groupes sont renseignées dans les journaux.
Configurer des journaux
Pour utiliser les journaux pour le débogage de Google Groupes avec RBAC :
Activez la journalisation de l'accès aux données pour votre projet Google Cloud. Pour activer la journalisation, procédez comme suit :
Dans Cloud Console, accédez à la page Journaux d'audit dans le menu IAM.
Dans le tableau, sélectionnez API Kubernetes Engine.
Dans le menu Type de journal, sélectionnez :
- Lecture administrateur
- Lecture de données
- Écriture de données
Cliquez sur Enregistrer.
Pour en savoir plus sur l'activation des journaux d'audit, consultez la section Configurer des journaux d'accès aux données avec Cloud Console dans la documentation des outils de gestion Cloud.
Exécutez une commande à l'aide de
kubectl
dans le cluster. Cela peut être simplementkubectl create ns helloworld
.Saisissez une requête personnalisée sur la page Visionneuse de journaux. Pour exécuter la requête, procédez comme suit :
Dans Cloud Console, accédez à la page Visionneuse de journaux du menu Journalisation.
Cliquez sur la flèche dans le champ Aperçu de la requête en haut de la page.
Dans la liste déroulante qui s'affiche, copiez et collez la requête suivante :
resource.type="k8s_cluster" resource.labels.location="cluster-region" resource.labels.cluster_name="cluster-name" protoPayload.resourceName="authorization.k8s.io/v1beta1/subjectaccessreviews" protoPayload.response.spec.user="email-address"
Où :
- cluster-region est la région ou la zone de votre cluster.
- cluster-name est le nom du cluster.
- email-address est l'adresse e-mail enregistrée de votre compte Google.
Sélectionnez Exécuter la requête. Au moins un résultat doit s'afficher. Si ce n'est pas le cas, essayez d'élargir la période.
Sélectionnez le cluster que vous souhaitez examiner.
Cliquez sur Développer les champs imbriqués.
Le champ
protoPayload.request.spec.group
contient les groupes pour lesquels :- Les groupes sont membres de
gke-security-group
. - Vous êtes membre du groupe.
Cette liste doit correspondre à l'ensemble des groupes dont vous êtes membre. Si aucun groupe n'apparaît, il y a peut-être un problème avec la configuration des groupes.
- Les groupes sont membres de
Restaurez la journalisation de l'accès aux données avec les paramètres précédents pour éviter des frais supplémentaires (si vous le souhaitez).
Limites
Les sections suivantes décrivent des mises en garde relatives à l'utilisation de Kubernetes RBAC.
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
.
Avant la version 1.14 de Kubernetes, les groupes system:authenticated
et system:unauthenticated
accordent tous deux par défaut les objets ClusterRole system:basic-user
et system:discovery
.
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.
À partir de Kubernetes 1.14, les utilisateurs anonymes (system:unauthenticated
) recevront à 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
Étape suivante
- Découvrez comment créer des stratégies IAM.