Compartir a través de

Controle el acceso con Microsoft Entra ID y Kubernetes RBAC para Windows Server

Se aplica a: AKS en Windows Server

Es posible configurar Azure Kubernetes Service (AKS) para que utilice Microsoft Entra ID para la autenticación de usuarios. En esta configuración, usted inicia sesión en un clúster de Kubernetes usando un token de autenticación de Microsoft Entra. Una vez autenticado, puede usar el control de acceso basado en rol de Kubernetes integrado (RBAC de Kubernetes) para administrar el acceso a los espacios de nombres y los recursos del clúster en función de la identidad o la pertenencia a grupos de un usuario.

Este artículo describe cómo controlar el acceso mediante Kubernetes RBAC en un clúster de Kubernetes, basado en la pertenencia a grupos de Microsoft Entra dentro de AKS Arc. Se crea un grupo de demostración y usuarios en Microsoft Entra ID. Luego, se crean roles y enlaces de rol en el clúster para otorgar los permisos adecuados para crear y ver recursos.

Requisitos previos

Antes de configurar Kubernetes RBAC usando Microsoft Entra ID, asegúrese de contar con los siguientes requisitos:

  • Un clúster de Kubernetes creado en AKS Arc. Si necesita configurar su clúster, consulte las instrucciones para hacerlo con Windows Admin Center o PowerShell para implementar AKS.
  • Conexión con Azure Arc. Debe tener una conexión de Azure Arc con su clúster de Kubernetes. Para obtener información sobre cómo habilitar Azure Arc, consulte: Conectar un clúster de Azure Kubernetes Service en Windows Server con Kubernetes habilitado para Azure Arc.
  • Necesita acceso a las siguientes herramientas de línea de comandos:
    • La CLI de Azure y la extensión connectedk8s. La CLI de Azure es un conjunto de comandos que se usan para crear y administrar recursos de Azure. Para comprobar si tiene CLI de Azure, abra una línea de comandos y escriba: az -v. También debe instalar la extensión connectedk8s para establecer un canal con su clúster de Kubernetes. Para obtener instrucciones de instalación, vea Cómo instalar CLI de Azure.
    • Kubectl. Esta herramienta de línea de comandos para Kubernetes le permite ejecutar comandos dirigidos a sus clústeres de Kubernetes. Para comprobar si instaló kubectl, abra un símbolo del sistema y escriba: kubectl version --client. Asegúrese de que la versión de su cliente kubectl sea al menos la versión v1.24.0. Para conocer las instrucciones de instalación, vea kubectl.
    • PowerShell y el módulo de PowerShell de AksHci. PowerShell es una solución de automatización de tareas multiplataforma que incluye un shell de línea de comandos, un lenguaje de scripting y un marco de administración de configuración. Si ya instaló AKS Arc, tiene acceso al módulo de PowerShell de AksHci.
    • Para acceder al clúster de Kubernetes desde cualquier ubicación en modo proxy usando el comando az connectedk8s proxy, necesita el permiso Microsoft.Kubernetes/connectedClusters/listClusterUserCredential/action, incluido en el rol de usuario del clúster de Kubernetes habilitado para Azure Arc. Además, verifique que los agentes y la máquina desde la que ejecuta el proceso de incorporación cumplan con los requisitos de red en requisitos de red de Kubernetes habilitado para Azure Arc.

Primeros pasos opcionales

Si aún no tiene un grupo de Microsoft Entra que contenga miembros, puede crear un grupo y agregar algunos miembros para seguir las instrucciones de este artículo.

Para demostrar el funcionamiento de Microsoft Entra ID con Kubernetes RBAC, puede crear un grupo de Microsoft Entra para desarrolladores de aplicaciones, y usarlo para mostrar cómo Microsoft Entra ID y Kubernetes RBAC controlan el acceso a los recursos del clúster. En entornos de producción, puede usar usuarios y grupos existentes dentro de un inquilino de Microsoft Entra.

Crear un grupo de demostración en Microsoft Entra ID

Primero, cree el grupo en Microsoft Entra ID dentro de su inquilino para los desarrolladores de aplicaciones usando el comando az ad group create. El siguiente ejemplo le solicita iniciar sesión en su inquilino de Azure y luego crea un grupo llamado appdev:

az login
az ad group create --display-name appdev --mail-nickname appdev

