Configura el control de acceso basado en funciones

En esta página, se proporciona una descripción general sobre el sistema de control de acceso basado en funciones (RBAC) que proporciona Kubernetes y sobre cómo usar Kubernetes RBAC en Google Kubernetes Engine (GKE).

Descripción general

Kubernetes incluye un mecanismo integrado de control de acceso según la función (RBAC) que te permite configurar conjuntos de permisos precisos y detallados que definen cómo un usuario de Google Cloud o un grupo de usuarios determinado puede interactuar con cualquier objeto de Kubernetes en el clúster o en un espacio de nombres específico del clúster.

Kubernetes RBAC está habilitado de forma predeterminada.

Antes de comenzar

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

• Asegúrate de que habilitaste la API de Google Kubernetes Engine.
Habilitar la API de Google Kubernetes Engine
• Asegúrate de que instalaste el SDK de Cloud.

Establece la configuración de gcloud predeterminada mediante uno de los siguientes métodos:

• Usa gcloud init si deseas ver una explicación sobre cómo configurar parámetros predeterminados.
• Usa gcloud config para establecer el ID, la zona y la región del proyecto de manera individual.

Usa gcloud init

Si recibes el error One of [--zone, --region] must be supplied: Please specify location, completa esta sección.

1. Ejecuta gcloud init y sigue las instrucciones:

   gcloud init

   Si usas SSH en un servidor remoto, usa la marca --console-only para evitar que el comando abra un navegador:

   gcloud init --console-only

2. Sigue las instrucciones a fin de autorizar a gcloud para que use tu cuenta de Google Cloud.
3. Crea una configuración nueva o selecciona una existente.
4. Elige un proyecto de Google Cloud.
5. Elige una zona predeterminada de Compute Engine.

Nota: Puedes anular esta configuración predeterminada en los comandos de gcloud mediante las marcas --project, --zone y --region.

Usa gcloud config

• Establece tu ID del proyecto predeterminado:

  gcloud config set project project-id

• Si trabajas con clústeres zonales, establece tu zona de procesamiento predeterminada:

  gcloud config set compute/zone compute-zone

• Si trabajas con clústeres regionales, establece tu región de procesamiento predeterminada:

  gcloud config set compute/region compute-region

• Actualiza gcloud a la versión más reciente:

  gcloud components update

Nota: Puedes anular esta configuración predeterminada en los comandos de gcloud mediante las marcas --project, --zone y --region.

Interacción con administración de identidades y accesos

Puedes usar la administración de identidades y accesos (IAM) y Kubernetes RBAC 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.

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

En GKE, IAM y Kubernetes RBAC 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.

Nota: Muchas fallas que parecen deberse a la autorización en realidad se deben a que el clúster no puede autenticar al cliente. Por ejemplo, existen requisitos especiales para la autenticación desde instancias de Compute Engine, que se describen en la documentación sobre la autenticación de kubectl.

Si bien Kubernetes RBAC se puede usar en lugar de IAM para casi todos los casos, los usuarios de GKE necesitan al menos 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, así como en las 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 Kubernetes RBAC.

Requisitos para usar Kubernetes RBAC en el clúster de GKE v1.11.x y versiones anteriores

En los clústeres de GKE que usan GKE v1.11.x y versiones anteriores, existe una limitación por la cual IAM no puede otorgar la capacidad de crear un Role o ClusterRole de Kubernetes RBAC. Sin embargo, la Función de IAM de administrador de Kubernetes Engine otorga a los usuarios la capacidad de crear un RoleBinding o ClusterRoleBinding de Kubernetes RBAC para cualquier usuario, incluido a sí mismos, que se puede usar para vincular a los usuarios de Google Cloud con Funciones predefinidas de RBAC.

En particular, la función cluster-admin predefinida de RBAC otorga a los usuarios permisos completos en el clúster. Por lo tanto, para iniciar un usuario y permitirle crear Roles y ClusterRoles de RBAC, emite el siguiente comando y reemplaza user-account por la dirección de correo electrónico de acceso de Google Cloud del usuario de destino.

kubectl create clusterrolebinding cluster-admin-binding \
  --clusterrole cluster-admin \
  --user user-account

Nota: En el valor de user-account, se distingue entre mayúsculas y minúsculas. Para evitar errores, ingresa la dirección de correo electrónico del usuario de destino en minúsculas.

Grupos de Google para GKE

Beta

Este producto o función se encuentra en un estado previo al lanzamiento y puede cambiar o tener asistencia limitada. Para obtener más información, consulta las etapas de lanzamiento de productos.

