Configurar 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 predeterminada de la herramienta de línea de comandos de gcloud para tu proyecto mediante uno de los siguientes métodos:
    • Usa gcloud init si deseas ver una explicación sobre cómo configurar los valores predeterminados del proyecto.
    • Usa gcloud config para configurar el ID, la zona y la región del proyecto de manera individual.

    gcloud init

    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 para autorizar a la herramienta de gcloud a usar 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 de Compute Engine predeterminada.
    6. Elige una región de Compute Engine predeterminada.

    gcloud config

    1. Establece tu ID del proyecto predeterminado:
      gcloud config set project PROJECT_ID
    2. Configura la región de Compute Engine predeterminada (por ejemplo, us-central1):
      gcloud config set compute/region COMPUTE_REGION
    3. Configura la zona de Compute Engine predeterminada (por ejemplo, us-central1-c):
      gcloud config set compute/zone COMPUTE_ZONE
    4. Actualiza gcloud a la versión más reciente:
      gcloud components update

    Cuando configuras las ubicaciones predeterminadas, puedes evitar errores en la herramienta gcloud como el siguiente: One of [--zone, --region] must be supplied: Please specify location.

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 funciones (conjuntos de permisos) para cualquier objeto o tipo de objeto dentro del clúster.

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 la función 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: 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

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.

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
    

¿Qué sigue?