Uso de Privileged Identity Management (PIM) para controlar el acceso a los clústeres de Azure Kubernetes Service (AKS)

Artículo
10/15/2024

Al configurar permisos para distintos equipos, puede que quiera establecer permisos predeterminados para equipos específicos y, después, conceder acceso con privilegios a usuarios concretos cuando sea necesario. El uso de Azure Kubernetes Service (AKS) con Microsoft Entra ID permite configurar Privileged Identity Management (PIM) para las solicitudes Just-In-Time (JIT).

En este artículo aprenderá a:

Establezca roles predeterminados para que los grupos de ejemplo accedan a los clústeres de AKS o realicen operaciones en ellos en función de la pertenencia a grupos de Microsoft Entra.
Configure roles básicos para acceder a los clústeres de AKS.
Active roles de forma automática para obtener acceso Just-In-Time a los clústeres de AKS.
Establezca aprobadores para aprobar o denegar las solicitudes de aprobación de acceso Just-In-Time.

Nota:

Microsoft Entra Privileged Identity Management (PIM) tiene capacidades de Microsoft Entra ID P2 o Gobierno de Microsoft Entra ID que requieren una SKU Premium P2. Para obtener más información, consulte Aspectos básicos de las licencias de Gobierno de Microsoft Entra ID y la guía de precios.

Requisitos previos

En este artículo se da por hecho que ya tiene un clúster de AKS con integración de Microsoft Entra ID. Si no lo tiene, consulte Creación de un clúster de AKS con integración de Microsoft Entra ID.

Crear grupos de demostración en Microsoft Entra ID

En esta sección, vamos a crear tres grupos en Microsoft Entra ID:

Predeterminado: este grupo tiene acceso de solo lectura (Azure Kubernetes Service RBAC Reader) a los recursos del clúster de AKS.
Administración: este grupo tiene acceso de administrador (Azure Kubernetes Service RBAC Admin) a los recursos del clúster de AKS.
Aprobador: este grupo tiene permisos para aprobar o denegar solicitudes de acceso Just-In-Time al clúster de AKS.

Puede usar solamente los grupos predeterminado y administración en lugar de crear un grupo aprobador independiente. Sin embargo, si incluye permisos de aprobación en el grupo de administración, el miembro que obtenga acceso Just-In-Time puede aprobar sus propias solicitudes y las solicitudes de otros usuarios. No se recomienda usar esta configuración en un entorno de producción, pero resulta útil para realizar pruebas.

Creación de un grupo predeterminado

Obtenga el id. de recurso del clúster de AKS mediante el comando az aks show.

AKS_ID=$(az aks show \
    --resource-group <resource-group-name> \
    --name <cluster-name> \
    --query id \
    --output tsv)

Obtenga el id. de grupo de recursos del clúster de AKS mediante el comando az group show.

RG_ID=$(az group show \
    --resource-group <resource-group-name> \
    --query id \
    --output tsv)

Cree el grupo predeterminado mediante el comando az ad group create.

DEFAULT_ID=$(az ad group create \
    --display-name default \
    --mail-nickname default \
    --query id \
    --output tsv)

Cree una asignación de roles de Azure para el grupo predeterminado con el comando az role assignment create.

Hay tres roles que puede asignar al grupo predeterminado en función de sus requisitos específicos:
- Azure Kubernetes Service RBAC Reader: se asigna en el ámbito del clúster de AKS y proporciona acceso básico de solo lectura a la mayoría de los recursos del clúster.
- Reader: se asigna en el ámbito del grupo de recursos y proporciona acceso de solo lectura a los recursos del grupo de recursos.
- Azure Kubernetes Service Cluster User Role: se asigna en el ámbito del clúster de AKS y proporciona acceso para obtener el contexto kubeconfig para el clúster de AKS.
```
# Assign the Azure Kubernetes Service RBAC Reader role to the default group
az role assignment create \
    --role "Azure Kubernetes Service RBAC Reader" \
    --assignee $DEFAULT_ID \
    --scope $AKS_ID

# Assign the Reader role to the default group
az role assignment create \
    --role "Reader" \
    --assignee $DEFAULT_ID \
    --scope $RG_ID

# Assign the Azure Kubernetes Service Cluster User Role to the default group
az role assignment create \
    --role "Azure Kubernetes Service Cluster User Role" \
    --assignee $DEFAULT_ID \
    --scope $AKS_ID
```

Creación de un grupo de administración

Cree el grupo administración mediante el comando az ad group create.

