Versión 1.15. Ya no se admite esta versión. Si quieres obtener información para actualizar a la versión 1.16, consulta Actualiza clústeres en la documentación más reciente. Para obtener más información sobre las versiones compatibles y no compatibles, consulta la página Historial de versiones en la documentación más reciente.

Control de acceso basado en funciones (RBAC) para el entorno de ejecución de VM en GDC

El entorno de ejecución de VM en GDC administra una amplia variedad de recursos relacionados con tus VM. Estos recursos incluyen recursos definidos por la edición de Google Kubernetes Engine (GKE) Enterprise, recursos definidos por KubeVirt y recursos de Kubernetes. El entorno de ejecución de VM en GDC usa el control de acceso basado en funciones (RBAC) a fin de establecer y aplicar permisos para los recursos administrados. Para ayudarte a trabajar con estos recursos y administrar tus VM, proporcionamos cuatro ClusterRoles preconfigurados:

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

Estas funciones integradas proporcionan un modelo de acceso generalizado a los recursos personalizados relacionados con el entorno de ejecución de VM en GDC. Cada rol tiene permisos preestablecidos para operar en los recursos. En este documento, se proporciona información sobre los recursos que administra el entorno de ejecución de VM en GDC para que los administradores de clústeres puedan personalizar su propio modelo de acceso.

ClusterRoles predefinidos

En esta sección, se describe cada uno de los ClusterRoles predefinidos. Estos ClusterRoles solo están disponibles cuando está habilitado el entorno de ejecución de VM en GDC:

Cuando el entorno de ejecución de VM en GDC está habilitado, se crean automáticamente los cuatro ClusterRoles predefinidos.
Cuando el entorno de ejecución de VM en GDC está inhabilitado, se borran los cuatro ClusterRoles predefinidos.

En la siguiente tabla, se enumeran los roles del clúster y sus permisos relacionados:

Rol del clúster	Descripción	Verbos de acceso
`kubevm.admin`	Otorga acceso completo a todos los recursos de la edición Google Kubernetes Engine (GKE) Enterprise.	`get` `list` `watch` `delete` `create` `update` `patch` `deletecollection`
`kubevm.edit`	Otorga acceso de lectura/escritura a todos los recursos de la edición de Google Kubernetes Engine (GKE) Enterprise.	`get` `list` `watch` `delete` `create` `update` `patch`
`kubevm.view`	Otorga acceso de lectura a todos los recursos de la edición Google Kubernetes Engine (GKE) Enterprise.	`get` `list` `watch`
`kubevm.cluster.view`	Otorga acceso de lectura a los recursos a nivel de clúster. Este rol de clúster es necesario cuando el rol de edición/vista está vinculado a un espacio de nombres, mientras que el acceso a los recursos a nivel de clúster es necesario.	`get` `list` `watch`

ClusterRoles agregados

Los ClusterRoles kubevm.admin, kubevm.view y kubevm.edit no se usan directamente. En cambio, estas tres funciones se agregan a los ClusterRoles admin, view y edit predeterminados de Kubernetes, respectivamente. Esta agregación extiende los roles predeterminados de Kubernetes para que se puedan usar para administrar los recursos de la edición de Google Kubernetes Engine (GKE) Enterprise. Con los ClusterRoles agregados, puedes usar las funciones predeterminadas de Kubernetes para administrar el acceso a los recursos de la edición Google Kubernetes Engine (GKE) Enterprise o crear tus propias funciones basadas en los ClusterRoles predefinidos.

Ejemplo de etiqueta de agregación

El ClusterRole kubevm.edit tiene la etiqueta rbac.authorization.k8s.io/aggregate-to-edit: "true", que la agrega al ClusterRole edit de Kubernetes. Los permisos en el ClusterRole kubevm.edit se otorgan a al rol predeterminado edit de Kubernetes. Los ClusterRoles kubevm.admin y kubevm.view se agregan de manera similar con las anotaciones 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"
...

Situaciones de usuario típicas

En las siguientes secciones, se describe cómo usar RoleBinding y ClusterRoleBinding para otorgar los permisos especificados en los ClusterRoles predefinidos a un usuario o conjunto de usuarios.

Administrador de clúster

Para otorgar permisos de administrador a un usuario o a un conjunto de usuarios, crea un ClusterRoleBinding con el ClusterRole admin predeterminado de Kubernetes.

ClusterRoleBinding de ejemplo

El siguiente ClusterRoleBinding admin-charlie de ejemplo otorga permisos de administrador charlie al usuario. El ClusterRoleBinding usa permisos del ClusterRole admin de Kubernetes predeterminado, que incluye permisos del ClusterRole kubevm.admin predefinido a través de la agregación.

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

Visualizador de clúster

Para otorgar permisos de visualizador a un usuario o conjunto de usuarios, crea un ClusterRoleBinding con el ClusterRole view predeterminado de Kubernetes. Consulta Ejemplo de ClusterRoleBinding para ver un ejemplo de ClusterRoleBinding similar.

Editor de clúster

Para otorgar permisos de editor a un usuario o conjunto de usuarios, crea un ClusterRoleBinding con el ClusterRole edit predeterminado de Kubernetes. Consulta Ejemplo de ClusterRoleBinding para ver un ejemplo de ClusterRoleBinding similar.

Editor de espacio de nombres