Agregar usuarios al grupo

Una vez creado el grupo de ejemplo en Microsoft Entra ID para desarrolladores de aplicaciones, agregue un usuario al grupo appdev. Usará esta cuenta de usuario para iniciar sesión en el clúster de AKS y probar la integración con Kubernetes RBAC.

Agregue un usuario al grupo appdev creado en la sección anterior utilizando el comando az ad group member add. Si cerró su sesión, vuelva a conectarse a Azure usando az login.

$AKSDEV_ID = az ad user create --display-name <name> --password <strongpassword> --user-principal-name <name>@contoso.onmicrosoft.com
az ad group member add --group appdev --member-id $AKSDEV_ID

Crear una asignación personalizada de rol RBAC de Kubernetes en el recurso del clúster de AKS para el grupo de Microsoft Entra

Configure el clúster de AKS para permitir que su grupo de Microsoft Entra acceda al clúster. Si desea agregar un grupo y usuarios, consulte Crear grupos de demostración en Microsoft Entra ID.

  1. Obtenga las credenciales de administrador del clúster mediante el comando Get-AksHciCredential:

    Get-AksHciCredential -name <name-of-your-cluster>

  2. Cree un espacio de nombres en el clúster de Kubernetes mediante el comando kubectl create namespace. En el ejemplo siguiente se crea un espacio de nombres denominado dev:

    kubectl create namespace dev

    En Kubernetes, los roles definen los permisos que conceder los enlaces de roles aplican los permisos a los usuarios o grupos deseados. Estas asignaciones se pueden aplicar a un espacio de nombres especificado o a todo el clúster. Para obtener más información, consulte Uso de la autorización de RBAC de Kubernetes.

    Cree un rol para el espacio de nombres dev. Este rol concede permisos completos al espacio de nombres. En entornos de producción, tal vez desee especificar permisos más granulares para diferentes usuarios o grupos.

  3. Cree un archivo llamado role-dev-namespace.yaml y copie/pegue el siguiente manifiesto de YAML:

    kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: dev-user-full-access
  namespace: dev
rules:
- apiGroups: ["", "extensions", "apps"]
  resources: ["*"]
  verbs: ["*"]
- apiGroups: ["batch"]
  resources:
  - jobs
  - cronjobs
  verbs: ["*"]

  4. Cree el rol mediante el comando kubectl apply y especifique el nombre de archivo del manifiesto de YAML:

    kubectl apply -f role-dev-namespace.yaml

  5. Obtenga el Id. de recurso para el grupo appdev mediante el comando az ad group show. Este grupo se establece como el sujeto de un enlace de rol en el paso siguiente:

    az ad group show --group appdev --query objectId -o tsv

    El comando az ad group show devuelve el valor que usará como groupObjectId:

    38E5FA30-XXXX-4895-9A00-050712E3673A

  6. Cree un archivo llamado rolebinding-dev-namespace.yaml y copie/pegue el siguiente manifiesto de YAML. Aquí establecerá el enlace de rol que permite al grupo appdev usar el rol role-dev-namespace para acceder al espacio de nombres. En la última línea, reemplace groupObjectId por la salida del id. de objeto de grupo producido por el comando az ad group show:

    kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: dev-user-access
  namespace: dev
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: dev-user-full-access
subjects:
- kind: Group
  namespace: dev
  name: groupObjectId

    Sugerencia

    Si desea crear el elemento RoleBinding para un solo usuario, especifique kind: User y reemplace groupObjectId por el nombre principal de usuario (UPN) en el ejemplo anterior.

  7. Cree el elemento RoleBinding mediante el comando kubectl apply y especifique el nombre de archivo del manifiesto de YAML:

    kubectl apply -f rolebinding-dev-namespace.yaml

    rolebinding.rbac.authorization.k8s.io/dev-user-access created

Uso de roles RBAC de Kubernetes integrados para el recurso de clúster de AKS

Kubernetes también proporciona roles integrados orientados al usuario. Estos roles integrados incluyen:

  • Roles de superusuario (administrador de clústeres)
  • Roles destinados a concederse en todo el clúster mediante ClusterRoleBindings
  • Roles destinados a concederse dentro de espacios de nombres concretos mediante RoleBindings (administrar, editar, visualizar)

