Procedimientos recomendados para la autenticación y autorización en Azure Kubernetes Service (AKS)

Artículo
08/02/2024

A medida que implementa y mantiene clústeres en Azure Kubernetes Service (AKS), deberá implementar maneras de administrar el acceso a los recursos y servicios. Sin estos controles:

Las cuentas podrían tener acceso a recursos y servicios innecesarios.
Puede ser difícil realizar el seguimiento de las credenciales que se utilizan para hacer cambios.

En este artículo, se describen los procedimientos recomendados que puede seguir un operador de clústeres para administrar el acceso y la identidad de los clústeres de AKS. Aprenderá a:

Autenticar a los usuarios de clústeres de AKS con Microsoft Entra ID.
Controlar el acceso a los recursos con el control de acceso basado en roles de Kubernetes (RBAC de Kubernetes).
Usar RBAC de Azure para controlar en detalle el acceso al recurso de AKS, a Kubernetes API a escala y a kubeconfig.
Use una identidad de carga de trabajo para acceder a los recursos de Azure desde los pods.

Advertencia

La identidad administrada por pods de Microsoft Entra de código abierto (versión preliminar) en Azure Kubernetes Service ha quedado en desuso a partir del 24/10/2022.

Si habilitó la identidad administrada por pod de Microsoft Entra en el clúster de AKS o está pensando implementarla, se recomienda revisar el artículo de introducción a las identidades de carga de trabajo para comprender nuestras recomendaciones y opciones a fin de configurar el clúster para utilizar una entidad de carga de trabajo de Microsoft Entra (versión preliminar). Este método de autenticación reemplaza la identidad administrada por pod (versión preliminar), que se integra con las funcionalidades nativas de Kubernetes para federarse con cualquier proveedor de identidades externo.

Uso de Microsoft Entra ID

Guía de procedimientos recomendados

Implementación de clústeres de AKS con integración de Microsoft Entra. Con Microsoft Entra ID, se centraliza la capa de administración de identidades. Cualquier cambio en el estado del grupo o cuenta del usuario se actualiza automáticamente al acceder al clúster de AKS. Establezca el ámbito de los usuarios o grupos en la cantidad mínima de permisos mediante roles, ClusterRoles o enlaces.

Los desarrolladores del clúster de Kubernetes y propietarios de aplicaciones necesitan acceder a diferentes recursos. Kubernetes carece de una solución de administración de identidades para controlar los recursos con los que los usuarios pueden interactuar. En su lugar, puede integrar el clúster con una solución de identidad existente como Microsoft Entra ID, una solución de administración de identidades lista para la empresa.

Con los clústeres integrados con Microsoft Entra en AKS, podrá crear roles o ClusterRoles que definan los permisos de acceso a los recursos. A continuación, enlaza los roles a usuarios o grupos de Microsoft Entra ID. Más información sobre estos RBAC de Kubernetes en la sección siguiente. En el diagrama siguiente se muestran la integración de Microsoft Entra y la forma de controlar el acceso a los recursos:

Autenticación de nivel de clúster para la integración de Microsoft Entra con AKS

El desarrollador se autentica con Microsoft Entra ID.
El punto de conexión de emisión de tokens de Microsoft Entra emite el token de acceso.
El desarrollador realiza una acción con el token de Microsoft Entra, como kubectl create pod.
Kubernetes valida el token con Microsoft Entra ID y recupera las pertenencias a grupos del desarrollador.
Se aplican las directivas del clúster y de RBAC de Kubernetes.
La solicitud del desarrollador es correcta en función de la validación anterior de pertenencia a grupos de Microsoft Entra, y las directivas y RBAC de Kubernetes.

Para crear un clúster de AKS que use Microsoft Entra ID, consulte Integración de Microsoft Entra ID con AKS.

Uso del control de acceso basado en roles de Kubernetes (RBAC de Kubernetes)

Guía de procedimientos recomendados

Defina permisos de usuario o grupo para agrupar recursos con RBAC de Kubernetes. Cree roles y enlaces que asignen la mínima cantidad de permisos necesarios. Use la integración de Microsoft Entra ID para actualizar automáticamente cualquier cambio de estado de usuario o pertenencia a grupos y mantener el acceso a los recursos del clúster actual.

En Kubernetes se proporciona control de acceso pormenorizado a los recursos del clúster. Los permisos se definen en el nivel de clúster, así como en espacios de nombres específicos. Determine qué recursos se pueden administrar y con qué permisos. A continuación, aplique estos roles a los usuarios o grupos con un enlace. Para obtener más información sobre los roles, ClusterRoles y enlaces, consulte Opciones de acceso e identidad en Azure Kubernetes Service (AKS).