ADMIN_ID=$(az ad group create \
    --display-name admin \
    --mail-nickname admin \
    --query id \
    --output tsv)

Asigne el rol Azure Kubernetes Service RBAC Admin al grupo administración mediante el comando az role assignment create.

az role assignment create \
    --role "Azure Kubernetes Service RBAC Admin" \
    --assignee $ADMIN_ID \
    --scope $AKS_ID

Nota:

Si quiere permitir que los usuarios del grupo administracióncambien la configuración del grupo de nodos, como el escalado manual, debe crear una asignación de roles Contributor en el grupo de nodos de clúster mediante el siguiente comando:

az role assignment create \
   --role "Contributor" \
   --assignee $ADMIN_ID \
   --scope $AKS_ID/nodepools/<node-pool-name>

Tenga en cuenta que esto solo concede permiso para reducir o escalar horizontalmente el recurso de AKS. Si quiere permitir la reducción o el escalado horizontales desde el recurso del conjunto de escalado de máquinas virtuales, debe crear una asignación en el nivel de dicho conjunto.

Creación de un grupo de aprobadores

Cree el grupo aprobador mediante el comando az ad group create.

APPROVER_ID=$(az ad group create \
    --display-name approver \
    --mail-nickname approver \
    --query id \
    --output tsv)

Crear usuarios de demostración en Microsoft Entra ID

En esta sección, vamos a crear dos usuarios en Microsoft Entra ID: uno normal que solo tenga el rol predeterminado y otro con privilegios que pueda aprobar o denegar las solicitudes Just-In-Time del usuario normal.

Cree el usuario normal mediante el comando az ad user create.

DOMAIN=contoso.com
PASSWORD=Password1

NUSER_ID=$(az ad user create \
    --display-name n01 \
    --password ${PASSWORD} \
    --user-principal-name n01@${DOMAIN} \
    --query id \
    --output tsv)

Agregue el usuario normal al grupo predeterminado mediante el comando az ad group member add.
```
az ad group member add \
    --group $DEFAULT_ID \
    --member-id $NUSER_ID
```

Cree el usuario con privilegios mediante el comando az ad user create.

PUSER_ID=$(az ad user create \
    --display-name p01 \
    --password ${PASSWORD} \
    --user-principal-name p01@${DOMAIN} \
    --query id \
    --output tsv)

Agregue el usuario con privilegios al grupo de aprobadores mediante el comando az ad group member add.
```
az ad group member add \
    --group $APPROVER_ID \
    --member-id $PUSER_ID
```

Habilitar Privileged Identity Management (PIM) para el grupo de administradores

En la página principal de Azure Portal, seleccione Microsoft Entra ID.
En el menú de servicio, en Administrar, seleccione Grupos y, a continuación, seleccione el grupo administración.
En el menú de servicio, en Actividad, seleccione Privileged Identity Management y, a continuación, seleccione Habilitar PIM para este grupo.

Establecimiento de un aprobador para el grupo de administración

En la página principal de Azure Portal, busque y seleccione Privileged Identity Management.
En el menú de servicio, en Administrar, seleccione Grupos y, a continuación, seleccione el grupo administración.
En el menú de servicio, en Administrar, seleccione Asignaciones>Agregar asignaciones.
En la pestaña Pertenencia de la página Agregar asignaciones, seleccione Miembro como rol seleccionado, predeterminado como miembro seleccionado y, a continuación, seleccione Siguiente.
En la pestaña Configuración, seleccione Elegible como tipo de asignación y, a continuación, seleccione Asignar.
En el menú de servicio, en Administrar, seleccione Configuración>Miembro>Editar.
En la página Edición de la configuración de roles: Miembro, seleccione la casilla Se requiere aprobación para activar y agregue el grupo aprobador como aprobador seleccionado.

Nota:

Si no selecciona la casilla Se requiere aprobación para activar, los usuarios del grupo predeterminado pueden activar el rol de forma automática para obtener acceso Just-In-Time al clúster de AKS sin aprobación. El usuario del grupo aprobador debe ser miembro del grupo. Aunque establezca como propietario al usuario, este seguirá sin poder revisar las solicitudes Just-In-Time porque al propietario del grupo solo le corresponden derechos administrativos en este, no la asignación de roles. Puede establecer el usuario como miembro y propietario del mismo grupo sin conflictos.
Realice cualquier otro cambio necesario y, a continuación, seleccione Actualizar.

Para obtener más información sobre la configuración de PIM, consulte Configuración de PIM para grupos.

Interactuación con recursos de clúster mediante el rol predeterminado

