Rollenbasierte Zugriffssteuerung (RBAC) für die VM-Laufzeit in der Google Datacenter Platform

VM Runtime on GDC verwaltet eine breite Palette von Ressourcen im Zusammenhang mit Ihren VMs. Dazu gehören von der Google Kubernetes Engine (GKE) Enterprise-Version definierte Ressourcen, von KubeVirt definierte Ressourcen und Kubernetes-Ressourcen. Die VM-Laufzeit auf GDC verwendet die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC), um Berechtigungen für verwaltete Ressourcen festzulegen und durchzusetzen. Damit Sie diese Ressourcen nutzen und Ihre VMs verwalten können, haben wir vier vorkonfigurierte ClusterRoles bereitgestellt:

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

Diese vordefinierten Rollen bieten ein generalisiertes Zugriffsmodell auf die benutzerdefinierten Ressourcen im Zusammenhang mit VM Runtime on GDC. Jede Rolle hat vordefinierte Berechtigungen für die Ressourcen. In diesem Dokument finden Sie Informationen zu den von VM Runtime on GDC verwalteten Ressourcen, damit Clusteradministratoren ihr eigenes Zugriffsmodell anpassen können.

Vordefinierte ClusterRoles

In diesem Abschnitt werden die einzelnen vordefinierten ClusterRoles beschrieben. Diese ClusterRoles sind nur verfügbar, wenn VM Runtime on 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 Zugriffsverben
kubevm.admin Gewährt vollen Zugriff auf alle Ressourcen der Google Kubernetes Engine (GKE) Enterprise-Version.
  • get
  • list
  • watch
  • delete
  • create
  • update
  • patch
  • deletecollection
kubevm.edit Gewährt Lese-/Schreibzugriff auf alle Ressourcen der Google Kubernetes Engine (GKE) Enterprise-Version.
  • get
  • list
  • watch
  • delete
  • create
  • update
  • patch
kubevm.view Gewährt Lesezugriff auf alle Ressourcen der Google Kubernetes Engine (GKE) Enterprise-Version.
  • get
  • list
  • watch
kubevm.cluster.view Gewährt Lesezugriff auf clusterweite Ressourcen. Diese Clusterrolle ist erforderlich, wenn die Rolle „Bearbeiten/Anzeigen“ an einen Namespace gebunden ist, aber Zugriff auf clusterweite 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 in die Kubernetes-Standard-ClusterRoles admin, view und edit aggregiert. Durch diese Aggregation werden die Standard-Kubernetes-Rollen erweitert, sodass sie zum Verwalten von Ressourcen der Google Kubernetes Engine (GKE) Enterprise-Version verwendet werden können. Mit aggregierten ClusterRoles können Sie den Zugriff auf Ressourcen der Google Kubernetes Engine (GKE) Enterprise Edition mithilfe von Kubernetes-Standardrollen verwalten oder eigene Rollen basierend auf den vordefinierten ClusterRoles erstellen.

Beispiel für ein Aggregationslabel

Die ClusterRole kubevm.edit hat das Label rbac.authorization.k8s.io/aggregate-to-edit: "true", wodurch sie mit der Kubernetes-ClusterRole edit aggregiert wird. Die Berechtigungen in der kubevm.edit-ClusterRole werden der Kubernetes-Standardrolle edit gewährt. Die kubevm.admin- und kubevm.view-ClusterRoles werden auf ähnliche Weise mit aggregate-to-admin- oder aggregate-to-view-Anmerkungen 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 Nutzer oder einer Gruppe von Nutzern die in den vordefinierten ClusterRoles angegebenen Berechtigungen gewähren.

Clusteradministrator

Wenn Sie einem Nutzer oder einer Gruppe von Nutzern Administratorberechtigungen gewähren möchten, erstellen Sie eine ClusterRoleBinding mit der standardmäßigen admin-ClusterRole von Kubernetes.

Beispiel-ClusterRoleBinding

Im folgenden Beispiel für eine admin-charlie ClusterRoleBinding erhält der Nutzer charlie Administratorberechtigungen. Die ClusterRoleBinding verwendet Berechtigungen aus der standardmäßigen Kubernetes-ClusterRole admin, die durch Aggregation Berechtigungen aus der vordefinierten ClusterRole kubevm.admin enthält.

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

Cluster-Betrachter

Wenn Sie einem Nutzer oder einer Gruppe von Nutzern die Berechtigungen eines Betrachters gewähren möchten, erstellen Sie eine ClusterRoleBinding mit der Standard-ClusterRole view von Kubernetes. Ein ähnliches Beispiel für eine ClusterRoleBinding finden Sie unter Beispiel für ClusterRoleBinding.

Clustereditor

Wenn Sie einem Nutzer oder einer Gruppe von Nutzern Berechtigungen zum Bearbeiten gewähren möchten, erstellen Sie eine ClusterRoleBinding mit der standardmäßigen edit-ClusterRole von Kubernetes. Ein ähnliches Beispiel für eine ClusterRoleBinding finden Sie unter Beispiel für ClusterRoleBinding.

Namespace-Editor

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

  • Erstellen Sie eine RoleBinding für den Namespace und verweisen Sie auf die Standard-Kubernetes-ClusterRole edit.

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

Beispiele für Rollenbindungen (Namespace-Editor)

In den folgenden RoleBinding- und ClusterRoleBinding-Beispielen erhält der Nutzer charlie Bearbeitungsberechtigungen für Ressourcen im Namespace 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

Namespace-Betrachter

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

  • Erstellen Sie eine RoleBinding für den Namespace und verweisen Sie auf die Standard-Kubernetes-ClusterRole view.

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

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

Von VM Runtime on GDC verwendete Ressourcen

Die folgenden Abschnitte enthalten Tabellen mit Ressourcen, die von VM Runtime on GDC verwendet werden. Diese Abschnitte dienen nur zu Informationszwecken. Wenn Sie in den in den vorherigen Abschnitten beschriebenen typischen Nutzerszenarien vordefinierte Rollen verwenden möchten, haben diese Informationen keine besondere Bedeutung.

Wenn Sie die vordefinierten Rollen jedoch nicht verwenden möchten, können Sie anhand dieser Ressourceninformationen eigene benutzerdefinierte Rollen erstellen.

Von der Google Kubernetes Engine (GKE) Enterprise Edition definierte Ressourcen

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

Ressource Generiert Clusterweit 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

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

Ressource Generiert Clusterweit
virtualmachineinstances/Console – –
virtualmachineinstances/VNC – –
virtualmachineinstances/Portweiterleitung – –
virtualmachineinstances/Starten – –
virtualmachineinstances/Beenden – –
virtualmachineinstances/Neu starten – –
virtualmachines Ja –
virtualmachineinstances Ja –
datavolumes – –
storageprofiles – Ja
cdiconfigs – Ja

Kubernetes-Ressourcen

Wenn Sie mit VM Runtime on 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 eigene, benutzerdefinierte Rollen erstellen möchten:

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

YAML-Beispiele für ClusterRole

Sie können YAML für die 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.
  • Dabei ist KUBECONFIG_PATH der Pfad der kubeconfig-Datei für den Cluster.

Hier sind Beispiele für die 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