Contrôle des accès basé sur les rôles (RBAC) pour l'environnement d'exécution des VM dans GDC

L'environnement d'exécution des VM sur GDC gère un large éventail de ressources liées à vos VM. Ces ressources incluent les ressources définies par l'édition Google Kubernetes Engine (GKE) Enterprise, celles définies par KubeVirt et les ressources Kubernetes. L'environnement d'exécution de VM sur GDC utilise le contrôle des accès basé sur les rôles (RBAC) pour définir et appliquer des autorisations pour les ressources gérées. Pour vous aider à utiliser ces ressources et à gérer vos VM, nous vous proposons quatre ClusterRoles préconfigurés:

  • kubevm.admin
  • kubevm.edit
  • kubevm.view
  • kubevm.cluster.view

Ces rôles intégrés fournissent un modèle d'accès généralisé aux ressources personnalisées liées à l'environnement d'exécution des VM sur GDC. Chaque rôle dispose d'autorisations prédéfinies pour fonctionner sur les ressources. Ce document fournit des informations sur les ressources gérées par l'environnement d'exécution de VM sur GDC afin que les administrateurs de cluster puissent personnaliser leur propre modèle d'accès.

ClusterRoles prédéfinis

Cette section décrit chacun des objets ClusterRole prédéfinis. Ces ClusterRoles ne sont disponibles que lorsque l'environnement d'exécution des VM sur GDC est activé:

  • Lorsque l'environnement d'exécution des VM sur GDC est activé, les quatre ClusterRoles prédéfinis sont créés automatiquement.
  • Lorsque l'environnement d'exécution des VM sur GDC est désactivé, les quatre ClusterRoles prédéfinis sont supprimés.

Le tableau suivant répertorie les rôles de cluster et les autorisations associées:

Rôle de cluster Description Verbes d'accès
kubevm.admin Accorde un accès complet à toutes les ressources de l'édition Google Kubernetes Engine (GKE) Enterprise.
  • get
  • list
  • watch
  • delete
  • create
  • update
  • patch
  • deletecollection
kubevm.edit Accorde un accès en lecture/écriture à toutes les ressources de l'édition Google Kubernetes Engine (GKE) Enterprise.
  • get
  • list
  • watch
  • delete
  • create
  • update
  • patch
kubevm.view Accorde un accès en lecture à toutes les ressources de l'édition Google Kubernetes Engine (GKE) Enterprise.
  • get
  • list
  • watch
kubevm.cluster.view Fournit un accès en lecture aux ressources au niveau du cluster. Ce rôle de cluster est nécessaire lorsque le rôle de modification ou de lecture est lié à un espace de noms, et que l'accès aux ressources par cluster est nécessaire.
  • get
  • list
  • watch

ClusterRoles agrégés

Les objets ClusterRole kubevm.admin, kubevm.view et kubevm.edit ne sont pas utilisés directement. À la place, ces trois rôles sont agrégés vers les objets ClusterRole admin, view et edit par défaut de Kubernetes, respectivement. Cette agrégation étend les rôles Kubernetes par défaut afin qu'ils puissent être utilisés pour gérer les ressources de Google Kubernetes Engine (GKE) de l'édition Enterprise. Avec les ClusterRoles agrégés, vous pouvez utiliser les rôles par défaut de Kubernetes pour gérer l'accès aux ressources de Google Kubernetes Engine (GKE) Enterprise ou créer vos propres rôles basés sur les ClusterRoles prédéfinis.

Exemple de libellé d'agrégation

Le ClusterRole kubevm.edit possède le libellé rbac.authorization.k8s.io/aggregate-to-edit: "true", qui l'agrège dans le ClusterRole edit de Kubernetes. Les autorisations de l'objet ClusterRole kubevm.edit sont accordées au rôle edit par défaut de Kubernetes. Les objets ClusterRole kubevm.admin et kubevm.view sont agrégés de la même manière avec les annotations aggregate-to-admin ou aggregate-to-view.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
    name: kubevm.edit
    labels:
      kubevm: kubevm.edit
      rbac.authorization.k8s.io/aggregate-to-edit: "true"
...

Scénarios d'utilisation typiques

Les sections suivantes décrivent comment utiliser RoleBinding et ClusterRoleBinding pour accorder à un utilisateur ou à un ensemble d'utilisateurs les autorisations spécifiées dans les objets ClusterRole prédéfinis.

Administrateur de cluster

Pour accorder des autorisations d'administrateur à un utilisateur ou à un ensemble d'utilisateurs, créez un objet ClusterRoleBinding avec le ClusterRole admin par défaut de Kubernetes.

Exemple de ClusterRoleBinding

