Utilizar el control de acceso basado en roles de Kubernetes con Microsoft Entra ID en Azure Kubernetes Service

Artículo
10/25/2023

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 AKS 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 aprenderá a:

Control del acceso mediante RBAC de Kubernetes en un clúster de AKS en función de la pertenencia a grupos de Microsoft Entra.
Cree grupos y usuarios de ejemplo en Microsoft Entra ID.
Cree roles y RoleBindings en el clúster de AKS para conceder los permisos adecuados a fin de crear y ver recursos.

Antes de empezar

Tiene un clúster de AKS existente con la integración de Microsoft Entra habilitada. Si necesita un clúster de AKS con esta configuración, vea Integración de Microsoft Entra ID con AKS.
RBAC de Kubernetes está habilitado de manera predeterminada durante la creación del clúster de AKS. Para actualizar el clúster con la integración de Microsoft Entra y RBAC de Kubernetes, habilite la integración de Microsoft Entra en el clúster de AKS existente.
Asegúrese de que la versión 2.0.61 o una posterior de la CLI de Azure está instalada y configurada. Ejecute az --version para encontrar la versión. Si necesita instalarla o actualizarla, vea Instalación de la CLI de Azure.
Si usa Terraform, instale Terraform versión 2.99.0 o una posterior.

Use Azure Portal o la CLI de Azure para comprobar si la integración de Microsoft Entra con RBAC de Kubernetes está habilitada.

Azure Portal
CLI de Azure

Para comprobar el uso de Azure Portal:

En el explorador, inicie sesión en Azure Portal.
Vaya a Servicios de Kubernetes y, en el panel izquierdo, seleccione Configuración del clúster.
En la sección Autenticación y autorización, compruebe si la opción de autenticación de Microsoft Entra con RBAC de Kubernetes está seleccionada.

Puede comprobar mediante el comando az aks show de la CLI de Azure. Reemplace el valor myResourceGroup por el nombre del grupo de recursos que hospeda el recurso de clúster de AKS y reemplace myAKSCluster por el nombre real del clúster de AKS.

az aks show --resource-group myResourceGroup --name myAKSCluster

Si está habilitado, la salida muestra que el valor de enableAzureRbac es false.

Crear grupos de demostración en Microsoft Entra ID

En este artículo, se crearán dos roles de usuario para mostrar cómo Kubernetes RBAC y Microsoft Entra ID controlan el acceso a recursos de clúster. Se usan los siguientes dos roles de ejemplo:

Desarrollador de aplicaciones
- Un usuario denominado aksdev que forma parte del grupo appdev.
Ingeniero encargado de garantizar la fiabilidad del sitio (SRE, por sus siglas en inglés)
- Un usuario denominado akssre que forma parte del grupoopssre.

En entornos de producción, puede usar usuarios y grupos existentes dentro de un inquilino de Microsoft Entra.

En primer lugar, obtenga el identificador de recurso de clúster de AKS mediante el comando az aks show. Después, asigne el id. de recurso a una variable denominada AKS_ID de manera que se pueda hacer referencia en otros comandos.
```
AKS_ID=$(az aks show \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --query id -o tsv)
```
Cree el primer grupo de ejemplo en Microsoft Entra ID para los desarrolladores de aplicaciones mediante el comando az ad group create. En el ejemplo siguiente se crea un grupo de recursos denominado appdev:
```
APPDEV_ID=$(az ad group create --display-name appdev --mail-nickname appdev --query id -o tsv)
```
Cree una asignación de roles de Azure para el grupo appdev con el comando az role assignment create. Esta asignación permite que cualquier miembro del grupo pueda usar kubectl para interactuar con un clúster de AKS concediendo el rol de Usuario de clúster de Azure Kubernetes Service.
```
az role assignment create \
  --assignee $APPDEV_ID \
  --role "Azure Kubernetes Service Cluster User Role" \
  --scope $AKS_ID
```

Sugerencia

