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

L'environnement d'exécution des VM Anthos gère un large éventail de ressources liées à vos VM. Ces ressources incluent les ressources définies par Anthos, les ressources définies par KubeVirt et les ressources Kubernetes. L'environnement d'exécution des VM Anthos utilise un contrôle d'accès basé sur les rôles (RBAC) pour définir et appliquer des autorisations aux 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 Anthos. 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 des VM Anthos 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 objets ClusterRole ne sont disponibles que lorsque l'environnement d'exécution des VM Anthos est activé:

  • Lorsque l'environnement d'exécution des VM Anthos est activé, les quatre objets ClusterRole prédéfinis sont automatiquement créés.
  • Lorsque l'environnement d'exécution des VM Anthos 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 Anthos.
  • get
  • list
  • watch
  • delete
  • create
  • update
  • patch
  • deletecollection
kubevm.edit Accorde un accès en lecture/écriture à toutes les ressources Anthos.
  • get
  • list
  • watch
  • delete
  • create
  • update
  • patch
kubevm.view Accorde un accès en lecture à toutes les ressources Anthos.
  • 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 Anthos. Avec les ClusterRoles agrégés, vous pouvez utiliser les rôles Kubernetes par défaut pour gérer l'accès aux ressources Anthos 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 Anthos

Les sections suivantes contiennent des tableaux de ressources utilisées par l'environnement d'exécution des VM Anthos. 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 par Anthos

Les objets ClusterRole prédéfinis se concentrent sur l'accès aux ressources définies par Anthos. Le tableau suivant répertorie les ressources Anthos et les autorisations d'accès accordées par chacun des objets ClusterRole 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 Yes – Complète Read Lecture/Écriture –
vmruntimes – Yes Complète Read Lecture/Écriture Read
virtualmachinetypes – Yes Complète Read Lecture/Écriture Read
vmhighavailabilitypolicies – Yes Complète Read Lecture/Écriture Read
networkinterfaces Yes – Complète Read Lecture/Écriture –
networks – Yes Complète Read Lecture/Écriture Read

Ressources KubeVirt

L'environnement d'exécution des VM Anthos est basé sur le projet Open Source KubeVirt. Par défaut, les autorisations pour les ressources KubeVirt sont automatiquement agrégées aux rôles Kubernetes par défaut, similaires aux ressources gérées par Anthos. 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 Yes –
virtualmachineinstances Yes –
datavolumes – –
storageprofiles – Yes
cdiconfigs – Yes

Ressources Kubernetes

Lorsque vous utilisez l'environnement d'exécution des VM Anthos et des VM Anthos, 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 Yes –
services – –
persistentvolumeclaims – –
secrets – –
nodes – Yes
storageclasses – Yes
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