Role-Based Access Control (RBAC) für VM-Laufzeit auf GDC

VM-Laufzeit auf GDC verwaltet eine breite Palette von Ressourcen für Ihre VMs. Zu diesen Ressourcen gehören in der Google Kubernetes Engine (GKE) Enterprise-Version definierte Ressourcen, von KubeVirt definierte Ressourcen und Kubernetes-Ressourcen. VM-Laufzeit auf GDC verwendet die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC), um Berechtigungen für verwaltete Ressourcen festzulegen und zu erzwingen. Damit Sie mit diesen Ressourcen arbeiten und Ihre VMs verwalten können, stellen wir vier vorkonfigurierte ClusterRoles bereit:

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

Diese integrierten Rollen bieten ein allgemeines Zugriffsmodell auf die benutzerdefinierten Ressourcen, die mit der VM-Laufzeit auf GDC zusammenhängen. Für jede Rolle sind vorab festgelegte Berechtigungen zum Ausführen der Ressourcen vorhanden. Dieses Dokument enthält Informationen zu Ressourcen, die von VM-Laufzeit auf GDC verwaltet werden, damit Clusteradministratoren ihr eigenes Zugriffsmodell anpassen können.

Vordefinierte ClusterRoles

In diesem Abschnitt werden alle vordefinierten ClusterRoles beschrieben. Diese ClusterRoles sind nur verfügbar, wenn die VM-Laufzeit auf GDC aktiviert ist:

  • Wenn die VM-Laufzeit auf GDC aktiviert ist, werden die vier vordefinierten ClusterRoles automatisch erstellt.
  • Wenn die VM-Laufzeit auf GDC deaktiviert ist, werden die vier vordefinierten ClusterRoles gelöscht.

In der folgenden Tabelle sind die Clusterrollen und die zugehörigen Berechtigungen aufgeführt:

Clusterrolle Beschreibung Auf Verben zugreifen
kubevm.admin Gewährt vollständigen Zugriff auf alle Ressourcen der Google Kubernetes Engine (GKE) Enterprise.
  • get
  • list
  • watch
  • delete
  • create
  • update
  • patch
  • deletecollection
kubevm.edit Gewährt Lese-/Schreibzugriff auf alle Ressourcen der Google Kubernetes Engine (GKE) Enterprise.
  • get
  • list
  • watch
  • delete
  • create
  • update
  • patch
kubevm.view Gewährt Lesezugriff auf alle Ressourcen der Google Kubernetes Engine (GKE) Enterprise.
  • get
  • list
  • watch
kubevm.cluster.view Gewährt Lesezugriff auf clusterbasierte Ressourcen. Diese Clusterrolle ist erforderlich, wenn die Bearbeitungs-/Anzeigerolle an einen Namespace gebunden ist, während Zugriff auf clusterbasierte Ressourcen erforderlich ist.
  • get
  • list
  • watch

Aggregierte ClusterRoles

Die ClusterRoles kubevm.admin, kubevm.view und kubevm.edit werden nicht direkt verwendet. Stattdessen werden diese drei Rollen zu den Kubernetes-Standardclustern admin, view und edit zusammengefasst. Diese Aggregation erweitert die Kubernetes-Standardrollen so, dass sie zum Verwalten von Ressourcen der Google Kubernetes Engine (GKE) Enterprise verwendet werden können. Mit aggregierten ClusterRoles können Sie Kubernetes-Standardrollen verwenden, um den Zugriff auf Ressourcen der Google Kubernetes Engine (GKE) Enterprise-Version zu verwalten, oder eigene Rollen anhand der vordefinierten ClusterRoles erstellen.

Beispiel für ein Aggregationslabel

Die ClusterRole kubevm.edit hat das Label rbac.authorization.k8s.io/aggregate-to-edit: "true", das sie mit der Kubernetes-ClusterRole edit aggregiert. Die Berechtigungen in der ClusterRole kubevm.edit werden der Kubernetes-Standardrolle edit gewährt. Die ClusterRoles kubevm.admin und kubevm.view werden ähnlich mit den Annotationen aggregate-to-admin oder aggregate-to-view aggregiert.

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

