Control del acceso mediante el identificador de Entra de Microsoft y RBAC de Kubernetes para Windows Server

Artículo
08/10/2024

Se aplica a: AKS en Azure Stack HCI 22H2, 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, inicie sesión en un clúster de Kubernetes mediante 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.

En este artículo se describe cómo controlar el acceso mediante RBAC de Kubernetes en un clúster de Kubernetes basado en la pertenencia a grupos de Microsoft Entra en AKS Arc. Cree un grupo de demostración y usuarios en el identificador de Entra de Microsoft. A continuación, creará roles y enlaces de rol en el clúster para conceder los permisos adecuados para crear y ver los recursos.

Requisitos previos

Antes de configurar RBAC de Kubernetes mediante el identificador de Microsoft Entra, necesita los siguientes requisitos previos:

Un clúster de Kubernetes creado en AKS Arc. Si necesita configurar el clúster, consulte las instrucciones para usar Windows Admin Center o PowerShell para implementar AKS.
Conexión de Azure Arc. Debe tener una conexión de Azure Arc al clúster de Kubernetes. Para más información sobre cómo habilitar Azure Arc, consulte Conexión de un clúster de Azure Kubernetes Service en Azure Local a Kubernetes habilitado para Azure Arc.
Necesita acceso a las siguientes herramientas de línea de comandos:
- 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 la CLI de Azure, abra una herramienta de línea de comandos y escriba: az -v. Además, instale la extensión connectedk8s para abrir un canal en el clúster de Kubernetes. Para obtener instrucciones de instalación, consulte Instalación de la CLI de Azure.
- Kubectl. Esta herramienta de línea de comandos de Kubernetes permite ejecutar comandos destinados a los 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 del cliente kubectl sea al menos la versión v1.24.0. Para obtener instrucciones de instalación, consulte kubectl.
- PowerShell y el módulo de PowerShell de AksHci. PowerShell es una solución de automatización de tareas multiplataforma formada por un shell de línea de comandos, un lenguaje de scripting y un marco de administración de configuración. Si instaló AKS Arc, tiene acceso al módulo de PowerShell de AksHci .
- Para acceder al clúster de Kubernetes desde cualquier lugar con un modo de proxy mediante az connectedk8s proxy el comando , necesita el permiso De usuario de clúster de Kubernetes/connectedClusters/listClusterUserCredential/action, que se incluye en el permiso de usuario de clúster de Kubernetes habilitado para Azure Arc. Mientras tanto, debe comprobar que los agentes y la máquina que realizan el proceso de incorporación cumplen los requisitos de red en los requisitos de red habilitados para Azure Arc para Kubernetes.

Primeros pasos opcionales

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

Para demostrar cómo trabajar con RBAC de Microsoft Entra y Kubernetes, puede crear un grupo de Microsoft Entra para desarrolladores de aplicaciones que se pueden usar para mostrar cómo RBAC de Kubernetes y el id. de Microsoft Entra 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.

Creación de un grupo de demostración en el identificador de Microsoft Entra

En primer lugar, cree el grupo en microsoft Entra ID en el inquilino para los desarrolladores de aplicaciones mediante el az ad group create comando . En el ejemplo siguiente se le pide que inicie sesión en el inquilino de Azure y, a continuación, cree un grupo denominado appdev:

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

Agregar usuarios al grupo

Con el grupo de ejemplo creado en microsoft Entra ID para desarrolladores de aplicaciones, agregue un usuario al appdev grupo. Use esta cuenta de usuario para iniciar sesión en el clúster de AKS y probar la integración de RBAC de Kubernetes.

Agregue un usuario al grupo appdev creado en la sección anterior mediante el az ad group member add comando . Si abandona la sesión, vuelva a conectarse a Azure mediante 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

Creación de un enlace de rol RBAC de Kubernetes personalizado en el recurso de clúster de AKS para el grupo Microsoft Entra

Configure el clúster de AKS para permitir que el 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.

Obtenga las credenciales de administrador del clúster mediante el Get-AksHciCredential comando :
```
Get-AksHciCredential -name <name-of-your-cluster>
```
Cree un espacio de nombres en el clúster de Kubernetes mediante el kubectl create namespace comando . 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 determinado o a todo un clúster. Para obtener más información, consulte Uso de la autorización de RBAC Kubernetes.