Si recibe un error como Principal 35bfec9328bd4d8d9b54dea6dac57b82 doesn't exist in the directory a5443dcd-cd0e-494d-a387-3039b419f0d5., espere unos segundos para que el id. de objeto del grupo de Microsoft Entra se propague través del directorio. A continuación, pruebe el comando az role assignment create de nuevo.

Cree un segundo grupo de ejemplo para SRE, denominado opssre.

OPSSRE_ID=$(az ad group create --display-name opssre --mail-nickname opssre --query id -o tsv)

Cree una asignación de roles de Azure para conceder a los miembros del grupo el rol de Usuario de clúster de Azure Kubernetes Service.
```
az role assignment create \
  --assignee $OPSSRE_ID \
  --role "Azure Kubernetes Service Cluster User Role" \
  --scope $AKS_ID
```

Crear usuarios de demostración en Microsoft Entra ID

Ahora que tenemos dos grupos de ejemplo creados en Microsoft Entra ID para nuestros desarrolladores de aplicaciones y SRE, crearemos dos usuarios de ejemplo. Para probar la integración de RBAC de Kubernetes al final del artículo, iniciará sesión en el clúster de AKS con estas cuentas.

Establecimiento del nombre principal de usuario y la contraseña de los desarrolladores de aplicaciones

Establezca el nombre principal de usuario (UPN) y la contraseña de los desarrolladores de aplicaciones. El UPN debe incluir el nombre de dominio comprobado del inquilino, por ejemplo aksdev@contoso.com.

El siguiente comando le pide el UPN y lo establece en AAD_DEV_UPN para que se pueda usar en un comando posterior:

echo "Please enter the UPN for application developers: " && read AAD_DEV_UPN

El siguiente comando le pide la contraseña y la establece en AAD_DEV_PW para su uso en un comando posterior:

echo "Please enter the secure password for application developers: " && read AAD_DEV_PW

Creación de las cuentas de usuario

Crear la primera cuenta de usuario en Microsoft Entra ID mediante el comando az ad user create. En el ejemplo siguiente se crea un usuario con el nombre para mostrar AKS Dev y el UPN y la contraseña segura usando los valores de AAD_DEV_UPN y AAD_DEV_PW:

AKSDEV_ID=$(az ad user create \
  --display-name "AKS Dev" \
  --user-principal-name $AAD_DEV_UPN \
  --password $AAD_DEV_PW \
  --query id -o tsv)

Agregue el usuario al grupo appdev creado en la sección anterior mediante el comando az ad group member add.

az ad group member add --group appdev --member-id $AKSDEV_ID

Establezca el UPN y la contraseña de SRE. El UPN debe incluir el nombre de dominio comprobado del inquilino, por ejemplo akssre@contoso.com. El siguiente comando le pide el UPN y lo establece en AAD_SRE_UPN para su uso en un comando posterior:

echo "Please enter the UPN for SREs: " && read AAD_SRE_UPN

El siguiente comando le pide la contraseña y la establece en AAD_SRE_PW para su uso en un comando posterior:

echo "Please enter the secure password for SREs: " && read AAD_SRE_PW

Cree una nueva cuenta de usuario. El siguiente ejemplo crea un usuario con el nombre para mostrar AKS SRE y el UPN y la contraseña segura utilizando los valores de AAD_SRE_UPN y AAD_SRE_PW:

# Create a user for the SRE role
AKSSRE_ID=$(az ad user create \
  --display-name "AKS SRE" \
  --user-principal-name $AAD_SRE_UPN \
  --password $AAD_SRE_PW \
  --query id -o tsv)

# Add the user to the opssre Azure AD group
az ad group member add --group opssre --member-id $AKSSRE_ID

Creación de recursos de clúster de AKS para desarrolladores de aplicaciones

Hemos creado nuestros grupos, usuarios y asignaciones de roles de Microsoft Entra. Ahora vamos a configurar el clúster de AKS para permitir que estos grupos diferentes puedan obtener acceso a recursos específicos.