Typische Nutzerszenarien

In den folgenden Abschnitten wird beschrieben, wie Sie mit RoleBinding und ClusterRoleBinding einem oder mehreren Nutzern die in den vordefinierten ClusterRoles angegebenen Berechtigungen erteilen.

Clusteradministrator

Wenn Sie einem Nutzer oder einer Gruppe von Nutzern Administratorberechtigungen gewähren möchten, erstellen Sie ein ClusterRoleBinding mit der Kubernetes-StandardclusterRole admin.

Beispiel für ClusterRoleBinding

Im folgenden admin-charlie-ClusterRoleBinding-Beispiel werden dem Nutzer charlie Administratorberechtigungen erteilt. ClusterRoleBinding verwendet Berechtigungen aus der standardmäßigen Kubernetes-ClusterRole admin, die über Aggregation Berechtigungen aus der vordefinierten ClusterRole kubevm.admin umfasst.

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

Clusterbetrachter

Wenn Sie einem Nutzer oder einer Gruppe von Nutzern Betrachterberechtigungen gewähren möchten, erstellen Sie ein ClusterRoleBinding mit der Kubernetes-StandardclusterRole view. Ein ähnliches Beispiel für ClusterRoleBinding finden Sie unter Beispiel für ClusterRoleBinding.

Cluster editor

Wenn Sie einem Nutzer oder einer Gruppe von Nutzern Bearbeitungsberechtigungen gewähren möchten, erstellen Sie ein ClusterRoleBinding mit der Kubernetes-StandardclusterRole edit. Ein ähnliches Beispiel für ClusterRoleBinding finden Sie unter Beispiel für ClusterRoleBinding.

Namespace-Editor

Wenn Sie einem Nutzer oder einer Gruppe von Nutzern Berechtigungen für den Namespace-Editor gewähren möchten, müssen Sie zwei separate Bindungen erstellen:

  • Erstellen Sie eine RoleBinding im Namespace und verweisen Sie auf die Kubernetes-StandardclusterRole edit.

  • Erstellen Sie eine ClusterRoleBinding, die auf die vordefinierte ClusterRole kubevm.cluster.view verweist. Dieses ClusterRoleBinding ist erforderlich, da einige Ressourcen wie virtualmachinetypes und storageclasses keinen Namespace haben.

Beispiele für Rollenbindungen (Namespace-Editor)

In den folgenden Beispielen für RoleBinding und ClusterRoleBinding werden dem Nutzer charlie-Bearbeiterberechtigungen für Ressourcen im Namespace default erteilt:

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

Namespace-Betrachter

Wenn Sie einem Nutzer oder einer Gruppe von Nutzern Namespace-Betrachterberechtigungen gewähren möchten, müssen Sie zwei separate Bindungen erstellen:

  • Erstellen Sie eine RoleBinding im Namespace und verweisen Sie auf die Kubernetes-StandardclusterRole view.

  • Erstellen Sie eine ClusterRoleBinding, die auf die vordefinierte ClusterRole kubevm.cluster.view verweist.

Ähnliche Beispiele für RoleBinding und ClusterRoleBinding finden Sie unter Beispiele für Rollenbindungen (Namespaced-Editor).

Von der VM-Laufzeit in GDC verwendete Ressourcen

Die folgenden Abschnitte enthalten Tabellen mit Ressourcen, die von der VM-Laufzeit auf GDC verwendet werden. Diese Abschnitte dienen nur zu Informationszwecken. Wenn Sie beabsichtigen, vordefinierte Rollen in den typischen Nutzerszenarien, die in den vorherigen Abschnitten beschrieben wurden, zu verwenden, gibt es keine spezifische Verwendung für diese Informationen.