Ahora, podemos intentar acceder al clúster de AKS mediante el usuario normal, que es miembro del grupo predeterminado.

Inicie sesión en Azure Portal como usuario normal mediante el comando az login.
```
az login --username n01@$DOMAIN --password ${PASSWORD}
```
Obtenga las credenciales de usuario para acceder al clúster usando el comando az aks get-credentials.
```
az aks get-credentials --resource-group <resource-group-name> --name <cluster-name>
```

Intente acceder a los pods del clúster mediante el comando kubectl get.

kubectl get pods --namespace kube-system

La salida debe ser similar a la del ejemplo siguiente, que muestra los pods en el espacio de nombres kube-system:

NAME                                   READY   STATUS    RESTARTS   AGE
azure-ip-masq-agent-2rdd9              1/1     Running   0          30h
azure-policy-767c9d9d9d-886rf          1/1     Running   0          31h
cloud-node-manager-92t6h               1/1     Running   0          30h
coredns-789789675-b2dhg                1/1     Running   0          31h
coredns-autoscaler-77bbc46446-pgt92    1/1     Running   0          31h
csi-azuredisk-node-lnzrf               3/3     Running   0          30h
csi-azurefile-node-lhbxr               3/3     Running   0          31h
konnectivity-agent-7645d94b-9wqct      1/1     Running   0          30h
kube-proxy-lkx4w                       1/1     Running   0          31h
metrics-server-5955767688-lpbjb        2/2     Running   0          30h

Intente acceder a los secretos del clúster mediante el comando kubectl get.
```
kubectl get secrets --namespace kube-system
```
La salida debe ser similar a la del ejemplo siguiente, que muestra un mensaje de error porque el usuario no tiene permiso para acceder a los secretos:
```
Error from server (Forbidden): secrets is forbidden: User "[email protected]" cannot list resource "secrets" in API group "" in the namespace "kube-system": User does not have access to the resource in Azure. Update role assignment to allow access.
```
El rol Azure Kubernetes Service RBAC Reader no tiene permiso para acceder a los secretos, por lo que se espera este error.

Solicitud de acceso Just-In-Time al clúster de AKS

En esta ocasión, podemos solicitar acceso Just-In-Time como Azure Kubernetes Service RBAC Admin temporal mediante los pasos descritos en Activación de la propiedad o la pertenencia a grupos en Privileged Identity Management. Para obtener información sobre cómo aprobar o denegar solicitudes como aprobador, consulte Aprobación de solicitudes de activación para miembros y propietarios de un grupo.

Interactuación con los recursos del clúster mediante el rol de administrador

Después de agregar el rol Azure Kubernetes Service RBAC Admin con carácter temporal, puede acceder a los recursos del clúster que requieran permisos de administrador.

Quite los tokens almacenados existentes mediante el comando kubelogin siguiente:
```
kubelogin remove-tokens
```
Nota:

Si se produce un error debido a la falta de permisos, inicie sesión para actualizar los permisos mediante el comando az login.
Intente acceder de nuevo a los secretos del clúster mediante el comando kubectl get secrets.
```
kubectl get secrets --namespace kube-system
```
La salida debe ser similar a la del ejemplo siguiente, que muestra los secretos en el espacio de nombres kube-system:
```
NAME                     TYPE                            DATA   AGE
bootstrap-token-sw3rck   bootstrap.kubernetes.io/token   4      35h
konnectivity-certs       Opaque                          3      35h
```
Ahora el usuario puede acceder a los secretos porque tiene el rol Azure Kubernetes Service RBAC Admin.

Consideraciones sobre la duración de los tokens

Debido al diseño de duración de los tokens, si concede roles a los usuarios que usan herramientas de la CLI, como kubectl o kubelogin, técnicamente la duración de la activación no puede ser inferior a 60 minutos. Incluso aunque la duración se establezca en menos de 60 minutos, la duración efectiva real permanece entre 60 y 75 minutos.

Cuando kubelogin intenta obtener tokens de la Plataforma de identidad de Microsoft, se devuelven access_token y refresh_token para su uso posterior. El elemento access_token realiza solicitudes a la API y se usa refresh_token para obtener un nuevo access_token cuando expira el actual. No se puede revocar access_token una vez generado, pero refresh_token sí se puede revocar. Si se revoca refresh_token, el usuario debe volver a autenticarse para obtener un nuevo refresh_token. Para revocar refresh_token de forma manual, puede usar Revoke-AzureADUserAllRefreshToken.

Pasos siguientes

Para más información, consulte los siguientes artículos.

Compartir a través de