Obtenga las credenciales de administrador del clúster mediante el comando az aks get-credentials. En una de las siguientes secciones, obtendrá las credenciales del clúster del usuario normal para ver el flujo de autenticación de Microsoft Entra en acción.

az aks get-credentials --resource-group myResourceGroup --name myAKSCluster --admin

Cree un espacio de nombres en el clúster de AKS mediante el comando kubectl create namespace. En el siguiente ejemplo se crea un nuevo espacio de nombres, dev:

kubectl create namespace dev

Nota

En Kubernetes, los roles definen los permisos que conceder los enlaces de roles los aplican 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 Kubernetes.

Si el usuario al que concede el enlace de RBAC de Kubernetes se encuentra en el mismo inquilino de Microsoft Entra, asigne permisos según userPrincipalName (UPN). Si el usuario se encuentra en un inquilino distinto de Microsoft Entra, en su lugar, consulte y use la propiedad objectId.

Cree un rol para el espacio de nombres dev, que concede permisos completos al espacio de nombres. En entornos de producción, puede especificar permisos más granulares para diferentes usuarios o grupos. Cree un archivo denominado role-dev-namespace.yaml y 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: ["*"]

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

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 id -o tsv

Cree un enlace de rol a fin de que el grupo appdev use el rol creado anteriormente para el acceso de espacio de nombres. Cree un archivo denominado rolebinding-dev-namespace.yaml y pegue el siguiente manifiesto de YAML. En la última línea, reemplace groupObjectId por la salida del id. de objeto de grupo del comando anterior.

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 el enlace de roles mediante el comando kubectl apply y especifique el nombre de archivo del manifiesto de YAML:

kubectl apply -f rolebinding-dev-namespace.yaml

Creación de los recursos de clúster de AKS para SRE

Ahora, vamos a repetir los pasos anteriores a fin de crear un espacio de nombres, el rol y el enlace de rol para los SRE.

Cree un espacio de nombres para sre mediante el comando kubectl create namespace.

kubectl create namespace sre

Cree un archivo denominado role-sre-namespace.yaml y pegue el siguiente manifiesto de YAML:

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

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

kubectl apply -f role-sre-namespace.yaml

Obtenga el id. de recurso para el grupo opssre mediante el comando az ad group show.

az ad group show --group opssre --query id -o tsv

Cree un enlace de rol para que el grupo opssre use el rol creado anteriormente para el acceso de espacio de nombres. Cree un archivo denominado rolebinding-sre-namespace.yaml y pegue el siguiente manifiesto de YAML. En la última línea, reemplace groupObjectId por la salida del id. de objeto de grupo del comando anterior.

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

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

kubectl apply -f rolebinding-sre-namespace.yaml

Interactuación con recursos de clúster con identidades de Microsoft Entra

Ahora vamos a probar el trabajo de los permisos esperados cuando se crean y administran recursos en un clúster de AKS. En estos ejemplos, programaremos y veremos pods en el espacio de nombres asignado del usuario e intentaremos programar y ver pods fuera del espacio de nombres asignado.

Restablezca el contexto kubeconfig mediante el comando az aks get-credentials. En una sección anterior, establezca el contexto con las credenciales de administrador de clúster. El usuario administrador omite las solicitudes de inicio de sesión de Microsoft Entra. Sin el parámetro --admin, se aplica el contexto de usuario que requiere que todas las solicitudes se autentiquen mediante Microsoft Entra ID.

az aks get-credentials --resource-group myResourceGroup --name myAKSCluster --overwrite-existing

Programe un pod NGINX básico mediante 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 se le solicite iniciar sesión, escriba las credenciales de su cuenta appdev@contoso.com personal creada al principio del artículo. Una vez que se haya iniciado sesión correctamente, el token de la cuenta se copia en caché para futuros comandos kubectl. NGINX se programa correctamente, como se muestra en la siguiente salida de ejemplo:

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

To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code B24ZD6FP8 to authenticate.

pod/nginx-dev created

