Anthos Clusters on Bare Metal sind jetzt Google Distributed Cloud (nur Software) für Bare Metal. Weitere Informationen finden Sie in der Produktübersicht.

Diese Seite wurde von der Cloud Translation API übersetzt.

Rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) für VM-Laufzeit in GDC

Die VM-Laufzeit auf GDC verwaltet eine breite Palette von Ressourcen im Zusammenhang mit Ihren VMs. Zu diesen Ressourcen gehören Ressourcen der Google Kubernetes Engine (GKE) Enterprise-Version, von KubeVirt definierte Ressourcen und Kubernetes-Ressourcen. Die VM-Laufzeit in GDC verwendet die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC), um Berechtigungen für verwaltete Ressourcen festzulegen und zu erzwingen. Um Sie bei der Arbeit mit diesen Ressourcen und bei der Verwaltung Ihrer VMs zu unterstützen, haben wir vier vorkonfigurierte ClusterRoles bereitgestellt:

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

Diese integrierten Rollen bieten ein allgemeines Zugriffsmodell auf die benutzerdefinierten Ressourcen im Zusammenhang mit der VM-Laufzeit auf GDC. Jede Rolle hat vordefinierte Berechtigungen für die Verarbeitung der Ressourcen. Dieses Dokument enthält Informationen zu Ressourcen, die von der 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 ClusterRole-Objekte automatisch erstellt.
Wenn die VM-Laufzeit auf GDC deaktiviert wird, werden die vier vordefinierten ClusterRole-Objekte gelöscht.

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

Clusterrolle	Beschreibung	Verben aufrufen
`kubevm.admin`	Gewährt vollständigen 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 zum Bearbeiten/Ansehen an einen Namespace gebunden ist, aber Zugriff auf clusterbezogene Ressourcen benötigt wird.	`get` `list` `watch`

Aggregierte ClusterRoles

Die ClusterRoles kubevm.admin, kubevm.view und kubevm.edit werden nicht direkt verwendet. Stattdessen werden diese drei Rollen in den Kubernetes-Standardclusterrollen admin, view und edit zusammengefasst. Durch diese Aggregation werden die Kubernetes-Standardrollen erweitert, sodass sie zur Verwaltung von Ressourcen der Google Kubernetes Engine (GKE) Enterprise-Version 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 basierend auf den vordefinierten ClusterRoles zu erstellen.

Beispiel für ein Aggregationslabel

Die ClusterRole kubevm.edit hat das Label rbac.authorization.k8s.io/aggregate-to-edit: "true", das sie in 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 auf ähnliche Weise 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 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 ein ClusterRoleBinding mit der Kubernetes-StandardclusterRole admin.

Beispiel für ClusterRoleBinding

Das folgende admin-charlie-Beispiel „ClusterRoleBinding“ gewährt dem Nutzer charlie-Administratorberechtigungen. ClusterRoleBinding verwendet Berechtigungen aus der Kubernetes-StandardclusterRole admin, die Berechtigungen von der vordefinierten ClusterRole kubevm.admin bis zur Aggregation 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

Cluster-Viewer

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 ClusterRoleBinding-Beispiel 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 ClusterRoleBinding-Beispiel finden Sie unter Beispiel für ClusterRoleBinding.

Namespace-Editor

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

Erstellen Sie ein RoleBinding im Namespace und verweisen Sie auf die standardmäßige Kubernetes-ClusterRole 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-Bearbeiter)

Die folgenden Beispiele für RoleBinding und ClusterRoleBinding gewähren dem Nutzer charlie-Bearbeiterberechtigungen 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 Namespace-Betrachterberechtigungen gewähren möchten, müssen Sie zwei separate Bindungen erstellen:

Erstellen Sie ein RoleBinding im Namespace und verweisen Sie auf die standardmäßige Kubernetes-ClusterRole 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 (Namespace-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 in den in den vorherigen Abschnitten beschriebenen typischen Nutzerszenarien vordefinierte Rollen verwenden möchten, können diese Informationen nicht spezifisch verwendet werden.

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

Ressourcen der Google Kubernetes Engine (GKE) Enterprise-Version

Die vordefinierten ClusterRoles konzentrieren sich auf den Zugriff auf Ressourcen, die in der Google Kubernetes Engine (GKE) Enterprise-Version definiert sind. In der folgenden Tabelle sind die Ressourcen der Google Kubernetes Engine (GKE) Enterprise-Version und die Zugriffsberechtigungen aufgeführt, die von den vordefinierten ClusterRole-Objekten 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`	Yes	–	Vollständig	Lesen	Lesen/Schreiben	–
`vmruntimes`	–	Yes	Vollständig	Lesen	Lesen/Schreiben	Lesen
`virtualmachinetypes`	–	Yes	Vollständig	Lesen	Lesen/Schreiben	Lesen
`vmhighavailabilitypolicies`	–	Yes	Vollständig	Lesen	Lesen/Schreiben	Lesen
`networkinterfaces`	Yes	–	Vollständig	Lesen	Lesen/Schreiben	–
`networks`	–	Yes	Vollständig	Lesen	Lesen/Schreiben	Lesen

KubeVirt-Ressourcen

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

Ressource	Generiert	Clusterweise
`virtualmachineinstances`/Konsole	–	–
`virtualmachineinstances`/vnc	–	–
`virtualmachineinstances`/Portweiterleitung	–	–
`virtualmachineinstances`/Start	–	–
`virtualmachineinstances`/Haltestelle	–	–
`virtualmachineinstances`/Neustart	–	–
`virtualmachines`	Yes	–
`virtualmachineinstances`	Yes	–
`datavolumes`	–	–
`storageprofiles`	–	Yes
`cdiconfigs`	–	Yes

Kubernetes-Ressourcen

Wenn Sie mit 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`	Yes	–
`services`	–	–
`persistentvolumeclaims`	–	–
`secrets`	–	–
`nodes`	–	Yes
`storageclasses`	–	Yes
`configmaps`	–	–

ClusterRole-YAML-Beispiele

Mit dem folgenden kubectl-Befehl können Sie YAML für die ClusterRoles 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 sind 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