Autoriza acciones en clústeres mediante el control de acceso basado en roles

En esta página, se muestra cómo autorizar acciones en los recursos de tus clústeres de Google Kubernetes Engine (GKE) mediante el mecanismo de control de acceso basado en roles (RBAC) integrado en Kubernetes.

RBAC es una función de seguridad principal en Kubernetes que te permite crear permisos detallados para administrar qué acciones pueden realizar los usuarios y las cargas de trabajo en los recursos de los clústeres. Como administrador de la plataforma, creas roles de RBAC y vinculas esos roles a los asuntos, que son usuarios autenticados como cuentas de servicio o Grupos. Kubernetes RBAC está habilitado de forma predeterminada.

Antes de comenzar

Antes de comenzar, asegúrate de haber realizado las siguientes tareas:

  • Habilita la API de Kubernetes Engine de Google.
    • Habilitar la API de Kubernetes Engine de Google
  • Si deseas usar Google Cloud CLI para esta tarea, instala y, luego, inicializa gcloud CLI. Si ya instalaste gcloud CLI, ejecuta gcloud components update para obtener la versión más reciente.

Interacción con administración de identidades y accesos

Puedes usar la administración de identidades y accesos (IAM) y el RBAC de Kubernetes para controlar el acceso a tu clúster de GKE:

  • IAM no es específico de Kubernetes. Proporciona administración de identidades para varios productos de Google Cloud y opera sobre todo a nivel de proyecto de Google Cloud.

  • El RBAC de Kubernetes es un componente central de Kubernetes y te permite crear y otorgar roles (conjuntos de permisos) para cualquier objeto o tipo de objeto dentro del clúster.

  • Para autorizar una acción, GKE verifica primero una política de RBAC. Si no hay una política de RBAC, GKE verifica los permisos de IAM.

En GKE, IAM y el RBAC de Kubernetes están integrados para autorizar a los usuarios a realizar acciones si tienen permisos suficientes de acuerdo con cualquiera de las dos herramientas. Esta es una parte importante de la inicialización de un clúster de GKE, ya que, de forma predeterminada, los usuarios de Google Cloud no tienen ningún RoleBinding de Kubernetes RBAC.

A fin de autorizar a los usuarios que usan cuentas de Google Cloud, el cliente debe estar configurado de forma correcta para autenticarse con esas cuentas. Por ejemplo, si usas kubectl, debes configurar el comando kubectl para autenticarte en Google Cloud antes de ejecutar cualquier comando que requiera autorización.

En casi todos los casos, se puede usar RBAC de Kubernetes en lugar de IAM. Los usuarios de GKE requieren, como mínimo, el permiso de IAM container.clusters.get en el proyecto que contiene el clúster. Este permiso se incluye en la función container.clusterViewer y en otras funciones con más privilegios. El permiso container.clusters.get es necesario para que los usuarios se autentiquen en los clústeres del proyecto, pero no los autoriza a realizar ninguna acción dentro de esos clústeres. La autorización se puede proporcionar mediante IAM o el RBAC de Kubernetes.

Define y asigna permisos

Puedes definir reglas de RBAC en objetos ClusterRole y Role y, luego, asignar esas reglas con objetos ClusterRoleBinding y RoleBinding de la siguiente manera:

  • ClusterRole: una agrupación de recursos a nivel de clúster y operaciones permitidas que puedes asignar a un usuario o grupo mediante un objetoRoleBinding o ClusterRoleBinding.
  • Función: Una agrupación de recursos con espacio de nombres y operaciones permitidas que puedes asignar a un usuario o a un grupo de usuarios mediante un RoleBinding.
  • ClusterRoleBinding: asigna un objeto ClusterRole a un usuario o grupo para todos los espacios de nombres del clúster.
  • RoleBinding: asigna un objeto Role o ClusterRole a un usuario o grupo en un espacio de nombres específico.

Cuando usas un objeto RoleBinding para asignar un objeto ClusterRole a un usuario o grupo, esos usuarios y grupos solo pueden acceder a los recursos en el espacio de nombres que especifiques en RoleBinding. Si quieres que los usuarios o grupos accedan al recurso en todos los espacios de nombres, usa un objeto ClusterRoleBinding en su lugar.

Define permisos con Roles o ClusterRoles

Debes definir permisos dentro de un objeto Role o ClusterRole. Un Role define el acceso a los recursos dentro de un único espacio de nombres, mientras que un ClusterRole define el acceso a los recursos en todo el clúster.