Para obtener más información sobre los roles integrados de Kubernetes RBAC, consulte Roles orientados al usuario en Kubernetes RBAC.

Roles orientados al usuario

Default ClusterRole Default ClusterRoleBinding Descripción
cluster-admin system:masters group Permite acceso de superusuario para realizar cualquier acción sobre cualquier recurso. Cuando se usa en un ClusterRoleBinding, este rol otorga control total sobre todos los recursos del clúster y de todos los espacios de nombres. Cuando se usa en un RoleBinding, proporciona control total sobre cada recurso del espacio de nombres del enlace de roles, incluido el propio espacio de nombres.
admin None Permite acceso administrativo, diseñado para asignarse dentro de un espacio de nombres mediante un enlace de rol. Si se usa en un enlace de rol, permite acceso de lectura/escritura a la mayoría de los recursos dentro del espacio de nombres, incluida la capacidad de crear roles y enlaces de rol. Este rol no permite el acceso de escritura a la cuota de recursos o al espacio de nombres en sí. Este rol tampoco permite el acceso de escritura a los puntos de conexión en clústeres creados con Kubernetes v1.22 y versiones posteriores. Para obtener más información, consulte Acceso de escritura a puntos de conexión.
edición None Permite el acceso de lectura y escritura para ver la mayoría de los objetos en un espacio de nombres. Este rol no permite la visualización o modificación de roles o enlaces de roles. Sin embargo, este rol permite acceder a secretos 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. Este rol tampoco permite el acceso de escritura a los puntos de conexión en clústeres creados con Kubernetes v1.22 y versiones posteriores. Para obtener más información, consulte Acceso de escritura a puntos de conexión.
ver None 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. Este rol no permite visualización de secretos, ya que leer el contenido de estos permite el acceso a las credenciales de ServiceAccount en el espacio de nombres, que permitiría el acceso a la API como cualquier ServiceAccount en el espacio de nombres (una forma de elevación de privilegios).

Uso de un rol integrado de Kubernetes RBAC con Microsoft Entra ID

Para usar un rol RBAC integrado de Kubernetes con Microsoft Entra ID, siga estos pasos:

  1. Aplique el rol RBAC integrado de Kubernetes view a su grupo de Microsoft Entra:

    kubectl create clusterrolebinding <name of your cluster role binding> --clusterrole=view --group=<Azure AD group object ID>

  2. Aplique el rol RBAC integrado de Kubernetes view a cada uno de sus usuarios de Microsoft Entra:

    kubectl create clusterrolebinding <name of your cluster role binding> --clusterrole=view --user=<Azure AD user object ID>

Trabaje con recursos del clúster usando Microsoft Entra ID

Ahora pruebe los permisos esperados al crear y administrar recursos dentro del clúster de Kubernetes. En estos ejemplos, programe y vea los pods en el espacio de nombres asignados del usuario. A continuación, intente programar y ver los pods fuera del espacio de nombres asignado.

  1. Inicie sesión en Azure usando la cuenta de usuario $AKSDEV_ID que especificó como entrada en el comando az ad group member add. Ejecute el comando az connectedk8s proxy para abrir un canal en el clúster:

    az connectedk8s proxy -n <cluster-name> -g <resource-group>

  2. Una vez establecido el canal proxy, abra otra sesión y programe un pod de NGINX con el comando kubectl run en el espacio de nombres dev:

    kubectl run nginx-dev --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace dev

    Cuando NGINX se programa correctamente, debería ver la siguiente salida:

    pod/nginx-dev created

  3. Ahora, use el comando kubectl get pods para ver los pods en el espacio de nombres dev:

    kubectl get pods --namespace dev

    Cuando NGINX se esté ejecutando correctamente, debería ver la siguiente salida:

    NAME        READY   STATUS    RESTARTS   AGE
nginx-dev   1/1     Running   0          4m

Creación y visualización de los recursos de clúster fuera del espacio de nombres asignado

Para intentar ver pods fuera del espacio de nombres dev, utilice el comando kubectl get pods con el indicador --all-namespaces:

kubectl get pods --all-namespaces

La pertenencia a grupos del usuario no tiene un rol de Kubernetes que permita esta acción. Sin ese permiso, el comando genera un error:

Error from server (Forbidden): pods is forbidden: User cannot list resource "pods" in API group "" at the cluster scope

Pasos siguientes