Para otorgar permisos de editor con espacio de nombres a un usuario o conjunto de usuarios, debes crear dos vinculaciones diferentes:

Crea un RoleBinding en el espacio de nombres y haz referencia al ClusterRole edit de Kubernetes predeterminado.
Crea un ClusterRoleBinding que haga referencia al ClusterRole kubevm.cluster.view predefinido. Se necesita esta ClusterRoleBinding, ya que algunos recursos, como virtualmachinetypes y storageclasses, no tienen espacio de nombres.

Ejemplos de vinculación de roles (editor con espacio de nombres)

Los siguientes ejemplos de RoleBinding y ClusterRoleBinding otorgan permisos de editor al usuario charlie para los recursos en el espacio de nombres 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

Visualizador con espacio de nombres

Para otorgar permisos de visualizador con espacio de nombres a un usuario o a un conjunto de usuarios, debes crear dos vinculaciones diferentes:

Crea un RoleBinding en el espacio de nombres y haz referencia al ClusterRole view de Kubernetes predeterminado.
Crea un ClusterRoleBinding que haga referencia al ClusterRole kubevm.cluster.view predefinido.

Consulta Ejemplos de vinculación de funciones (editor con espacio de nombres) para ver ejemplos de RoleBinding y ClusterRoleBinding similares.

Recursos que usa el entorno de ejecución de la VM en GDC

En las siguientes secciones, se incluyen tablas de recursos que usa el entorno de ejecución de VM en GDC. Estas secciones son solo con fines informativos. Si planeas usar roles predefinidos en las situaciones de usuario típicas descritas en las secciones anteriores, no hay uso específico para esta información.

Sin embargo, si no deseas usar los roles predefinidos, puedes usar esta información de recursos para crear tus propios roles personalizados.

Recursos definidos por la edición de Google Kubernetes Engine (GKE) Enterprise

Los ClusterRoles predefinidos se enfocan en el acceso a los recursos definidos por la edición de Google Kubernetes Engine (GKE) Enterprise. En la siguiente tabla, se enumeran los recursos de la edición Enterprise de Google Kubernetes Engine (GKE) y los permisos de acceso otorgados por cada uno de los ClusterRoles predefinidos.

Recurso	Generada	En términos de clústeres	`kubevm.admin`	`kubevm.view`	`kubevm.edit`	`kubevm.cluster.view`
`virtualmachineaccessrequests`	–	–	Completo	Leer	Lectura/escritura	–
`virtualmachinedisks`	–	–	Completo	Leer	Lectura/escritura	–
`virtualmachines`	–	–	Completo	Leer	Lectura/escritura	–
`gpuallocations`	–	–	Completo	Leer	Lectura/escritura	–
`guestenvironmentdata`	Sí	–	Completo	Leer	Lectura/escritura	–
`vmruntimes`	–	Sí	Completo	Leer	Lectura/escritura	Leer
`virtualmachinetypes`	–	Sí	Completo	Leer	Lectura/escritura	Leer
`vmhighavailabilitypolicies`	–	Sí	Completo	Leer	Lectura/escritura	Leer
`networkinterfaces`	Sí	–	Completo	Leer	Lectura/escritura	–
`networks`	–	Sí	Completo	Leer	Lectura/escritura	Leer

Recursos de KubeVirt

El entorno de ejecución de VM en GDC se basa en el proyecto de código abierto KubeVirt. De forma predeterminada, los permisos para los recursos de KubeVirt se agregan automáticamente a los roles predeterminados de Kubernetes, de manera similar a los recursos administrados por la edición Google Kubernetes Engine (GKE) Enterprise. Usa la información de recursos de la siguiente tabla si deseas crear tus propios roles personalizados:

Recurso	Generada	En términos de clústeres
`virtualmachineinstances`/console	–	–
`virtualmachineinstances`/vnc	–	–
`virtualmachineinstances`/portforward	–	–
`virtualmachineinstances`/start	–	–
`virtualmachineinstances`/stop	–	–
`virtualmachineinstances`/restart	–	–
`virtualmachines`	Sí	–
`virtualmachineinstances`	Sí	–
`datavolumes`	–	–
`storageprofiles`	–	Sí
`cdiconfigs`	–	Sí

Recursos de Kubernetes

Cuando trabajas con el entorno de ejecución de VM en GDC y las VM, es posible que debas administrar el acceso a los siguientes recursos de Kubernetes. Usa la información de recursos de la siguiente tabla si deseas crear tus propios roles personalizados:

Recurso	Generada	En términos de clústeres
`pods`	Sí	–
`services`	–	–
`persistentvolumeclaims`	–	–
`secrets`	–	–
`nodes`	–	Sí
`storageclasses`	–	Sí
`configmaps`	–	–

Ejemplos de YAML de ClusterRole

Puedes recuperar YAML para los ClusterRoles con el siguiente comando de kubectl:

kubectl get ClusterRole CLUSTERROLE_NAME -o yaml --kubeconfig KUBECONFIG_PATH

Reemplaza lo siguiente:

CLUSTERROLE_NAME: el nombre del ClusterRole, como kubevm.cluster.view.
KUBECONFIG_PATH: la ruta al archivo kubeconfig para el clúster.

Estos son ejemplos del resultado del comando para cada uno de los cuatro ClusterRoles predefinidos:

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