L'exemple de clusterRoleBinding admin-charlie suivant accorde à l'utilisateur les autorisations d'administrateur charlie. ClusterRoleBinding utilise les autorisations du ClusterRole admin Kubernetes par défaut, qui inclut les autorisations de l'objet ClusterRole kubevm.admin prédéfini via l'agrégation.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: admin-charlie
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: charlie

Lecteur de cluster

Pour accorder des autorisations de lecteur à un utilisateur ou à un ensemble d'utilisateurs, créez un objet ClusterRoleBinding avec le rôle ClusterRole view par défaut de Kubernetes. Consultez la section Exemple de ClusterRoleBinding pour obtenir un exemple de ClusterRoleBinding similaire.

Éditeur de cluster

Pour accorder des autorisations d'éditeur à un utilisateur ou à un ensemble d'utilisateurs, créez un objet ClusterRoleBinding avec le ClusterRole edit par défaut de Kubernetes. Consultez la section Exemple de ClusterRoleBinding pour obtenir un exemple de ClusterRoleBinding similaire.

Éditeur d'espace de noms

Pour accorder des autorisations d'éditeur d'espace de noms à un utilisateur ou à un ensemble d'utilisateurs, vous devez créer deux liaisons distinctes:

  • Créez un objet RoleBinding sur l'espace de noms et référencez l'objet ClusterRole Kubernetes par défaut edit.

  • Créez un objet ClusterRoleBinding qui référence l'objet ClusterRole kubevm.cluster.view prédéfini. Cet objet ClusterRoleBinding est nécessaire, car certaines ressources, telles que virtualmachinetypes et storageclasses, ne sont pas liées à un espace de noms.