Wenn Sie jedoch keine vordefinierten Rollen verwenden möchten, können Sie anhand dieser Ressourceninformationen Ihre eigenen, benutzerdefinierten Rollen erstellen.

Ressourcen der Google Kubernetes Engine (GKE) Enterprise-Version

Die vordefinierten ClusterRole-Objekte konzentrieren sich auf den Zugriff auf Ressourcen, die in der GKE Enterprise-Version (Google Kubernetes Engine) definiert sind. In der folgenden Tabelle sind die Ressourcen der Google Kubernetes Engine (GKE) Enterprise Edition und die Zugriffsberechtigungen aufgeführt, die durch die einzelnen vordefinierten ClusterRoles gewährt werden.

Ressource Generiert Clusterweise kubevm.admin kubevm.view kubevm.edit kubevm.cluster.view
virtualmachineaccessrequests – – Vollständig Lesen Lesen/Schreiben –
virtualmachinedisks – – Vollständig Lesen Lesen/Schreiben –
virtualmachines – – Vollständig Lesen Lesen/Schreiben –
gpuallocations – – Vollständig Lesen Lesen/Schreiben –
guestenvironmentdata Ja – Vollständig Lesen Lesen/Schreiben –
vmruntimes – Ja Vollständig Lesen Lesen/Schreiben Lesen
virtualmachinetypes – Ja Vollständig Lesen Lesen/Schreiben Lesen
vmhighavailabilitypolicies – Ja Vollständig Lesen Lesen/Schreiben Lesen
networkinterfaces Ja – Vollständig Lesen Lesen/Schreiben –
networks – Ja Vollständig Lesen Lesen/Schreiben Lesen

KubeVirt-Ressourcen

Die VM-Laufzeit auf GDC basiert auf dem Open-Source-Projekt KubeVirt. Standardmäßig werden die Berechtigungen für die KubeVirt-Ressourcen automatisch zu den Kubernetes-Standardrollen zusammengefasst, ähnlich wie bei den von der Google Kubernetes Engine (GKE) Enterprise Edition verwalteten Ressourcen. Wenn Sie eigene benutzerdefinierte Rollen erstellen möchten, verwenden Sie die Ressourceninformationen in der folgenden Tabelle:

Ressource Generiert Clusterweise
virtualmachineinstances/Konsole – –
virtualmachineinstances/VNC – –
virtualmachineinstances/Portweiterleitung – –
virtualmachineinstances/Start – –
virtualmachineinstances/Stopp – –
virtualmachineinstances/Neustart – –
virtualmachines Ja –
virtualmachineinstances Ja –
datavolumes – –
storageprofiles – Ja
cdiconfigs – Ja

Kubernetes-Ressourcen

Wenn Sie mit der VM-Laufzeit auf GDC und VMs arbeiten, müssen Sie möglicherweise den Zugriff auf die folgenden Kubernetes-Ressourcen verwalten. Verwenden Sie die Ressourceninformationen in der folgenden Tabelle, wenn Sie Ihre eigenen, benutzerdefinierten Rollen erstellen möchten:

Ressource Generiert Clusterweise
pods Ja –
services – –
persistentvolumeclaims – –
secrets – –
nodes – Ja
storageclasses – Ja
configmaps – –

Beispiele für ClusterRole-YAML-Dateien

Sie können YAML für ClusterRoles mit dem folgenden kubectl-Befehl abrufen:

kubectl get ClusterRole CLUSTERROLE_NAME -o yaml --kubeconfig KUBECONFIG_PATH

Ersetzen Sie Folgendes:

  • CLUSTERROLE_NAME: der Name der ClusterRole, z. B. kubevm.cluster.view.
  • KUBECONFIG_PATH: der Pfad zur kubeconfig-Datei für den Cluster.

Hier sehen Sie Beispiele der Befehlsausgabe für jede der vier vordefinierten ClusterRoles:

  • 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