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

Die VM-Laufzeit auf GDC verwendet die rollenbasierte Zugriffssteuerung (RBAC), mit der Sie Berechtigungen für Ihre VM-Arbeitslasten festlegen und erzwingen können. Mit diesen Berechtigungen wird der Zugriff auf von GKE, KubeVirt und Kubernetes definierte Ressourcen verwaltet.

Zur Optimierung der Zugriffsverwaltung bietet VM Runtime on GDC vorkonfigurierte ClusterRoles für Verwaltungs-, Bearbeitungs- und Ansichtsvorgänge. VM Runtime on GDC aggregiert diese Rollen automatisch in die Kubernetes-Standard-ClusterRoles admin, edit und view. In Namespace-Szenarien bietet eine dedizierte kubevm.cluster.view-Rolle Lesezugriff auf clusterweite Ressourcen. Administratoren können diese Rollen auch als Vorlagen verwenden, um benutzerdefinierte Zugriffsmodelle zu entwerfen.

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 vollständigen Zugriff auf alle GKE-Ressourcen.
  • get
  • list
  • watch
  • delete
  • create
  • update
  • patch
  • deletecollection
kubevm.edit Gewährt Lese-/Schreibzugriff auf alle GKE-Ressourcen.
  • get
  • list
  • watch
  • delete
  • create
  • update
  • patch
kubevm.view Gewährt Lesezugriff auf alle GKE-Ressourcen.
  • get
  • list
  • watch
kubevm.cluster.view Gewährt Lesezugriff auf clusterweite Ressourcen. Diese Clusterrolle ist erforderlich, wenn die Bearbeitungs-/Ansichtsrolle an einen Namespace gebunden ist, aber Zugriff auf clusterweite 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 zu den Kubernetes-Standard-ClusterRoles admin, view und edit aggregiert. Durch diese Aggregation werden die Kubernetes-Standardrollen erweitert, sodass sie zum Verwalten von GKE-Ressourcen verwendet werden können. Mit aggregierten ClusterRoles können Sie den Zugriff auf GKE-Ressourcen 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 ClusterRole kubevm.edit 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 ein ClusterRoleBinding-Objekt mit der Kubernetes-Standard-ClusterRole admin.

Beispiel-ClusterRoleBinding

Im folgenden admin-charlie-Beispiel für ein ClusterRoleBinding erhält der Nutzer charlie Administratorberechtigungen. Das ClusterRoleBinding-Objekt verwendet Berechtigungen aus der Kubernetes-Standard-ClusterRole admin, die Berechtigungen aus der vordefinierten ClusterRole kubevm.admin durch Aggregation 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 Betrachterberechtigungen gewähren möchten, erstellen Sie ein ClusterRoleBinding-Objekt mit der Kubernetes-Standard-ClusterRole view. Ein ähnliches ClusterRoleBinding-Beispiel finden Sie unter Beispiel-ClusterRoleBinding.

Clustereditor

Wenn Sie einem Nutzer oder einer Gruppe von Nutzern Bearbeiterberechtigungen gewähren möchten, erstellen Sie ein ClusterRoleBinding-Objekt mit der Kubernetes-Standard-ClusterRole edit. Ein ähnliches ClusterRoleBinding-Beispiel finden Sie unter Beispiel-ClusterRoleBinding.

Namespace-Editor

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

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

  • Erstellen Sie ein ClusterRoleBinding, das 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 RoleBinding- und ClusterRoleBinding-Beispielen werden dem Nutzer charlie Bearbeiterberechtigungen für Ressourcen im Namespace default gewährt:

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 Betrachterberechtigungen für einen Namespace gewähren möchten, müssen Sie zwei separate Bindungen erstellen:

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

  • Erstellen Sie ein ClusterRoleBinding, das 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 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 vordefinierte Rollen in den typischen Nutzerszenarien verwenden möchten, die in den vorherigen Abschnitten beschrieben wurden, gibt es für diese Informationen keine spezifische Verwendung.

Wenn Sie die vordefinierten Rollen jedoch nicht verwenden möchten, können Sie diese Ressourceninformationen verwenden, um eigene, benutzerdefinierte Rollen zu erstellen.

Von Google Kubernetes Engine definierte Ressourcen

Die vordefinierten ClusterRoles konzentrieren sich auf den Zugriff auf in GKE definierte Ressourcen. In der folgenden Tabelle sind die GKE-Ressourcen und die Zugriffsberechtigungen aufgeführt, die von den 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 den Kubernetes-Standardrollen zugewiesen, ähnlich wie bei den von GKE 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