Exemples de liaisons de rôles (éditeur d'espace de noms)

Les exemples de RoleBinding et de ClusterRoleBinding suivants donnent à l'utilisateur charlie les autorisations d'éditeur pour les ressources de l'espace de noms default:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: edit-charlie
  namespace: default
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: edit
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: charlie

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: kubevm-cluster-view-charlie
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: kubevm.cluster.view
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: charlie

Lecteur d'espaces de noms

Pour accorder des autorisations de lecteur d'espace de noms à un utilisateur ou à un ensemble d'utilisateurs, vous devez créer deux liaisons distinctes:

  • Créez un objet RoleBinding sur l'espace de noms et référencez l'objet ClusterRole Kubernetes par défaut view.

  • Créez un objet ClusterRoleBinding qui référence l'objet ClusterRole kubevm.cluster.view prédéfini.

Consultez la section Exemples de liaison de rôle (éditeur en espace de noms) pour obtenir des exemples d'objets RoleBinding et ClusterRoleBinding similaires.

Ressources utilisées par l'environnement d'exécution des VM sur GDC

Les sections suivantes contiennent des tables de ressources utilisées par l'environnement d'exécution de VM sur GDC. Ces sections sont données uniquement à titre d'information. Si vous envisagez d'utiliser des rôles prédéfinis dans les scénarios d'utilisation types décrits dans les sections précédentes, il n'y a pas d'utilisation spécifique pour ces informations.

Toutefois, si vous ne souhaitez pas utiliser les rôles prédéfinis, vous pouvez utiliser ces informations sur les ressources pour créer vos propres rôles personnalisés.

Ressources définies dans l'édition Google Kubernetes Engine (GKE) Enterprise

Les ClusterRoles prédéfinis se concentrent sur l'accès aux ressources définies par l'édition Google Kubernetes Engine (GKE) Enterprise. Le tableau suivant répertorie les ressources de l'édition Google Kubernetes Engine (GKE) Enterprise et les autorisations d'accès accordées par chacun des ClusterRoles prédéfinis.

Ressource Généré Par cluster kubevm.admin kubevm.view kubevm.edit kubevm.cluster.view
virtualmachineaccessrequests – – Complète Read Lecture/Écriture –
virtualmachinedisks – – Complète Read Lecture/Écriture –
virtualmachines – – Complète Read Lecture/Écriture –
gpuallocations – – Complète Read Lecture/Écriture –
guestenvironmentdata Oui – Complète Read Lecture/Écriture –
vmruntimes – Oui Complète Read Lecture/Écriture Read
virtualmachinetypes – Oui Complète Read Lecture/Écriture Read
vmhighavailabilitypolicies – Oui Complète Read Lecture/Écriture Read
networkinterfaces Oui – Complète Read Lecture/Écriture –
networks – Oui Complète Read Lecture/Écriture Read

Ressources KubeVirt

L'environnement d'exécution des VM sur GDC est basé sur le projet Open Source KubeVirt. Par défaut, les autorisations associées aux ressources KubeVirt sont automatiquement agrégées aux rôles Kubernetes par défaut, à l'instar des ressources gérées de l'édition Google Kubernetes Engine (GKE) Enterprise. Utilisez les informations liées aux ressources du tableau suivant si vous souhaitez créer vos propres rôles personnalisés:

Ressource Généré Par cluster
virtualmachineinstances/console – –
virtualmachineinstances/vnc – –
virtualmachineinstances/portforward – –
virtualmachineinstances/start – –
virtualmachineinstances/stop – –
virtualmachineinstances/restart – –
virtualmachines Oui –
virtualmachineinstances Oui –
datavolumes – –
storageprofiles – Oui
cdiconfigs – Oui

Ressources Kubernetes

Lorsque vous utilisez l'environnement d'exécution des VM sur GDC et sur des VM, vous devrez peut-être gérer l'accès aux ressources Kubernetes suivantes. Utilisez les informations liées aux ressources du tableau suivant si vous souhaitez créer vos propres rôles personnalisés:

Ressource Généré Par cluster
pods Oui –
services – –
persistentvolumeclaims – –
secrets – –
nodes – Oui
storageclasses – Oui
configmaps – –

Exemples YAML ClusterRole

Vous pouvez récupérer le code YAML des objets ClusterRole à l'aide de la commande kubectl suivante:

kubectl get ClusterRole CLUSTERROLE_NAME -o yaml --kubeconfig KUBECONFIG_PATH

Remplacez les éléments suivants :

  • CLUSTERROLE_NAME: nom du ClusterRole, par exemple kubevm.cluster.view.
  • KUBECONFIG_PATH : chemin d'accès au fichier kubeconfig pour le cluster.

Voici des exemples de résultat de commande pour chacun des quatre ClusterRoles prédéfinis:

  • kubevm.admin

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  creationTimestamp: "2022-10-11T21:10:31Z"
  labels:
    kubevm: kubevm.admin
    rbac.authorization.k8s.io/aggregate-to-admin: "true"
  name: kubevm.admin
  resourceVersion: "16654950"
  uid: 3296c279-6e85-4ea6-b250-548bf0c3e935
rules:
- apiGroups:
  - vm.cluster.gke.io
  resources:
  - virtualmachineaccessrequests
  - virtualmachinedisks
  - virtualmachines
  - gpuallocations
  - guestenvironmentdata
  - vmruntimes
  - virtualmachinetypes
  - vmhighavailabilitypolicies
  verbs:
  - get
  - delete
  - create
  - update
  - patch
  - list
  - watch
  - deletecollection
- apiGroups:
  - networking.gke.io
  resources:
  - networkinterfaces
  - networks
  verbs:
  - get
  - delete
  - create
  - update
  - patch
  - list
  - watch
  - deletecollection

  • kubevm.edit

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  creationTimestamp: "2022-10-11T21:10:31Z"
  labels:
    kubevm: kubevm.edit
    rbac.authorization.k8s.io/aggregate-to-edit: "true"
  name: kubevm.edit
  resourceVersion: "16654951"
  uid: 237bf9ae-b2c8-4303-94dc-e6425a2df331
rules:
- apiGroups:
  - vm.cluster.gke.io
  resources:
  - virtualmachineaccessrequests
  - virtualmachinedisks
  - virtualmachines
  - gpuallocations
  - guestenvironmentdata
  - vmruntimes
  - virtualmachinetypes
  - vmhighavailabilitypolicies
  verbs:
  - get
  - delete
  - create
  - update
  - patch
  - list
  - watch
- apiGroups:
  - networking.gke.io
  resources:
  - networkinterfaces
  - networks
  verbs:
  - get
  - delete
  - create
  - update
  - patch
  - list
  - watch

  • kubevm.view

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  creationTimestamp: "2022-10-11T21:10:31Z"
  labels:
    kubevm: kubevm.view
    rbac.authorization.k8s.io/aggregate-to-view: "true"
  name: kubevm.view
  resourceVersion: "16654953"
  uid: b5b54e2d-0097-4698-abbd-aeac212d0a34
rules:
- apiGroups:
  - vm.cluster.gke.io
  resources:
  - virtualmachineaccessrequests
  - virtualmachinedisks
  - virtualmachines
  - gpuallocations
  - guestenvironmentdata
  - vmruntimes
  - virtualmachinetypes
  - vmhighavailabilitypolicies
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - networking.gke.io
  resources:
  - networkinterfaces
  - networks
  verbs:
  - get
  - list
  - watch

  • kubevm.cluster.view

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  creationTimestamp: "2022-10-11T21:10:31Z"
  labels:
    kubevm: kubevm.cluster.view
  name: kubevm.cluster.view
  resourceVersion: "16654956"
  uid: b25dde64-67da-488b-81d2-1a08f9a4a7c1
rules:
- apiGroups:
  - vm.cluster.gke.io
  resources:
  - vmruntimes
  - virtualmachinetypes
  - vmhighavailabilitypolicies
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - networking.gke.io
  resources:
  - networks
  verbs:
  - get
  - list
  - watch