Antes, solo se podían otorgar funciones a cuentas de usuario de Google Cloud o cuentas de servicio de IAM. Grupos de Google para GKE (Beta) te permite otorgar funciones a los miembros de un Grupo de Google de G Suite. Con este mecanismo, los administradores de G Suite mantienen a los usuarios y grupos fuera de Kubernetes o Cloud Console en su totalidad, por lo que los administradores del clúster no necesitan información detallada sobre tus usuarios. Otro beneficio es la integración con las prácticas de administración de cuentas de usuario existentes, como revocar el acceso cuando alguien abandona la organización.

Para usar esta función, completa las siguientes tareas:

• Cumplir con los requisitos
• Configurar los Grupos de Google de G Suite
• Crear un clúster con la función habilitada
• Asociar los Grupos de Google con conjuntos de permisos de clúster.

Requisitos

A fin de usar los Grupos de Google para GKE, debes cumplir con los siguientes requisitos:

• Tener una suscripción a G Suite o Cloud Identity.

Configura Grupos de Google para usar con RBAC

La configuración de tu clúster a fin de usar esta función y la sintaxis para hacer referencia a un Grupo de Google de G Suite en Kubernetes RBAC se analizan más adelante en este tema. Primero, debes seguir los pasos a continuación para configurar tus Grupos de Google:

1. Crea un Grupo de Google de Google Workspace en tu dominio, llamado [e-mail]. El nombre del grupo debe llamarse gke-security-groups. Asegúrate de que el grupo gke-security-groups tenga el permiso “Ver miembros” para “Miembros del grupo”. Consulta este artículo para ver un ejemplo de cómo configurarlo en la Consola del administrador de Google Workspace.

   También puedes consultar el Centro de ayuda de Grupos para obtener más información sobre cómo administrar Grupos en Google Workspace.

2. Crea grupos, si aún no existen, que representen grupos de usuarios o grupos que deberían tener permisos diferentes en los clústeres. Cada grupo debe tener el permiso “Ver miembros” para “Miembros del grupo”.

3. Agrega estos grupos (no usuarios) a la membresía de [e-mail].

A fin de verificar si un usuario determinado tiene permiso para crear, modificar o ver un recurso en el clúster según la membresía del grupo, GKE verifica si es miembro de un grupo con acceso y si ese grupo es miembro directo del grupo gke-security-groups del dominio.

La información sobre la membresía de Grupos de Google de G Suite se almacena en caché por un corto tiempo. Los cambios en las membresías de grupo pueden demorar unos minutos en propagarse a todos tus clústeres. Además de la latencia de los cambios de grupos, el almacenamiento en caché estándar de las credenciales de usuario en el clúster es de alrededor de una hora.

Configura el clúster a fin de usar Grupos de Google para GKE

Nota:Debes crear un clúster nuevo para habilitar esta función.

Una vez que el administrador de los Grupos de Google de G Suite configura los grupos, crea un clúster nuevo con el comando de gcloud y agrega la marca --security-group="[e-mail]", mediante la sustitución del valor con tu propio nombre de dominio.

El siguiente es un ejemplo del comando de creación del clúster:

gcloud beta container clusters create cluster-name \
  --security-group="[e-mail]"

Ahora estás listo para crear Roles, ClusterRoles, RoleBindings y ClusterRoleBindings que hagan referencia a tus Grupos de Google de G Suite.

Define y asigna permisos

Crea los siguientes tipos de objetos de Kubernetes para definir tus permisos RBAC:

• ClusterRole o Role: define un conjunto de tipos de recursos y operaciones que pueden asignarse a un usuario o grupo de usuarios en un clúster (ClusterRole) o un espacio de nombres (Role), pero no especifica el usuario o grupo de usuarios.
• ClusterRoleBinding o RoleBinding: asigna un ClusterRole o Role a un usuario o grupo de usuarios. Un ClusterRoleBinding funciona con un ClusterRole y un RoleBinding funciona con un ClusterRole o un Role.

Las funciones de RBAC son aditivas en su totalidad: no hay reglas de “denegación”. Cuando estructuras tus funciones de RBAC, debes pensar en términos de “otorgar” a los usuarios acceso a los recursos del clúster.

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 el espacio de nombres, el tipo de recurso y las operaciones permitidas relevantes para el Role. Por ejemplo, el siguiente Role otorga acceso de lectura (get, watch y list) para todos los pods en el espacio de nombres accounting:

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

Nota:No puedes crear un Role que defina permisos, a menos que ya tengas los permisos definidos en el Role. Si se te otorgó la función de IAM cluster-admin, esto es suficiente.