Los Roles y ClusterRoles tienen la misma sintaxis. Cada una tiene una sección rules, en la que se definen los recursos a los que se aplica la regla y las operaciones permitidas para el Role. Por ejemplo, el siguiente Role otorga acceso de lectura (get, watch y list) a todos los Pods en el espacio de nombres accounting:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: accounting
  name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

Consulta la documentación de la API de Role y ClusterRole para ver una lista completa de los campos permitidos.

Role en comparación con ClusterRole

Debido a que los permisos otorgados por un ClusterRole se aplican a todo el clúster, puedes usar ClusterRoles para controlar el acceso a diferentes tipos de recursos de los que puedes con Roles. Entre estas opciones, se incluyen las siguientes:

  • Recursos de alcance de clúster, como los nodos
  • Extremos de REST sin recursos, como /healthz
  • Recursos con espacio de nombres en todos los espacios de nombres (por ejemplo, todos los Pods en todo el clúster, sin importar el espacio de nombres)

Asigna Roles mediante RoleBindings o ClusterRoleBindings

Después de crear un Role o ClusterRole, se lo asigna a un usuario o grupo de usuarios mediante un RoleBinding o ClusterRoleBinding. Los usuarios y los grupos se llaman subjects y pueden ser cualquiera de los siguientes:

Tipo de asunto Valor de kind Valor de name
Cuenta de usuario de Google Cloud User Dirección de correo electrónico registrada en Google Cloud
Cuenta de servicio de Kubernetes ServiceAccount El nombre de un objeto ServiceAccount de Kubernetes en el clúster
Cuenta de servicio de IAM User Dirección de correo electrónico de la cuenta de servicio de IAM generada de forma automática
Dirección del Grupo de Google en un dominio verificado Group Dirección de correo electrónico de un grupo de Google Workspace que es miembro del grupo gke-security-groups. A fin de obtener instrucciones sobre cómo configurar Grupos de Google para RBAC, consulta Configura Grupos de Google para RBAC.

La siguiente RoleBinding otorga el rolpod-reader a un usuario, una cuenta de servicio de Kubernetes, una cuenta de servicio de IAM y un Grupo de Google:

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: pod-reader-binding
  namespace: accounting
subjects:
# Google Cloud user account
- kind: User
  name: janedoe@example.com
# Kubernetes service account
- kind: ServiceAccount
  name: johndoe
# IAM service account
- kind: User
  name: test-account@test-project.iam.gserviceaccount.com
# Google Group
- kind: Group
  name: accounting-group@example.com
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Verifica el acceso a la API con kubectl

kubectl proporciona el subcomando auth can-i para consultar con rapidez la capa de autorización de la API. Como administrador de la plataforma, es posible que debas usar la identidad de los usuarios para determinar qué acciones pueden realizar. Puedes usar la auth can-i y pasar una marca --as adicional.

Cuando ejecutas el comando kubectl auth can-i sin la marca --as, Identity and Access Management (IAM) realiza la autorización. Mientras que, cuando agregas la marca --as, Kubernetes RBAC realiza la autorización. Por lo tanto, deberás crear los objetos Role y RoleBinding necesarios para RBAC.

Para obtener más información, consulta Verifica el acceso a la API.

Uso de API y ejemplos

Para obtener información completa sobre cómo usar la API de Kubernetes a fin de crear los objetos Role, ClusterRole, RoleBinding y ClusterRoleBinding necesarios para RBAC, consulta Usa la autorización con control de acceso basado en funciones en la documentación de Kubernetes.

Solución de problemas y depuración

A fin de depurar problemas con RBAC, se usa el registro de auditoría de actividad del administrador, que está habilitado en todos los clústeres de forma predeterminada. Si se deniega el acceso a un recurso o una operación debido a la falta de permisos suficientes, el servidor de API registra un error RBAC DENY, junto con información adicional, como la membresía de grupo implícita y explícita del usuario. Si usas Grupos de Google para RBAC, google groups se muestra en el mensaje de registro.

Limitaciones

En las siguientes secciones, se describen interacciones que pueden no parecer obvias cuando se trabaja con Kubernetes RBAC e IAM de Kubernetes.

Funciones de descubrimiento predeterminadas

Los clústeres se crean con un conjunto de ClusterRoles y ClusterRoleBindings predeterminados. Las solicitudes realizadas con credenciales válidas se colocan en el grupo system:authenticated, mientras que todas las demás solicitudes corresponden a system:unauthenticated.

