Compartir a través de

Opciones de acceso e identidad para AKS habilitadas por Azure Arc

  • Artículo

Se aplica a: AKS en Azure Stack HCI 23H2

Puede autenticar, autorizar, proteger y controlar el acceso a clústeres de Kubernetes de varias maneras:

RBAC de Kubernetes y RBAC de Azure 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.

Para obtener más información, consulte Uso de la autorización de RBAC de Kubernetes.

Roles y ClusterRoles

Roles

Antes de asignar permisos a los usuarios con RBAC de Kubernetes, debe definir los permisos de usuario como un rol. Conceda permisos dentro de un espacio de nombres de Kubernetes mediante roles.

Los roles de Kubernetes conceden permisos; no los deniegan. Para conceder permisos en todo el clúster o en recursos de clúster fuera de un espacio de nombres determinado, puede usar 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.

RoleBindings y ClusterRoleBindings

Una vez que defina roles para conceder permisos a los recursos, asigne esos permisos de RBAC de Kubernetes con roleBinding. Si el clúster de AKS se integra con Microsoft Entra ID, los RoleBindings conceden permisos a los usuarios de Microsoft Entra para que realicen acciones en el clúster. Consulte Control del acceso mediante el identificador de Entra de Microsoft y RBAC de Kubernetes.

RoleBindings

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 a recursos de clúster fuera de un espacio de nombres determinado, use 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.

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 la cuenta de servicio se almacenan como secretos de Kubernetes, lo que les permite 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 Autenticación de 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 una administración de acceso específica de 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.

Para obtener más información, consulte ¿Qué es el control de acceso basado en roles (RBAC) de Azure?

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

  • Acceso al recurso de AKS en la suscripción de Azure
    • Controle el escalado o actualización del clúster mediante las API de Azure Arc habilitadas para AKS.
    • Extraiga el administrador, kubeconfig basado en certificados.
    • Extraiga el identificador de Entra habilitado kubeconfig.
  • Acceso al API de Kubernetes. Este acceso se controla mediante:
    • RBAC de Kubernetes o
    • Integración de RBAC de Azure con AKS para la autorización de Kubernetes.

Azure RBAC para autorizar el acceso al recurso de AKS

Con Azure RBAC, puede proporcionar a los usuarios (o identidades) acceso granular a los recursos de AKS en una o varias suscripciones. Hay tres roles disponibles para esta acción del plano de control: rol de administrador de clústeres de Azure Kubernetes Service Arc, rol de usuario de clúster de Azure Kubernetes Service Arc y rol de colaborador de Azure Kubernetes Service Arc. Cada rol tiene un ámbito de permisos diferente, tal como se describe en Roles integrados de Azure para contenedores. Por ejemplo, puede usar el rol Colaborador de Azure Kubernetes Service Arc para crear, escalar y actualizar el clúster. Mientras tanto, otro usuario con el rol de administrador de clústeres de Azure Kubernetes Service Arc solo tiene permiso para extraer el kubeconfig administrador.

RBAC de Azure para la autorización de Kubernetes

Con la integración de RBAC de Azure, AKS usa un servidor de webhook de autorización de Kubernetes para que pueda administrar los permisos y asignaciones de recursos del clúster de Kubernetes integrados de Microsoft Entra mediante la definición de roles y las asignaciones de roles de Azure.

Diagrama del flujo de autorización.

Como se muestra en este diagrama, al usar la integración de RBAC de Azure, todas las solicitudes a la API de Kubernetes siguen el mismo flujo de autenticación que se describe en integración de Microsoft Entra.

Si la identidad que realiza la solicitud existe en microsoft Entra ID, los equipos de Azure con RBAC de Kubernetes para autorizar la solicitud. Si la identidad existe fuera del identificador de Entra de Microsoft (por ejemplo, una cuenta de servicio de Kubernetes), la autorización se aplaza 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. Hay cuatro roles integrados disponibles para esta acción del plano de datos, cada uno con su propio ámbito de permisos, como se describe en la sección roles integrados.

Importante

Debe habilitar RBAC de Azure para la autorización de Kubernetes antes de realizar la asignación de roles. Para más información y instrucciones paso a paso, consulte Uso de RBAC de Azure para la autorización de Kubernetes.

Roles integrados

AKS habilitado por Arc proporciona los cinco roles integrados siguientes. Son similares a los roles integrados de Kubernetes con algunas diferencias, como admitir CRD. Consulte la lista completa de acciones permitidas por cada rol integrado de Azure.

