Configurer le contrôle d'accès basé sur les rôles (RBAC)

L'authentification est souvent combinée avec le contrôle des accès basé sur les rôles (RBAC) de Kubernetes afin de fournir un contrôle d'accès plus précis aux clusters pour les utilisateurs authentifiés et les comptes de service. Il est recommandé de créer des stratégies RBAC qui utilisent des noms de groupe plutôt que des identifiants d'utilisateur. En associant explicitement vos stratégies RBAC à des groupes, vous pouvez gérer entièrement les droits d'accès des utilisateurs avec votre fournisseur d'identité. Ainsi, le cluster n'a pas besoin d'être mis à jour chaque fois que les privilèges utilisateur sont modifiés. Notez que pour configurer le contrôle des accès basé sur l'appartenance à des groupes de sécurité, vous devez vous assurer que GKE Identity Service est configuré de manière à obtenir les informations d'appartenance aux groupes auprès de votre fournisseur d'identité.

Exemple

Si vous souhaitez que certains utilisateurs authentifiés aient accès aux pods du cluster, créez un ClusterRole accordant l'accès à ces ressources, comme dans l'exemple suivant :

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pod-reader
rules:
- apiGroups: [""]
  # The resource type for which access is granted
  resources: ["pods"]
  # The permissions granted by the ClusterRole
  verbs: ["get", "watch", "list"]

Vous créez ensuite un ClusterRoleBinding correspondant pour accorder les autorisations dans le ClusterRole aux utilisateurs concernés (dans ce cas, les membres du groupe de sécurité us-east1-cluster-admins et l'utilisateur ayant l'ID u98523-4509823) :

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-pods-admins
subjects:
  # Grants anyone in the "us-east1-cluster-admins" group
  # read access to Pods in any namespace within this cluster.
- kind: Group
  name: gid-us-east1-cluster-admins # Name is case-sensitive
  apiGroup: rbac.authorization.k8s.io
  # Grants this specific user read access to Pods in any
  # namespace within this cluster
- kind: User
  name: uid-u98523-4509823
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Remarque : Si votre fournisseur d'identité renvoie un nom de groupe contenant des caractères de type "barre oblique inverse", l'un de ces caractères doit être omis lorsque vous faites référence au nom du groupe dans la ressource ClusterRoleBinding. Par exemple, si vous avez créé un groupe nommé corp\\my-group, référencez-le dans la ressource ClusterRoleBinding sous le nom corp\my-group. En effet, la première barre oblique inverse est traitée comme un caractère d'échappement.

Dans l'exemple suivant, ce ClusterRoleBinding accorde les autorisations du ClusterRole au groupe concerné associé à l'ID 12345678-BBBb-cCCCC-0000-123456789012. Notez que ce paramètre n'est pertinent que pour les fournisseurs Azure AD et qu'il est disponible pour les clusters Google Distributed Cloud.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: pod-reader-binding
subjects:
  # Retrieves group information for the group ID mentioned
- kind: Group
  name: 12345678-BBBb-cCCCC-0000-123456789012
  apiGroup: rbac.authorization.k8s.io

Pour en savoir plus sur l'utilisation de l'autorisation RBAC, consultez les pages Configurer le contrôle des accès basé sur les rôles et Utiliser l'autorisation RBAC.

Créer un rôle RBAC pour l'accès à la console Google Cloud

Les utilisateurs authentifiés à l'aide de fournisseurs OIDC peuvent se connecter aux clusters depuis la console Google Cloud ainsi qu'à partir de la ligne de commande.

Les utilisateurs authentifiés qui souhaitent accéder aux ressources d'un cluster dans la console Google Cloud doivent disposer des autorisations Kubernetes appropriées. Si vous ne souhaitez pas accorder à ces utilisateurs des autorisations plus étendues, telles que celles d'un administrateur de cluster, vous pouvez créer un rôle RBAC personnalisé qui inclut les autorisations minimales requises pour afficher les nœuds, les volumes persistants, les pods et les classes de stockage du cluster. Vous pouvez définir cet ensemble d'autorisations en créant une ressource ClusterRole RBAC (cloud-console-reader) dans le cluster.

cloud-console-reader accorde à ses utilisateurs les autorisations get, list et watch sur les nœuds, les volumes persistants, les pods et les classes de stockage du cluster, ce qui leur permet d'afficher des informations détaillées sur ces ressources.

kubectl

Pour créer le ClusterRole cloud-console-reader et l'appliquer au cluster, exécutez la commande suivante :

cat <<EOF > cloud-console-reader.yaml
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: cloud-console-reader
rules:
- apiGroups: [""]
  resources: ["nodes", "persistentvolumes", "pods"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["storage.k8s.io"]
  resources: ["storageclasses"]
  verbs: ["get", "list", "watch"]
EOF
kubectl apply -f cloud-console-reader.yaml

Vous pouvez ensuite accorder ce rôle ClusterRole aux utilisateurs lors de la configuration de vos stratégies d'autorisation, comme décrit dans la section précédente. Notez que les utilisateurs ont également besoin d'autorisations IAM pour afficher les clusters dans la console Google Cloud.