El ClusterRole system:basic-user permite a los usuarios hacer SelfSubjectAccessReviews para probar sus permisos en el clúster. El rol system:discovery permite a los usuarios leer las API de Discovery, que pueden revelar información sobre CustomResourceDefinitions agregada al clúster.

En cambio, los usuarios anónimos (system:unauthenticated) reciben el ClusterRole system:public-info-viewer, que otorga acceso de solo lectura a las API de /healthz y /version.

Para ver los extremos de API permitidos por el ClusterRole system:discovery, ejecuta el siguiente comando:

kubectl get clusterroles system:discovery -o yaml

Error prohibido para cuentas de servicio en instancias de VM de Google Cloud

El siguiente error puede ocurrir cuando la instancia de VM no tiene el alcance userinfo-email:

Error from server (Forbidden): error when creating ... "role-name" is forbidden: attempt to grant extra privileges:...

Por ejemplo, supongamos que la VM tiene alcance cloud-platform, pero no tiene alcance userinfo-email. Cuando la VM obtiene un token de acceso, Google Cloud asocia ese token con el alcance cloud-platform. Cuando el servidor de la API de Kubernetes solicita a Google Cloud la identidad asociada con el token de acceso, recibe el ID único de la cuenta de servicio, no el correo electrónico de la cuenta de servicio.

Para autenticar con éxito, crea una VM nueva con el alcance userinfo-email o crea una vinculación de función nueva que use el ID único.

Para crear una instancia de VM nueva con el alcance userinfo-email, ejecuta el siguiente comando:

gcloud compute instances create INSTANCE_NAME \
    --service-account SERVICE_ACCOUNT_EMAIL \
    --scopes userinfo-email

A fin de crear una nueva vinculación de función que use el ID único de la cuenta de servicio para una VM existente, realiza los siguientes pasos:

  1. Identifica el ID único de la cuenta de servicio:

    gcloud iam service-accounts describe SERVICE_ACCOUNT_EMAIL

    Por ejemplo, el siguiente resultado muestra el uniqueId para la cuenta de servicio my-iam-account@somedomain.com:

    displayName: Some Domain IAM service account
email: my-iam-account@somedomain.com
etag: BwWWja0YfJA
name: projects/project-name/serviceAccounts/my-iam-account@somedomain.com
oauth2ClientId: '123456789012345678901'
projectId: project-name
uniqueId: '123456789012345678901'

  2. Crea una vinculación de función con el uniqueId de la cuenta de servicio:

    kubectl create clusterrolebinding CLUSTERROLEBINDING_NAME \
    --clusterrole cluster-admin \
    --user UNIQUE_ID

Permiso para crear o actualizar roles y vinculaciones de roles

En Kubernetes, solo puedes crear o actualizar un rol o una vinculación de rol con permisos específicos si cumples con las siguientes condiciones:

  • Crea o actualiza un rol: ya debes tener los mismos permisos que deseas otorgar a el rol. Como alternativa, debes tener autorización para realizar el verbo escalate en el rol.
  • Crea o actualiza una vinculación de rol: ya debes tener los mismos permisos que se otorgan en el rol de vinculación, con el mismo permiso que la vinculación de rol. Como alternativa, debes tener autorización para realizar el verbo bind en el rol al que se hace referencia.

Si los permisos que otorgas en el rol se te otorgaron originalmente mediante una política de permisos de IAM en lugar de RBAC, tu solicitud de vinculación de rol o rol puede fallar. Por ejemplo, considera la siguiente solicitud de creación de roles, de un usuario al que se le otorgaron los permisos de IAM container.pods.* y container.roles.create:

kubectl create role allowed-to-view-pods --resource pods --verb list,get

Si al usuario solo se le otorgaron los permisos mediante IAM, podría ocurrir el siguiente error:

Error from server (Forbidden): clusterroles.rbac.authorization.k8s.io "allowed-to-view-pods" is forbidden:
user "caller@example.com" (groups=["system:authenticated"]) is attempting to grant RBAC permissions not currently held:
{APIGroups:[""], Resources:["pods"], Verbs:["list" "get"]}

Para mitigar esta limitación, otorga al emisor los permisos en el rol mediante RBAC en lugar de IAM.

Como alternativa, puedes usar RBAC o IAM para otorgar al emisor el verbo escalate, el verbo bind o ambos. Sin embargo, GKE no recomienda este enfoque, ya que el emisor puede otorgar cualquier permiso a cualquier función.

¿Qué sigue?