Control de acceso según la función

En esta página, se proporciona una descripción general del sistema de control de acceso según la función (RBAC) proporcionado por Kubernetes, y una explicación sobre cómo usar Kubernetes RBAC en Google Kubernetes Engine.

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 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:

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

  • Usa gcloud init si quieres aprender acerca de los valores predeterminados de la configuración.
  • Usa gcloud config para establecer el ID, la zona y la región del proyecto de manera individual.

Usa gcloud init

  1. Ejecuta gcloud init y sigue estas instrucciones:

    gcloud init

    Si usas SSH en un servidor remoto, usa la marca --console-only para evitar que el comando inicie 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.

Usa la configuración de gcloud

  • 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
  • Descarga la versión más reciente de gcloud:
    gcloud components update

Interacción con administración de identidades y accesos

Puedes usar Cloud Identity and Access Management y Kubernetes RBAC para controlar el acceso al clúster de GKE:

  • Cloud 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, Cloud IAM y Kubernetes RBAC la integración permite 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.

Requisitos previos 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 Cloud IAM no puede otorgar la capacidad de crear un Role o ClusterRole de Kubernetes RBAC. Sin embargo, la función de administrador de Kubernetes Engine de Cloud IAM otorga a los usuarios la capacidad de crear un RoleBinding o ClusterRoleBinding de Kubernetes RBAC para cualquier usuario, incluidos ellos mismos, que se puede usar a fin de vincular a los usuarios de GCP con las 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 que les permita crear Roles de RBAC y ClusterRoles, ejecuta el siguiente comando y reemplaza user-account por la dirección de correo electrónico de acceso de Google Cloud del usuario objetivo.

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

Grupos de Google para GKE

beta

Antes, solo se podían otorgar funciones a cuentas de usuario de Google Cloud o cuentas de servicio de Cloud IAM. Con Grupos de Google para GKE (Beta), puedes 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, configura tus Grupos de Google de G Suite, crea un clúster con la función habilitada y, luego, asocia esos Grupos de Google con conjuntos de permisos de clúster.

Configura Grupos de Google para usar con RBAC

La configuración de tu clúster para usar esta función y la sintaxis con el fin de 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 G Suite en tu dominio, llamado gke-security-groups@yourdomain.com. El grupo debe llamarse exactamente 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 G Suite.

    También puedes consultar el Centro de ayuda de Grupos para obtener más información sobre la administración de Grupos en G Suite.

  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.

  3. Agrega estos grupos (no usuarios) a la membresía de gke-security-groups@yourdomain.com.

A fin de verificar si un usuario 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 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.

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

Una vez que el administrador de G Suite configura tus grupos, crea un clúster nuevo con el comando gcloud y agrega la marca --security-group="gke-security-groups@yourdomain.com", 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="gke-security-groups@yourdomain.com"

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"]

Role frente a 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. Los siguientes son algunos de ellos:

  • Recursos de alcance de clúster, como los nodos
  • Extremos que no son de 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 Cloud IAM User Dirección de correo electrónico de la cuenta de servicio de Cloud 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 gke-security-groups@[yourdomain.com]

El siguiente RoleBinding otorga el Role pod-reader a un usuario, una cuenta de servicio de Kubernetes, una cuenta de servicio de Cloud 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
    # Cloud IAM service account
    - kind: User
      name: test-account@test-project-123456.google.com.iam.gserviceaccount.com
    # G Suite Google Group
    - kind: Group
      name: accounting-group@example.com
    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 la página sobre Usa la autorización con control de acceso basado en funciones en la documentación de Kubernetes.

Advertencias

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 las demás solicitudes corresponden a system:unauthenticated. Antes de la versión 1.14 de Kubernetes, system:authenticated y system:unauthenticated otorgan los ClusterRoles system:basic-user y system:discovery de forma 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 detección, 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:basic-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

Este error puede ocurrir cuando la instancia de VM no tiene el permiso userinfo-email. Por ejemplo, supongamos que la VM tiene el permiso cloud-platform, pero no el permiso userinfo-email. Cuando la VM obtiene un token de acceso, Google Cloud lo asocia con el permiso 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 esta.

Para autenticarte de forma correcta, crea una VM nueva con el permiso userinfo-email o crea una nueva vinculación de función que use el ID único.

Para crear una VM nueva con el permiso 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

  2. Crea una vinculación de función con el ID único:

        kubectl create clusterrolebinding clusterrolebinding-name \
      --clusterrole cluster-admin \
      --user unique-id

Próximos pasos