Opciones de acceso e identidad en Azure Kubernetes Service (AKS)
Artículo
Puede autenticar, autorizar, proteger y controlar el acceso a los clústeres de Kubernetes de varias maneras:
Mediante el control de acceso basado en rol de Kubernetes (RBAC de Kubernetes), puede conceder acceso a usuarios, grupos y cuentas de servicio únicamente a los recursos que necesitan.
Con Azure Kubernetes Service (AKS), puede mejorar aún más la seguridad y la estructura de permisos mediante el uso de Microsoft Entra ID y Azure RBAC.
AKS y RBAC de Kubernetes le ayudan a proteger el acceso al clúster y a proporcionar solo los permisos mínimos necesarios a los desarrolladores y operadores.
En este artículo se presentan los conceptos básicos para ayudarle a autenticarse y a asignar permisos en AKS.
RBAC de Kubernetes
RBAC de Kubernetes proporciona un filtrado detallado de las acciones del usuario. Con este mecanismo de control:
Asigna a usuarios o grupos de usuarios permiso para crear o modificar recursos, o ver registros de cargas de trabajo de aplicaciones en ejecución.
Puede limitar los permisos a un único espacio de nombres o a todo el clúster de AKS.
Crea roles para definir permisos y, después, asigna esos roles a usuarios mediante enlaces de rol.
Antes de asignar permisos a los usuarios con RBAC de Kubernetes, definirá los permisos de usuario como un rol. Conceda permisos dentro de un espacio de nombres mediante roles.
Nota
Los roles de Kubernetes conceden permisos; no los deniegan.
Para conceder permisos en todo el clúster o a recursos de clúster fuera de un espacio de nombres determinado, puede usar en su lugar ClusterRoles.
ClusterRoles
Un objeto ClusterRole concede y aplica permisos a los recursos de todo el clúster, no a un espacio de nombres específico.
Asigne roles a los usuarios de un espacio de nombres determinado mediante RoleBindings. Con RoleBindings, puede separar lógicamente un único clúster de AKS, de modo que solo se permita a los usuarios acceder a los recursos de la aplicación en su espacio de nombres asignado.
Para enlazar roles en todo el clúster o para recursos de clúster fuera de un espacio de nombres determinado, use en su lugar ClusterRoleBindings.
ClusterRoleBinding
Con un objeto ClusterRoleBinding, enlaza roles a usuarios y los aplica a los recursos de todo el clúster, no a un espacio de nombres determinado. Este enfoque le permite conceder acceso para los administradores o ingenieros de soporte técnico a todos los recursos del clúster de AKS.
Nota
Microsoft/AKS realiza todas las acciones de clúster con el consentimiento del usuario en el rol de Kubernetes integrado aks-service y el enlace de roles integrado aks-service-rolebinding.
Este rol permite a AKS solucionar problemas de clústeres, pero no puede modificar permisos ni crear roles, enlaces de roles ni otras acciones de privilegios elevados. El acceso a roles solo se habilita en incidencias de soporte técnico activos con acceso Just-in-Time (JIT). Obtenga más información sobre Directivas de soporte técnico de AKS.
Cuentas de servicio de Kubernetes
Las cuentas de servicio son uno de los tipos de usuario principales en Kubernetes. La API de Kubernetes contiene y administra cuentas de servicio. Las credenciales de las cuentas de servicio se almacenan como secretos de Kubernetes que pueden usar los pods autorizados para comunicarse con el servidor de API. La mayoría de las solicitudes de API proporcionan un token de autenticación para una cuenta de servicio o una cuenta de usuario normal.
Las cuentas de usuario normales permiten un acceso más tradicional para administradores o desarrolladores humanos, no solo a servicios y procesos. Aunque Kubernetes no proporciona una solución de administración de identidades para almacenar contraseñas y cuentas de usuario normales, puede integrar soluciones de identidades externas en Kubernetes. Para los clústeres de AKS, esta solución de identidades integrada es Microsoft Entra ID.
Para más información sobre las opciones de identidad en Kubernetes, consulte la autenticación Kubernetes.
Control de acceso basado en roles de Azure
El control de acceso basado en rol (RBAC) de Azure es un sistema de autorización basado en Azure Resource Manager que proporciona administración de acceso específico a los recursos de Azure.
Sistema RBAC
Descripción
RBAC de Kubernetes
Diseñado para funcionar en recursos de Kubernetes dentro del clúster de AKS.
Azure RBAC
Diseñado para funcionar en recursos dentro de la suscripción de Azure.
Con el control de acceso basado en rol de Azure, puede crear una definición de rol que describe los permisos que se aplicarán. A continuación, asigne esta definición de rol a un usuario o grupo mediante una asignación de roles para un ámbito determinado. El ámbito puede ser un recurso individual, un grupo de recursos o toda la suscripción.
Con la integración de Azure RBAC, AKS utilizará un servidor de webhooks de autorización de Kubernetes, lo que le permitirá administrar los permisos y asignaciones de los recursos del clúster de Kubernetes integrados en Microsoft Entra utilizando la definición y la asignación de roles de Azure.
Como se muestra en el diagrama anterior, al usar la integración de Azure RBAC, todas las solicitudes a la API Kubernetes seguirán el mismo flujo de autenticación que se explica en la sección de integración de Microsoft Entra.
Si la identidad que realiza la solicitud existe en Microsoft Entra ID, Azure colaborará con RBAC de Kubernetes para autorizar la solicitud. Si la identidad existe fuera de Microsoft Entra ID (es decir, una cuenta de servicio de Kubernetes), la autorización se aplazará al RBAC de Kubernetes normal.
En este escenario, usará mecanismos y API de RBAC de Azure para asignar roles integrados a los usuarios o crear roles personalizados, tal como lo haría con los roles de Kubernetes.
Con esta característica, no solo concede permisos a los usuarios para el recurso de AKS entre suscripciones, sino que también configura el rol y los permisos dentro de cada uno de esos clústeres que controlan el acceso a la API de Kubernetes. Por ejemplo, puede conceder el rol Azure Kubernetes Service RBAC Reader en el ámbito de la suscripción. El destinatario del rol podrá enumerar y obtener todos los objetos de Kubernetes de todos los clústeres sin modificarlos.
Importante
Debe habilitar Azure RBAC para la autorización de Kubernetes antes de usar esta característica. Para obtener información detallada e instrucciones paso a paso, siga nuestra guía paso a paso Uso de Azure RBAC para la autorización de Kubernetes.
Roles integrados
AKS proporciona los siguientes cuatro roles integrados. Son similares a los roles integrados de Kubernetes con algunas diferencias, como la compatibilidad con CRDs. Consulte la lista completa de acciones permitidas por cada rol integrado de Azure.
Role
Descripción
Lector de Azure Kubernetes Service RBAC
Permite el acceso de solo lectura para ver la mayoría de los objetos en un espacio de nombres. No permite la visualización de roles o enlaces de roles. No permite la visualización de Secrets. Leer el contenido de Secrets permite el acceso a las credenciales de ServiceAccount en el espacio de nombres, lo que permitiría el acceso a la API como cualquier ServiceAccount en el espacio de nombres (una forma de elevación de privilegios).
Escritor de Azure Kubernetes Service RBAC
Permite el acceso de lectura y escritura para ver la mayoría de los objetos en un espacio de nombres. No permite la visualización o modificación de roles o enlaces de roles. Permite acceder a Secrets y ejecutar pods como cualquier ServiceAccount en el espacio de nombres, por lo que se puede usar para obtener los niveles de acceso de la API de cualquier ServiceAccount en el espacio de nombres.
Administrador de Azure Kubernetes Service RBAC
Permite el acceso de administrador, diseñado para su concesión dentro de un espacio de nombres. Permite el acceso de lectura y escritura a la mayoría de los recursos de un espacio de nombres (o ámbito de clúster), incluida la capacidad de crear roles y enlaces de roles dentro del espacio de nombres. No permite el acceso de escritura a la cuota de recursos o al espacio de nombres en sí.
Administrador de clúster de Azure Kubernetes Service RBAC
Permite el acceso de superusuario para realizar cualquier acción en cualquier recurso. Proporciona control total sobre todos los recursos del clúster y en todos los espacios de nombres.
Integración de Microsoft Entra
Mejore la seguridad del clúster de AKS con la integración de Microsoft Entra. Con la experiencia de varias décadas de administración de identidades empresariales, Microsoft Entra ID es un servicio multiinquilino de administración de identidades y de directorios basado en la nube que combina los servicios de directorio principales, la administración del acceso de las aplicaciones y la protección de identidades. Con Microsoft Entra ID, puede integrar identidades locales en clústeres de AKS para proporcionar un único origen para la seguridad y administración de cuentas.
Con los clústeres de AKS integrados en Microsoft Entra, puede conceder a los usuarios o grupos acceso a los recursos de Kubernetes de un espacio de nombres o del clúster.
Para obtener un contexto de configuración de kubectl, el usuario ejecuta el comando az aks get-credentials.
Cuando un usuario interactúa con el clúster de AKS con kubectl, se le pide que inicie sesión con sus credenciales de Microsoft Entra.
Este enfoque proporciona un único origen para la administración de cuentas de usuario y de las credenciales de contraseña. El usuario solo puede acceder a los recursos como defina el administrador de clústeres.
La autenticación de Microsoft Entra se proporciona a los clústeres de AKS con OpenID Connect. OpenID Connect es una capa de identidad creada basándose en el protocolo OAuth 2.0. Puede encontrar más información sobre OpenID Connect en la documentación de OpenID Connect. Dentro del clúster de Kubernetes, se usa la autenticación de token de webhook para verificar los tokens de autenticación. La autenticación de token de webhook se configura y administra como parte del clúster de AKS.
Webhook y servidor de API
Como se muestra en el gráfico anterior, el servidor de API llama al servidor de webhook de AKS y realiza los pasos siguientes:
Microsoft Entra ID proporciona un access_token, id_token y un refresh_token.
El usuario realiza una solicitud a kubectl con un access_token de kubeconfig.
kubectl envía access_token al servidor de API.
El servidor de API se configura con el servidor de autenticación de Webhook para realizar la validación.
El servidor de autenticación de webhook confirma que la firma JSON Web Token es válida mediante la comprobación de la clave de firma pública de Microsoft Entra.
La aplicación del servidor usa credenciales proporcionadas por el usuario para consultar la pertenencia a grupos del usuario que ha iniciado sesión desde la MS Graph API.
Se envía una respuesta al servidor de API con información del usuario, como la notificación del nombre principal de usuario (UPN) del token de acceso y la pertenencia al grupo del usuario en función del identificador de objeto.
La API realiza una decisión de autorización basada en el rol Kubernetes/RoleBinding.
Una vez autorizado, el servidor de API devuelve una respuesta a kubectl.
Al crear un clúster, AKS genera o modifica los recursos necesarios (por ejemplo, máquinas virtuales y NIC) para crear y ejecutar el clúster en nombre del usuario. Esta identidad es distinta del permiso de identidad del clúster, que se crea durante la construcción del clúster.
Identidad para crear y administrar los permisos de clúster
Los siguientes permisos son necesarios para la identidad que crea y administra el clúster.
Permiso
Motivo
Microsoft.Compute/diskEncryptionSets/read
Se requiere para leer el identificador de conjunto de cifrado de disco.
Microsoft.Compute/proximityPlacementGroups/write
Necesario para actualizar los grupos con ubicación por proximidad.
Necesario para configurar los grupos de back-end de Load Balancer basados en IP.
Permisos de identidad de clúster de AKS
Los siguientes permisos se usan en la identidad de clúster de AKS, que se crea y se asocia al clúster de AKS. Cada permiso se usa por los motivos que se indican a continuación:
Permiso
Motivo
Microsoft.ContainerService/managedClusters/*
Necesario para la creación de usuarios y el funcionamiento del clúster
Se requiere para encontrar información de máquinas virtuales en un conjunto de escalado de máquinas virtuales (por ejemplo, zonas, dominio de error, tamaño y discos de datos).
Microsoft.Network/networkInterfaces/write
Se requiere para agregar una máquina virtual de un clúster VMAS a un grupo de direcciones de back-end del equilibrador de carga.
Microsoft.Compute/virtualMachineScaleSets/write
Se requiere para agregar un conjunto de escalado de máquinas virtuales a grupos de direcciones de back-end del equilibrador de carga y a nodos de escalabilidad horizontal en un conjunto de escalado de máquinas virtuales.
Microsoft.Compute/virtualMachineScaleSets/delete
Se requiere para eliminar un conjunto de escalado de máquinas virtuales a grupos de direcciones de back-end del equilibrador de carga y a nodos de reducción vertical en un conjunto de escalado de máquinas virtuales.
Se requiere para asociar AzureDisks y agregar una máquina virtual de un conjunto de escalado de máquinas virtuales al equilibrador de carga.
Microsoft.Network/networkInterfaces/read
Se requiere para buscar grupos de direcciones IP internas y de direcciones de back-end del equilibrador de carga para las máquinas virtuales de un clúster VMAS.
Se requiere para buscar grupos de direcciones IP internas y de back-end del equilibrador de carga para una máquina virtual de un conjunto de escalado de máquinas virtuales.
Se requiere para buscar tamaños de máquina virtual y encontrar límites de volumen de AzureDisk.
Permisos adicionales de identidad de clúster
Al crear un clúster con atributos específicos, necesitará los siguientes permisos adicionales para la identidad del clúster. Dado que estos permisos no se asignan automáticamente, debe agregarlos a la identidad del clúster después de su creación.
Se requiere cuando se usa un grupo de seguridad de red en otro grupo de recursos. Se requiere para configurar reglas de seguridad para un servicio LoadBalancer.
Se requiere cuando se usa una subred asociada a una tabla de rutas en otro grupo de recursos (por ejemplo, una red virtual personalizada con una tabla de rutas personalizada). Se requiere para comprobar si ya existe una subred para la subred en el otro grupo de recursos.
Microsoft.Network/virtualNetworks/subnets/read
Se requiere cuando se usa un equilibrador de carga interno en otro grupo de recursos. Se requiere para comprobar si ya existe una subred para el equilibrador de carga interno en el grupo de recursos.
Microsoft.Network/privatednszones/*
Se requiere cuando se usa una subred en otro grupo de recursos (por ejemplo, una red privateDNSZone personalizada).
Acceso al nodo de AKS
De forma predeterminada, no se requiere acceso a los nodos para AKS. El siguiente acceso es necesario para el nodo si se utiliza un componente específico.
Acceso
Motivo
kubelet
Necesario para conceder acceso de MSI a ACR.
http app routing
Necesario para el permiso de escritura en "nombre aleatorio".aksapp.io.
container insights
Necesario para conceder permiso al área de trabajo de Log Analytics.
Resumen
Vea en la tabla un resumen rápido de cómo los usuarios pueden autenticarse en Kubernetes cuando la integración de Microsoft Entra está habilitada. En todos los casos, la secuencia de comandos del usuario es:
Ejecute az login para autenticarse en Azure.
Ejecute az aks get-credentials para descargar las credenciales del clúster en .kube/config.
Ejecute comandos kubectl.
El primer comando puede desencadenar la autenticación basada en explorador para autenticarse en el clúster, tal y como se describe en la tabla siguiente.
En Azure Portal, puede encontrar lo siguiente:
La concesión de roles (concesión de roles de Azure RBAC) a la que se hace referencia en la segunda columna se muestra en la pestaña Control de acceso.
El grupo de Microsoft Entra de administración del clúster se muestra en la pestaña Configuración.
También se encuentra con el nombre de parámetro --aad-admin-group-object-ids en la CLI de Azure.
Descripción
Concesión de rol requerida
Grupo(s) de Microsoft Entra de administración del clúster
Cuándo se usa
Inicio de sesión de administrador heredado con certificado de cliente
Rol de administrador de clústeres de Azure Kubernetes Service. Este rol permite usar az aks get-credentials con la marca --admin, que descarga un certificado de administrador de clústeres heredado (no de Microsoft Entra) en .kube/config del usuario. Este es el único propósito de "Rol de administrador de clústeres de Azure Kubernetes Service".
N/D
Si está bloqueado de forma permanente porque no tiene acceso a un grupo válido de Microsoft Entra con acceso al clúster.
Microsoft Entra ID con (Cluster)RoleBindings manual
Rol de usuario de clúster de Azure Kubernetes Service. El rol "Usuario" permite usar az aks get-credentials sin la marca --admin. (Este es el único propósito de "Rol de usuario de clúster de Azure Kubernetes Service"). El resultado, en un clúster habilitado para Microsoft Entra ID, es la descarga de una entrada vacía en .kube/config, que desencadena la autenticación basada en explorador cuando se usa por primera vez en kubectl.
El usuario no se encuentra en ninguno de estos grupos. Dado que el usuario no está en ningún grupo de administración de clústeres, cualquier RoleBindings o ClusterRoleBindings configurado por los administradores de clústeres controlarán por completo sus derechos. Los roles (Cluster)RoleBindings designan a los usuarios de Microsoft Entra o a los grupos de Microsoft Entra como sus subjects. Si no se ha configurado ningún enlace de este tipo, el usuario no podrá ejecutar ningún comando kubectl.
Si desea tener un control de acceso específico y no usa RBAC de Azure para la autorización de Kubernetes. Tenga en cuenta que el usuario que configura los enlaces debe iniciar sesión con uno de los otros métodos enumerados en esta tabla.
Microsoft Entra ID por miembro del grupo de administración
Lo mismo que antes.
El usuario es miembro de uno de los grupos que se indican aquí. AKS genera automáticamente un elemento ClusterRoleBinding que enlaza todos los grupos indicados al rol cluster-admin de Kubernetes. De este modo, los usuarios de estos grupos pueden ejecutar todos los comandos kubectl como cluster-admin.
Si desea conceder de forma práctica a los usuarios derechos de administrador completos y no usan RBAC de Azure para la autorización de Kubernetes.
Microsoft Entra ID con RBAC de Azure para la autorización de Kubernetes
Dos roles: En primer lugar, Rol de usuario de clúster de Azure Kubernetes Service (como se ha indicado anteriormente). En segundo lugar, uno de los roles RBAC de "Azure Kubernetes Service" indicados anteriormente, o su propia alternativa personalizada.
El campo de roles de administrador de la pestaña Configuración es irrelevante cuando está habilitada la autorización de RBAC de Azure para Kubernetes.
Usa RBAC de Azure para la autorización de Kubernetes. Este enfoque proporciona un control específico, sin necesidad de configurar RoleBindings o ClusterRoleBindings.
El origen de este contenido se puede encontrar en GitHub, donde también puede crear y revisar problemas y solicitudes de incorporación de cambios. Para más información, consulte nuestra guía para colaboradores.
Comentarios de Azure Kubernetes Service
Azure Kubernetes Service es un proyecto de código abierto. Seleccione un vínculo para proporcionar comentarios:
Explore cómo usar roles integrados de Azure, identidades administradas y directivas de RBAC para controlar el acceso a recursos de Azure. La identidad es la clave para proteger las soluciones.
Muestre las características de Microsoft Entra ID para modernizar las soluciones de identidad, implementar soluciones híbridas e implementar la gobernanza de identidades.