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 el RBAC de Kubernetes 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.
-
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
- Sigue las instrucciones a fin de autorizar a
gcloud
para que use tu cuenta de Google Cloud. - Crea una configuración nueva o selecciona una existente.
- Elige un proyecto de Google Cloud.
- Elige una zona predeterminada de Compute Engine.
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
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.
Si bien el RBAC de Kubernetes puede usarse en lugar de IAM en 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 el RBAC de Kubernetes.
Grupos de Google para GKE
Antes, solo se podían otorgar funciones a cuentas de usuario de Google Cloud o cuentas de servicio de IAM. Con Grupos de Google para GKE (beta), puedes otorgar funciones a los miembros de un grupo en Grupos de Google para empresas. Con este mecanismo, los administradores de Google Workspace mantienen a los usuarios y los grupos, completamente por fuera de Kubernetes o Cloud Console, 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
- Configura tus Grupos de Google.
- 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 los siguientes requisitos:
- Debes tener una suscripción a Google Workspace o a Cloud Identity.
Configura Grupos de Google para usar con RBAC
La configuración de tu clúster con el fin de usar esta función y la sintaxis para hacer referencia a un Grupo de Google en el RBAC de Kubernetes se analizan más adelante en este tema. Primero, debes seguir los pasos a continuación para configurar tus Grupos de Google:
Crea un Grupo de Google en tu dominio, llamado
gke-security-groups@yourdomain.com
. El grupo debe llamarsegke-security-groups
. Asegúrate de que el grupogke-security-groups
tenga el permiso “Ver miembros” para “Miembros del grupo”. Consulta este artículo para obtener 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.
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”.
Agrega estos grupos (no usuarios) a la membresía de
gke-security-groups@yourdomain.com
.
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 los Grupos de Google se almacena en caché por un período breve. 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
Después de que tu administrador de Grupos de Google configure tus grupos, crea un clúster nuevo mediante el comando gcloud
y agrega la marca --security-group="gke-security-groups@yourdomain.com"
para sustituir el valor con tu propio nombre de dominio.
El siguiente es un ejemplo del comando cluster create:
gcloud beta container clusters create cluster-name \
--security-group="gke-security-groups@yourdomain.com"
Ahora estás listo para crear funciones, ClusterRoles, RoleBindings y ClusterRoleBindings que hagan referencia a tus Grupos de Google.
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. Una ClusterRoleBinding funciona con un ClusterRole y una RoleBinding funciona con un ClusterRole o un Role.
Las funciones de RBAC son completamente aditivas: no hay reglas de “denegación”. Cuando estructuras las 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
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 (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 |
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-123456.google.com.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 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:
Habilita el registro de acceso a los datos para el proyecto de Google Cloud. Para habilitar el registro, sigue estos pasos:
En Cloud Console, ve a la página Registros de auditoría en el menú IAM.
En la tabla, selecciona API de Kubernetes Engine.
En el menú Tipo de registro, selecciona:
- Lectura de administración
- Lectura de datos
- Escritura de datos
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.
Ejecuta un comando mediante
kubectl
en el clúster. Esto puede ser tan simple comokubectl create ns helloworld
.Ingresa una consulta personalizada en la página Visor de registros. Para ejecutar la consulta, haz lo siguiente:
En Cloud Console, ve a la página Visor de registros en el menú Registro.
Haz clic en la flecha del cuadro Vista previa de la búsqueda en la parte superior de la página.
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.
Selecciona Ejecutar consulta. Debes ver al menos un resultado. De lo contrario, intenta aumentar el intervalo de tiempo.
Selecciona el clúster que deseas examinar.
Haz clic en Expand nested fields.
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.
- Los grupos que son miembros de
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:
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 serviciomy-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'
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?
- Obtén más información para crear políticas de IAM.