Anthos clusters on bare metal ora è Google Distributed Cloud (solo software) per bare metal. Per ulteriori informazioni, consulta la panoramica del prodotto.

Questa pagina è stata tradotta dall'API Cloud Translation.

Controllo dell'accesso basato sui ruoli (RBAC) per il runtime delle VM su GDC

Il runtime delle VM su GDC gestisce un'ampia gamma di risorse correlate alle VM. Queste risorse includono le risorse definite dalla versione Enterprise di Google Kubernetes Engine (GKE), le risorse definite da KubeVirt e le risorse Kubernetes. Il runtime VM su GDC utilizza il controllo controllo dell'accesso basato sui ruoli (RBAC) per impostare e applicare le autorizzazioni per le risorse gestite. Per aiutarti a utilizzare queste risorse e gestire le tue VM, abbiamo fornito quattro ruoli di gruppo preconfigurati:

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

Questi ruoli integrati forniscono un modello di accesso generalizzato alle risorse personalizzate relative al runtime della VM su GDC. Ogni ruolo ha autorizzazioni predefinite per operare sulle risorse. Questo documento fornisce informazioni sulle risorse gestite da VM Runtime on GDC in modo che gli amministratori del cluster possano personalizzare il proprio modello di accesso.

ClusterRole predefiniti

Questa sezione descrive ciascuno dei ClusterRole predefiniti. Questi ClusterRoles sono disponibili solo quando il runtime VM su GDC è abilitato:

Quando l'ambiente di runtime VM su GDC è abilitato, i quattro ruoli di gruppo predefiniti vengono creati automaticamente.
Quando il runtime VM su GDC è disabilitato, i quattro ruoli ClusterRole predefiniti vengono eliminati.

La tabella seguente elenca i ruoli del cluster e le relative autorizzazioni:

Ruolo del cluster	Descrizione	Verbi di accesso
`kubevm.admin`	Concede l'accesso completo a tutte le risorse della versione Enterprise di Google Kubernetes Engine (GKE).	`get` `list` `watch` `delete` `create` `update` `patch` `deletecollection`
`kubevm.edit`	Concede l'accesso in lettura/scrittura a tutte le risorse della versione Enterprise di Google Kubernetes Engine (GKE).	`get` `list` `watch` `delete` `create` `update` `patch`
`kubevm.view`	Concede l'accesso in lettura a tutte le risorse della versione Enterprise di Google Kubernetes Engine (GKE).	`get` `list` `watch`
`kubevm.cluster.view`	Concede l'accesso in lettura alle risorse a livello di cluster. Questo ruolo cluster è necessario quando il ruolo di modifica/visualizzazione è associato a uno spazio dei nomi, mentre è necessario accedere alle risorse a livello di cluster.	`get` `list` `watch`

ClusterRole aggregati

I ClusterRole kubevm.admin, kubevm.view e kubevm.edit non vengono utilizzati direttamente. Questi tre ruoli vengono invece aggregati rispettivamente ai ClusterRole admin, view e edit predefiniti di Kubernetes. Questa aggregazione estende i ruoli Kubernetes predefiniti in modo che possano essere utilizzati per gestire le risorse della versione Enterprise di Google Kubernetes Engine (GKE). Con i ClusterRole aggregati, puoi utilizzare i ruoli predefiniti di Kubernetes per gestire l'accesso alle risorse della versione Enterprise di Google Kubernetes Engine (GKE) o creare i tuoi ruoli in base ai ClusterRole predefiniti.

Esempio di etichetta di aggregazione

Il ClusterRole kubevm.edit ha l'etichetta rbac.authorization.k8s.io/aggregate-to-edit: "true", che lo aggrega al ClusterRole edit di Kubernetes. Le autorizzazioni nel kubevm.edit ClusterRole vengono concesse al ruolo edit predefinito di Kubernetes. I ClusterRole kubevm.admin e kubevm.view vengono aggregati in modo simile con le annotazioni aggregate-to-admin o 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"
...

Scenari utente tipici

Le sezioni seguenti descrivono come utilizzare RoleBinding e ClusterRoleBinding per concedere le autorizzazioni specificate nei ClusterRole predefiniti a un utente o a un insieme di utenti.

Amministratore del cluster

Per concedere autorizzazioni amministrative a un utente o a un insieme di utenti, crea un ClusterRoleBinding con il ruolo ClusterRole admin predefinito di Kubernetes.

Esempio di ClusterRoleBinding

Il seguente esempio di ClusterRoleBinding admin-charlie assegna all'utente charlie le autorizzazioni amministrative. ClusterRoleBinding utilizza le autorizzazioni del ruolo admin ClusterRole di Kubernetes predefinito, che include le autorizzazioni del ruolo admin ClusterRole predefinito tramite aggregazione.kubevm.admin

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

Visualizzatore cluster

Per concedere le autorizzazioni di visualizzatore a un utente o a un insieme di utenti, crea un ClusterRoleBinding con il ClusterRole view predefinito di Kubernetes. Consulta Esempio di ClusterRoleBinding per un esempio simile di ClusterRoleBinding.

Editor di cluster

Per concedere le autorizzazioni di editor a un utente o a un gruppo di utenti, crea un ClusterRoleBinding con il ruolo ClusterRole edit predefinito di Kubernetes. Consulta Esempio di ClusterRoleBinding per un esempio simile di ClusterRoleBinding.

Editor con spazio dei nomi