Cree un rol para el espacio de nombres de desarrollo . Este rol concede permisos completos al espacio de nombres. En entornos de producción, es posible que quiera especificar permisos más granulares para distintos usuarios o grupos.

Cree un archivo denominado role-dev-namespace.yaml y copie o pegue el siguiente manifiesto 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: ["*"]

Cree el rol con el kubectl apply comando y especifique el nombre de archivo del manifiesto YAML:
```
kubectl apply -f role-dev-namespace.yaml
```
Obtenga el Id. de recurso para el grupo appdev mediante el comando az ad group show. Este grupo se establece como el asunto de un RoleBinding en el paso siguiente:
```
az ad group show --group appdev --query objectId -o tsv
```
El az ad group show comando devuelve el valor que se usa como groupObjectId:
```
38E5FA30-XXXX-4895-9A00-050712E3673A
```
Cree un archivo denominado rolebinding-dev-namespace.yaml y copie o pegue el siguiente manifiesto YAML. Establezca el enlace de roles que permite al grupo appdev usar el rol para el role-dev-namespace acceso 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.

Cree roleBinding con el kubectl apply comando y especifique el nombre de archivo del manifiesto 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 más información sobre los roles RBAC de Kubernetes integrados, consulte Roles orientados al usuario de RBAC de Kubernetes.

Roles orientados al usuario

Default ClusterRole	Default ClusterRoleBinding	Descripción
cluster-admin	system:masters group	Permite el acceso de superusuario para realizar cualquier acción en cualquier recurso. Cuando se usa en ClusterRoleBinding, este rol proporciona control total sobre todos los recursos del clúster y en 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.
Administración	Ninguno	Permite el acceso de administrador, destinado a concederse dentro de un espacio de nombres mediante un enlace de roles. Si se usa en un enlace de roles, 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í. Este rol tampoco permite el acceso de escritura a los puntos de conexión de los clústeres creados con Kubernetes v1.22 y versiones posteriores. Para obtener más información, consulte Acceso de escritura para puntos de conexión.
edit	Ninguno	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 API de cualquier ServiceAccount en el espacio de nombres. Este rol tampoco permite el acceso de escritura a los puntos de conexión de los clústeres creados con Kubernetes v1.22 y versiones posteriores. Para obtener más información, consulte Acceso de escritura para puntos de conexión.
ver	Ninguno	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 ver secretos, ya que leer el contenido de los secretos 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 escalación de privilegios).

Uso de un rol RBAC de Kubernetes integrado con el identificador entra de Microsoft

Para usar un rol RBAC de Kubernetes integrado con el identificador entra de Microsoft, siga estos pasos:

Aplique el rol RBAC de Kubernetes integrado view al grupo de Microsoft Entra:

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

Aplique el rol RBAC de Kubernetes integrado view a cada uno de los usuarios de Microsoft Entra:

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

Trabajar con recursos de clúster mediante identificadores de Microsoft Entra

Ahora, pruebe los permisos esperados al crear y administrar recursos en un 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 pods fuera del espacio de nombres asignado.

Inicie sesión en Azure con la $AKSDEV_ID cuenta de usuario que especificó como entrada para el az ad group member add comando. Ejecute el az connectedk8s proxy comando para abrir un canal en el clúster:
```
az connectedk8s proxy -n <cluster-name> -g <resource-group>
```
Una vez establecido el canal de proxy, abra otra sesión y programe un pod NGINX mediante el kubectl run comando en el espacio de nombres de desarrollo :
```
kubectl run nginx-dev --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace dev
```
Cuando NGINX está programado correctamente, debería ver la siguiente salida:
```
pod/nginx-dev created
```
Ahora, use el kubectl get pods comando para ver pods en el dev espacio de nombres:
```
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 recursos de clúster fuera del espacio de nombres asignado

Para intentar ver pods fuera del espacio de nombres de desarrollo , use el kubectl get pods comando con la --all-namespaces marca :

kubectl get pods --all-namespaces

La pertenencia a grupos del usuario no tiene un rol de Kubernetes que permita esta acción. Sin el 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

Más información sobre la seguridad en AKS Arc en Windows Server

Compartir a través de