Use el comando kubectl get pods para ver los pods en el espacio de nombres dev.

kubectl get pods --namespace dev

Asegúrese de que el estado del pod NGINX es En ejecución. El resultado será similar a la salida siguiente:

$ kubectl get pods --namespace dev

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

Pruebe a ver los pods fuera del espacio de nombres dev. Use el comando kubectl get pods de nuevo, esta vez para ver --all-namespaces.

kubectl get pods --all-namespaces

La pertenencia a grupos del usuario no tiene un rol de Kubernetes que permita esta acción, tal como se muestra en la salida de ejemplo siguiente:

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

De la misma manera, intente programar un pod en un espacio de nombres diferente, como el espacio de nombres sre. La pertenencia a grupos del usuario no es compatible con un rol y un enlace de rol de Kubernetes para conceder estos permisos, tal como se muestra en la salida de ejemplo siguiente:

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

Error from server (Forbidden): pods is forbidden: User "aksdev@contoso.com" cannot create resource "pods" in API group "" in the namespace "sre"

Prueba del acceso de SRE a los recursos de clúster de AKS

Para confirmar que la pertenencia a grupos de Microsoft Entra y Kubernetes RBAC funcionan correctamente entre distintos usuarios y grupos, pruebe los comandos anteriores cuando inicie sesión como usuario opssre.

Restablezca el contexto kubeconfig mediante el comando az aks get-credentials que borra el token de autenticación previamente copiado en caché para el usuario aksdev.

az aks get-credentials --resource-group myResourceGroup --name myAKSCluster --overwrite-existing

Intente programar y ver los pods en el espacio de nombres sre asignado. Cuando se le solicite, inicie sesión con sus credenciales personales de opssre@contoso.com creadas al principio del artículo.

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

Como se muestra en la siguiente salida de ejemplo, puede crear y ver los pods correctamente:

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

3. To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code BM4RHP3FD to authenticate.

pod/nginx-sre created

$ kubectl get pods --namespace sre

NAME        READY   STATUS    RESTARTS   AGE
nginx-sre   1/1     Running   0

Pruebe ver o programar los pods fuera del espacio de nombres de SRE asignado.

kubectl get pods --all-namespaces
kubectl run nginx-sre --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace dev

No se pueden ejecutar estos comandos kubectl, como se muestra en la salida de ejemplo siguiente. La pertenencia a grupos del usuario y el rol y los enlaces de roles de Kubernetes no conceden permisos para crear o administrar recursos en otros espacios de nombres.

$ kubectl get pods --all-namespaces
Error from server (Forbidden): pods is forbidden: User "akssre@contoso.com" cannot list pods at the cluster scope

$ kubectl run nginx-sre --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace dev
Error from server (Forbidden): pods is forbidden: User "akssre@contoso.com" cannot create pods in the namespace "dev"

Limpieza de recursos

En este artículo, ha creado los recursos en el clúster de AKS y los usuarios y grupos en Microsoft Entra ID. Para borrar todos los recursos, ejecute los comandos siguientes:

# Get the admin kubeconfig context to delete the necessary cluster resources.

az aks get-credentials --resource-group myResourceGroup --name myAKSCluster --admin

# Delete the dev and sre namespaces. This also deletes the pods, Roles, and RoleBindings.

kubectl delete namespace dev
kubectl delete namespace sre

# Delete the Azure AD user accounts for aksdev and akssre.

az ad user delete --upn-or-object-id $AKSDEV_ID
az ad user delete --upn-or-object-id $AKSSRE_ID

# Delete the Azure AD groups for appdev and opssre. This also deletes the Azure role assignments.

az ad group delete --group appdev
az ad group delete --group opssre

Pasos siguientes

Para obtener más información sobre cómo proteger los clústeres de Kubernetes, consulte Opciones de acceso e identidad para AKS.
Para ver procedimientos recomendados sobre el control de recursos e identidades, consulte Procedimientos recomendados para la autenticación y autorización en AKS.