Per concedere autorizzazioni di editor con nome a un utente o a un gruppo di utenti, devi creare due associazioni distinte:

Crea un'associazione dei ruoli nello spazio dei nomi e fai riferimento al ClusterRoleedit Kubernetes predefinito.
Crea un ClusterRoleBinding che faccia riferimento al ClusterRolekubevm.cluster.view predefinito. Questo ClusterRoleBinding è necessario perché alcune risorse, come virtualmachinetypes e storageclasses, non sono associate a uno spazio dei nomi.

Esempi di associazione dei ruoli (editor con nome nello spazio dei nomi)

I seguenti esempi di RoleBinding e ClusterRoleBinding concedono all'utente charlie le autorizzazioni di editor per le risorse nello spazio dei nomi 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

Visualizzatore con spazio dei nomi

Per concedere le autorizzazioni di visualizzatore con nome a un utente o a un gruppo di utenti, devi creare due associazioni distinte:

Crea un'associazione dei ruoli nello spazio dei nomi e fai riferimento al ClusterRoleview Kubernetes predefinito.
Crea un ClusterRoleBinding che faccia riferimento al ClusterRolekubevm.cluster.view predefinito.

Consulta Esempi di associazioni di ruoli (editor con spazi dei nomi) per esempi simili di RoleBinding e ClusterRoleBinding.

Risorse utilizzate dal runtime VM su GDC

Le sezioni seguenti contengono tabelle di risorse utilizzate dal runtime VM su GDC. Queste sezioni sono fornite solo a scopo informativo. Se prevedi di utilizzare i ruoli predefiniti negli scenari utente tipici descritti nelle sezioni precedenti, queste informazioni non hanno un utilizzo specifico.

Tuttavia, se non vuoi utilizzare i ruoli predefiniti, puoi utilizzare queste informazioni sulle risorse per creare i tuoi ruoli personalizzati.

Risorse definite dalla versione Enterprise di Google Kubernetes Engine (GKE)

I ruoli ClusterRole predefiniti si concentrano sull'accesso alle risorse definite dalla versione Enterprise di Google Kubernetes Engine (GKE). La tabella seguente elenca le risorse di Google Kubernetes Engine (GKE) versione Enterprise e le autorizzazioni di accesso concesse da ciascuno dei ClusterRole predefiniti.

Risorsa	Generato	Per cluster	`kubevm.admin`	`kubevm.view`	`kubevm.edit`	`kubevm.cluster.view`
`virtualmachineaccessrequests`	–	–	Completa	Leggi	Lettura/scrittura	–
`virtualmachinedisks`	–	–	Completa	Leggi	Lettura/scrittura	–
`virtualmachines`	–	–	Completa	Leggi	Lettura/scrittura	–
`gpuallocations`	–	–	Completa	Leggi	Lettura/scrittura	–
`guestenvironmentdata`	Sì	–	Completa	Leggi	Lettura/scrittura	–
`vmruntimes`	–	Sì	Completa	Leggi	Lettura/scrittura	Leggi
`virtualmachinetypes`	–	Sì	Completa	Leggi	Lettura/scrittura	Leggi
`vmhighavailabilitypolicies`	–	Sì	Completa	Leggi	Lettura/scrittura	Leggi
`networkinterfaces`	Sì	–	Completa	Leggi	Lettura/scrittura	–
`networks`	–	Sì	Completa	Leggi	Lettura/scrittura	Leggi

Risorse KubeVirt

Il runtime delle VM su GDC si basa sul progetto open source KubeVirt. Per impostazione predefinita, le autorizzazioni per le risorse KubeVirt vengono aggregate automaticamente ai ruoli Kubernetes predefiniti, in modo simile alle risorse gestite dalla versione Enterprise di Google Kubernetes Engine (GKE). Utilizza le informazioni sulle risorse riportate nella tabella seguente se vuoi creare i tuoi ruoli personalizzati:

Risorsa	Generato	Per cluster
`virtualmachineinstances`/console	–	–
`virtualmachineinstances`/vnc	–	–
`virtualmachineinstances`/portforward	–	–
`virtualmachineinstances`/start	–	–
`virtualmachineinstances`/stop	–	–
`virtualmachineinstances`/restart	–	–
`virtualmachines`	Sì	–
`virtualmachineinstances`	Sì	–
`datavolumes`	–	–
`storageprofiles`	–	Sì
`cdiconfigs`	–	Sì

Risorse Kubernetes

Quando utilizzi il runtime VM su GDC e le VM, potresti dover gestire l'accesso alle seguenti risorse Kubernetes. Utilizza le informazioni sulle risorse riportate nella tabella seguente se vuoi creare i tuoi ruoli personalizzati:

Risorsa	Generato	Per cluster
`pods`	Sì	–
`services`	–	–
`persistentvolumeclaims`	–	–
`secrets`	–	–
`nodes`	–	Sì
`storageclasses`	–	Sì
`configmaps`	–	–

Esempi di file YAML ClusterRole

Puoi recuperare il file YAML per i ClusterRole con il seguente comando kubectl:

kubectl get ClusterRole CLUSTERROLE_NAME -o yaml --kubeconfig KUBECONFIG_PATH

Sostituisci quanto segue:

CLUSTERROLE_NAME: il nome del ruoloClusterRole, ad esempio kubevm.cluster.view.
KUBECONFIG_PATH: il percorso del file kubeconfig per il cluster.

Di seguito sono riportati alcuni esempi dell'output del comando per ciascuno dei quattro ruoli di cluster predefiniti:

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