Por ejemplo, puede crear un rol con acceso total a los recursos del espacio de nombres denominado finance-app, tal como se muestra en el ejemplo de manifiesto de YAML siguiente:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: finance-app-full-access-role
  namespace: finance-app
rules:
- apiGroups: [""]
  resources: ["*"]
  verbs: ["*"]

A continuación, cree un elemento RoleBinding y enlace a él el usuario de Microsoft Entra ID developer1@contoso.com, tal como se muestra en el manifiesto de YAML siguiente:

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: finance-app-full-access-role-binding
  namespace: finance-app
subjects:
- kind: User
  name: developer1@contoso.com
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: finance-app-full-access-role
  apiGroup: rbac.authorization.k8s.io

Cuando developer1@contoso.com se autentica en el clúster de AKS, este tendrá permisos completos sobre los recursos en el espacio de nombres finance-app. De esta forma, separa y controla el acceso a los recursos de forma lógica. Uso de RBAC de Kubernetes con la integración de Microsoft Entra ID.

Para aprender a usar los grupos de Microsoft Entra para controlar el acceso a los recursos de Kubernetes mediante RBAC de Kubernetes, consulte Administración del acceso a recursos de clúster mediante el control de acceso basado en roles y las identidades de Microsoft Entra en Azure Kubernetes Service.

Uso de Azure RBAC

Guía de procedimientos recomendados

Use RBAC de Azure para definir los permisos mínimos de los usuarios o grupos de los recursos de AKS en una o más suscripciones.

Hay dos niveles de acceso necesarios para operar completamente un clúster de AKS:

Acceda al recurso de AKS en la suscripción de Azure.

Este nivel de acceso permite:
- Controlar el escalado o la actualización del clúster mediante las API de AKS.
- Extraer kubeconfig.
Para aprender a controlar el acceso al recurso de AKS y a kubeconfig, consulte Limitación del acceso al archivo de configuración de clúster.
Acceso al API de Kubernetes.

Este nivel de acceso se controla mediante:
- RBAC de Kubernetes (tradicionalmente), o bien,
- mediante la integración de RBAC de Azure con AKS para la autorización de Kubernetes.
Para aprender a conceder permisos pormenorizados a la API de Kubernetes mediante el uso de RBAC de Azure, consulte Uso de la autorización de Azure RBAC para Kubernetes.

Uso de identidades administradas por pod

Advertencia

La identidad administrada por pods de Microsoft Entra de código abierto (versión preliminar) en Azure Kubernetes Service ha quedado en desuso a partir del 24/10/2022.

No use credenciales fijas dentro de pods o imágenes de contenedor, ya que corren riesgo de exposición o abuso. En su lugar, use identidades de pod para solicitar acceso automáticamente mediante Microsoft Entra ID.

Para acceder a otros recursos de Azure, como Azure Cosmos DB, Key Vault o Blob Storage, el pod necesita credenciales de autenticación. Puede definir las credenciales de autenticación con la imagen de contenedor o insertarlas como secreto de Kubernetes. En cualquier caso, tendría que crearlas y asignarlas manualmente. A menudo, las credenciales se reutilizan en los pods y no se rotan de forma periódica.

Con las identidades administradas por pod (versión preliminar) para los recursos de Azure, podrá solicitar acceso de manera automática a los servicios por medio de Microsoft Entra ID. Las identidades administradas por pod están actualmente en versión preliminar para AKS. Consulte la documentación Uso de identidades administradas del pod de Microsoft Entra en Azure Kubernetes Service (versión preliminar) para comenzar.

La identidad administrada de pod de Microsoft Entra (versión preliminar) admite dos modos de operación:

Modo estándar: en este modo, se implementan los dos componentes siguientes en el clúster de AKS:
- Controlador de identidades administradas (MIC): un controlador de Kubernetes que busca cambios en los pods, en AzureIdentity y en AzureIdentityBinding mediante el servidor de API de Kubernetes. Cuando se detectan cambios importantes, el MIC agrega o elimina AzureAssignedIdentity según sea necesario. En concreto, cuando se programa un pod, el MIC asigna la identidad administrada en Azure al conjunto de escalado de máquinas virtuales subyacente utilizado por el grupo de nodos durante la fase de creación. Cuando se eliminan todos los pods que usan la identidad, se quita la identidad del conjunto de escalado de máquinas virtuales del grupo de nodos, a menos que otros pods usen la misma identidad administrada. El MIC realiza acciones similares cuando se crea o elimina AzureIdentity o AzureIdentityBinding.
- Identidad administrada del nodo (NMI): es un pod que se ejecuta como DaemonSet en cada nodo del clúster de AKS. NMI intercepta las solicitudes de token de seguridad a Azure Instance Metadata Service en cada nodo. Redirige las solicitudes a sí mismo y valida si el pod tiene acceso a la identidad para la que se solicita un token y, luego, captura el token del inquilino de Microsoft Entra en nombre de la aplicación.
Modo administrado: en este modo, solo hay NMI. El usuario debe asignar y administrar manualmente la identidad. Para más información, consulte Pod Identity en modo administrado. En este modo, cuando se usa el comando az aks pod-identity add para agregar una identidad de pod a un clúster de Azure Kubernetes Service (AKS), se crean AzureIdentity y AzureIdentityBinding en el espacio de nombres especificado por el parámetro --namespace, mientras que el proveedor de recursos de AKS asigna la identidad administrada especificada por el parámetro --identity-resource-id al conjunto de escalado de máquinas virtuales de cada grupo de nodos del clúster de AKS.

Nota:

En cambio, si decide instalar la identidad administrada por pod de Microsoft Entra mediante el complemento de clúster de AKS, el programa de instalación utiliza el modo managed.

El modo managed proporciona las ventajas siguientes sobre el modo standard:

La asignación de identidades en el conjunto de escalado de máquinas virtuales de un grupo de nodos puede tardar entre 40 y 60 segundos. Con cronjobs o aplicaciones que requieren acceso a la identidad y no pueden tolerar el retraso de asignación, es mejor usar el modo managed, ya que la identidad se asigna previamente al conjunto de escalado de máquinas virtuales del grupo de nodos. Manualmente o con el comando az aks pod-identity add.
En modo standard, el MIC requiere permisos de escritura en el conjunto de escalado de máquinas virtuales que el clúster de AKS utiliza y el permiso Managed Identity Operator en las entidades administradas asignadas por el usuario. Al ejecutarse en managed mode, y como no hay ningún MIC, no se requieren asignaciones de roles.

En lugar de definir manualmente las credenciales de los pods, las identidades administradas por pod solicitan un token de acceso en tiempo real y lo usan para acceder solo a sus recursos asignados. En AKS hay dos componentes que controlan las operaciones para permitir que los pods usen identidades administradas:

El servidor de identidad de administración de nodos (NMI) es un pod que se ejecuta como DaemonSet en cada nodo del clúster de AKS. El servidor de NMI escucha las solicitudes de pods para servicios de Azure.
El proveedor de recursos de Azure consulta al servidor de API de Kubernetes y busca una asignación de identidad de Azure que corresponda a un pod.

Cuando los pods solicitan un token de seguridad a Microsoft Entra ID para acceder a un recurso de Azure, las reglas de red redirigen el tráfico al servidor NMI.

El servidor NMI:
- Identifica los pods que solicitan acceso a los recursos de Azure en función de su dirección remota.
- Consulta al proveedor de recursos de Azure.
El proveedor de recursos de Azure las asignaciones de identidad de Azure en el clúster de AKS.
El servidor NMI solicita un token de acceso de Microsoft Entra ID en función de la asignación de identidad del pod.
Microsoft Entra ID proporciona acceso al servidor de NMI, que se devuelve al pod.
- El pod puede usar este token de acceso para, después, solicitar acceso a los recursos de Azure.

En el ejemplo siguiente, un desarrollador crea un pod que usa una identidad administrada para solicitar acceso a Azure SQL Database:

Las identidades de pod permiten que un pod solicite acceso a otros recursos automáticamente.

El operador de los clústeres crea una cuenta de servicio para asignar identidades cuando los pods solicitan acceso a los recursos.
El servidor de NMI se implementa para retransmitir las solicitudes de los pods, y del proveedor de recursos de Azure, de tokens de acceso a Microsoft Entra ID.
Un desarrollador implementa un pod con una identidad administrada que solicita un token de acceso a través del servidor de NMI.
El token se devuelve al pod y se utiliza para obtener acceso a Azure SQL Database.

Para usar identidades administradas de pod, vea Uso de identidades administradas del pod de Microsoft Entra en Azure Kubernetes Service (versión preliminar).

Pasos siguientes

Este artículo de procedimientos recomendados se centra en la autenticación y autorización para el clúster y los recursos. Para implementar algunos de estos procedimientos recomendados, consulte los artículos siguientes:

Para obtener más información acerca de las operaciones de clúster en AKS, consulte los siguientes procedimientos recomendados:

Compartir a través de