Role vs. 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. Estos incluyen:

• 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 de G Suite (Beta) en un dominio verificado	Group	Dirección de correo electrónico de un Grupo de Google que es miembro del Grupo de Google [e-mail]

El siguiente RoleBinding otorga el Role pod-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: [e-mail]
# Kubernetes service account
- kind: ServiceAccount
  name: johndoe
# IAM service account
- kind: User
  name: [e-mail]
# G Suite Google Group
- kind: Group
  name: [e-mail]
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

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 GKE, google groups se muestra en el mensaje de registro.

Depura problemas con la integración de Grupos de Google

Las siguientes instrucciones te permiten ver los registros para validar si tus clústeres se configuraron de forma correcta para usar Grupos de Google en RoleBindings de RBAC.

Requisitos

Antes de comenzar a examinar los registros, asegúrate de lo siguiente:

• No has interactuado con el clúster que quieres probar (por ejemplo, si ejecutaste comandos kubectl) durante al menos una hora. La autenticación se almacena en caché durante una hora y debes asegurarte de que la solicitud se registre cuando suceda.
• Eres miembro de al menos uno de los grupos incluidos en gke-security-groups. Esto garantiza que la información de los Grupos de Google se propague en los registros.

Configura registros

A fin de usar registros para depurar los Grupos de Google con RBAC, haz lo siguiente:

1. Habilita el registro de acceso a los datos para el proyecto de Google Cloud. Para habilitar el registro, haz lo siguiente:

   1. En Cloud Console, ve a la página Registros de auditoría en el menú IAM.

      Ir a la página Registros de auditoría

   2. En la tabla, selecciona API de Kubernetes Engine.

   3. En el menú Tipo de registro, selecciona:

      • Lectura de administración
      • Lectura de datos
      • Escritura de datos

   4. Haz clic en Guardar.

   Si deseas obtener más información sobre cómo habilitar el registro de auditoría, consulta Configura los registros de acceso a los datos con Cloud Console en la documentación de las herramientas de administración de Cloud.

   Importante: Habilitar el registro de auditoría genera cargos. Si solo habilitaste el registro de auditoría con fines de prueba, debes inhabilitarlo después de completar la prueba para evitar cargos.

2. Ejecuta un comando mediante kubectl en el clúster. Esto puede ser tan simple como kubectl create ns helloworld.

3. Ingresa una consulta personalizada en la página Visor de registros. Para ejecutar la consulta, haz lo siguiente:

   1. En Cloud Console, ve a la página Visor de registros en el menú Registro.

      Ir a la página Visor de registros

   2. Haz clic en la flecha del cuadro Vista previa de la búsqueda en la parte superior de la página.

   3. En el cuadro desplegable que aparece, copia y pega la siguiente consulta:

      resource.type="k8s_cluster"
      resource.labels.location="cluster-region"
      resource.labels.cluster_name="cluster-name"
      protoPayload.resourceName="authorization.k8s.io/v1beta1/subjectaccessreviews"
      protoPayload.response.spec.user="email-address"
      

      En el ejemplo anterior, se ilustra lo siguiente:

      • cluster-region es la región o la zona de tu clúster.
      • cluster-name es el nombre de tu clúster.
      • email-address es la dirección de correo electrónico registrada de tu Cuenta de Google.

   4. Selecciona Ejecutar consulta. Debes ver al menos un resultado. De lo contrario, intenta aumentar el intervalo de tiempo.

   5. Selecciona el clúster que deseas examinar.

   6. Haz clic en Expand nested fields.

   7. El campo protoPayload.request.spec.group contiene los siguientes grupos:

      • Los grupos que son miembros de gke-security-group
      • Los grupos de los que formas parte

      Esta lista debe coincidir con el conjunto de grupos del que eres miembro. Si no hay grupos presentes, es posible que haya un problema con la configuración de los grupos.

4. Restablece el registro de acceso a los datos a la configuración anterior para evitar cargos adicionales (si lo deseas).

Limitaciones

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

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. Antes de la versión 1.14 de Kubernetes, tanto system:authenticated como system:unauthenticated otorgan los ClusterRoles system:basic-user y system:discovery de manera predeterminada.

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

A partir de Kubernetes 1.14, los usuarios anónimos (system:unauthenticated) recibirán 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 [e-mail]:

   displayName: Some Domain IAM service account
   email: [e-mail]
   etag: BwWWja0YfJA
   name: projects/project-name/serviceAccounts/[e-mail]
   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
   

Próximos pasos

• Obtén más información sobre cómo crear políticas de IAM.