Role Descripción
Usuario de clúster de Kubernetes habilitado para Azure Arc Permite recuperar el archivo kubeconfig basado en Cluster Connect para administrar clústeres desde cualquier lugar.
Visor de Azure Arc Kubernetes Permite el acceso de solo lectura para ver la mayoría de los objetos en un espacio de nombres.
No permite ver secretos, ya que el permiso de lectura en secretos permite el acceso a las credenciales de ServiceAccount en el espacio de nombres. Estas credenciales permiten a su vez el acceso a la API a través de ese valor serviceAccount (una forma de escalación de privilegios).
Escritor de Azure Arc Kubernetes Permite el acceso de lectura y escritura para ver la mayoría de los objetos en un espacio de nombres.
No permite ver ni modificar roles ni enlaces de roles. Sin embargo, este rol permite acceder a secretos y ejecutar pods como cualquier valor ServiceAccount en el espacio de nombres, por lo que se puede usar para obtener los niveles de acceso de API de cualquier valor serviceAccount en el espacio de nombres.
Administrador de Azure Arc Kubernetes Permite el acceso de administrador. Está pensado para concederse dentro de un espacio de nombres a través de RoleBinding. Si lo usa en RoleBinding, permite el acceso de lectura y escritura a la mayoría de los recursos de un espacio de nombres, incluida la capacidad de crear roles y enlaces de roles dentro del espacio de nombres. Este rol no permite el acceso de escritura a la cuota de recursos o al espacio de nombres en sí.
Administrador de clústeres de Azure Arc Kubernetes Permite el acceso de "superusuario" para ejecutar cualquier acción en cualquier recurso. Cuando se usa en ClusterRoleBinding, proporciona control total sobre todos los recursos del clúster y en todos los espacios de nombres. Cuando se usa en RoleBinding, proporciona control total sobre todos los recursos del espacio de nombres de enlace de roles, incluido el propio espacio de nombres.

Integración de Microsoft Entra

Mejore la seguridad del clúster de AKS con la integración de Microsoft Entra. Basado en la experiencia de administración de identidades empresariales, Microsoft Entra ID es un servicio de administración de identidades y directorios multiinquilino basado en la nube que combina los servicios de directorio principales, la administración del acceso a 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.

Diagrama de flujo que muestra la integración de Entra.

Con los clústeres de AKS integrados en Microsoft Entra, puede conceder a los usuarios o grupos acceso a los recursos de Kubernetes dentro de un espacio de nombres o en todo el clúster.

  • Para obtener un contexto de configuración kubectl , ejecute el comando az aksarc get-credentials .
  • Cuando un usuario interactúa con el clúster de AKS mediante kubectl, se le pedirá 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 según lo definido por el administrador del clúster de Kubernetes.

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. Para obtener más información sobre OpenID Connect, consulte la documentación de OpenID Connect. Desde el clúster de Kubernetes, la autenticación de token de webhook se usa para comprobar los tokens de autenticación. La autenticación de token de webhook se configura y administra como parte del clúster de AKS.

Resumen

La tabla siguiente contiene un resumen 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 es:

  1. Ejecute az login para autenticarse en Azure.
  2. Ejecute az aksarc get-credentials para descargar las credenciales del clúster de Kubernetes en .kube/config.
  3. Ejecute comandos kubectl.
    • El primer comando puede desencadenar la autenticación basada en explorador para autenticarse en el clúster de Kubernetes, como se describe en la tabla siguiente.
Descripción Concesión de rol requerida Grupos de Administración de clústeres de Microsoft Entra Cuándo se deben usar
Inicio de sesión de administrador mediante el certificado de cliente Rol de administrador de clústeres de Azure Kubernetes Service Arc. Este rol permite az aksarc get-credentials usarse con la --admin marca , que descarga un certificado de administrador de clúster que no es de Microsoft Entra en el archivo .kube/config del usuario. Este es el único propósito del rol de administrador de Azure Kubernetes. 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.
Id. de Entra de Microsoft con RoleBindings manual (clúster) Rol de usuario de clúster de Azure Kubernetes Service Arc. El rol Usuario permite az aksarc get-credentials usarse sin la --admin marca . Este es el único propósito del rol de usuario de clúster de Azure Kubernetes Service). El resultado, en un clúster habilitado para id. de Microsoft Entra, es la descarga de una entrada vacía en .kube/config, que desencadena la autenticación basada en explorador cuando kubectl la usa por primera vez. Dado que el usuario no está en ningún grupo de administración de clústeres, los administradores del clúster controlan sus derechos por completo mediante roleBindings o ClusterRoleBindings configurados por los administradores de clústeres. RoleBindings (Clúster) designa a los usuarios de Microsoft Entra o a los grupos de Microsoft Entra como sus temas. Si no se ha configurado ningún enlace de este tipo, el usuario no puede excute 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.
Id. de Microsoft Entra por miembro del grupo Microsoft Entra de administrador del clúster (establecido mediante --aad-admin-group-object-ids la marca en la CLI de Azure) Igual que lo anterior. 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 quiere conceder derechos de administrador completos a los usuarios y no usa RBAC de Azure para la autorización de Kubernetes.
Identificador de Entra de Microsoft con Azure RBAC para la autorización de Kubernetes Dos roles:
Rol de usuario de clúster de Azure Kubernetes Service Arc (como se ha descrito anteriormente).
Uno de los roles de Kubernetes de Azure Arc descritos anteriormente o su propia alternativa personalizada.		 El campo Roles de administrador de la pestaña Configuración es irrelevante cuando azure RBAC para la autorización de Kubernetes está habilitado. Use RBAC de Azure para la autorización de Kubernetes. Este enfoque proporciona un control específico, sin necesidad de configurar RoleBindings o ClusterRoleBindings.

Pasos siguientes