Uso del control de acceso basado en roles de Azure para la autorización de Kubernetes
En este artículo se explica cómo usar el Azure RBAC para la autorización de Kubernetes, lo que permite la administración unificada y el control de acceso entre recursos de Azure, AKS y recursos de Kubernetes. Para obtener más información, consulte Autorización de Azure RBAC para Kubernetes.
Nota
Al usar la autenticación integrada entre Microsoft Entra ID y AKS, puede usar usuarios, grupos o entidades de servicio de Microsoft Entra como sujetos en el control de acceso basado en roles de Kubernetes (Kubernetes RBAC). Con esta característica, no es necesario administrar por separado las identidades de usuario y las credenciales de Kubernetes. Sin embargo, todavía debe configurar y administrar Azure RBAC y Kubernetes por separado.
- Es preciso que esté instalada y configurada la versión 2.24.0 de la CLI de Azure, o cualquier otra posterior. Ejecute
az --version
para encontrar la versión. Si necesita instalarla o actualizarla, vea Instalación de la CLI de Azure. - Necesita
kubectl
, con la versión 1.18.3 como mínimo. - Debe habilitar la integración administrada de Microsoft Entra en el clúster para poder agregar el Azure RBAC para la autorización de Kubernetes. Si necesita habilitar la integración administrada de Microsoft Entra, consulte Usar Microsoft Entra ID en AKS.
- Si tiene CRDs y está realizando definiciones de roles personalizadas, la única manera de abarcar CRDs hoy es usar
Microsoft.ContainerService/managedClusters/*/read
. Para el resto de objetos, puede usar los grupos de API específicos, comoMicrosoft.ContainerService/apps/deployments/read
. - Las nuevas asignaciones de roles pueden tardar hasta cinco minutos en propagarse y actualizarse mediante el servidor de autorización.
- La autorización de Azure RBAC para Kubernetes requiere que el inquilino de Microsoft Entra configurado para la autenticación sea el mismo que el inquilino de la suscripción que alberga su clúster AKS.
Creación de un nuevo clúster de AKS con la integración administrada de Microsoft Entra y Azure RBAC para la autorización de Kubernetes
Cree un grupo de recursos de Azure con el comando
az group create
.export RESOURCE_GROUP=<resource-group-name> export LOCATION=<azure-region> az group create --name $RESOURCE_GROUP --location $LOCATION
Cree el clúster de AKS con la integración administrada de Microsoft Entra y Azure RBAC para la autorización de Kubernetes con el comando
az aks create
.export CLUSTER_NAME=<cluster-name> az aks create \ --resource-group $RESOURCE_GROUP \ --name $CLUSTER_NAME \ --enable-aad \ --enable-azure-rbac \ --generate-ssh-keys
El resultado debería ser similar al ejemplo siguiente:
"AADProfile": { "adminGroupObjectIds": null, "clientAppId": null, "enableAzureRbac": true, "managed": true, "serverAppId": null, "serverAppSecret": null, "tenantId": "****-****-****-****-****" }
Habilite Azure RBAC para la autorización de Kubernetes en un clúster de AKS existente mediante el comando
az aks update
con la marca--enable-azure-rbac
.az aks update --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --enable-azure-rbac
Para quitar la autorización de Azure RBAC para Kubernetes desde un clúster de AKS existente, use el comando
az aks update
con la marca--disable-azure-rbac
.az aks update --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --disable-azure-rbac
AKS proporciona los siguientes roles integrados:
Rol | Descripción |
---|---|
Lector de Azure Kubernetes Service RBAC | 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 Secrets , ya que leer el contenido de 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 elevación de privilegios). |
Escritor de Azure Kubernetes Service RBAC | 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 Secrets 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. |
Administrador de Azure Kubernetes Service RBAC | Permite el acceso de administrador, diseñado para su concesión dentro de un espacio de nombres. Permite el acceso de lectura y escritura a la mayoría de los recursos de un espacio de nombres (o ámbito de clúster), 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úster de Azure Kubernetes Service RBAC | Permite el acceso de superusuario para realizar cualquier acción en cualquier recurso. Proporciona control total sobre todos los recursos del clúster y en todos los espacios de nombres. |
Obtenga el id. de recurso de AKS mediante el comando
az aks show
.AKS_ID=$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query id --output tsv)
Cree una asignación de roles con el comando
az role assignment create
.<AAD-ENTITY-ID>
puede ser un nombre de usuario o el id. de cliente de una entidad de servicio. En el siguiente ejemplo se crea una asignación de roles para el rol Administrador de RBAC de Azure Kubernetes Service .az role assignment create --role "Azure Kubernetes Service RBAC Admin" --assignee <AAD-ENTITY-ID> --scope $AKS_ID
Nota
Puede crear las asignaciones de roles del lector de RBAC de Azure Kubernetes Service y del escritor de Azure Kubernetes Service cuyo ámbito sea un espacio de nombres específico dentro del clúster mediante el comando
az role assignment create
y establecer el ámbito en el espacio de nombres deseado.az role assignment create --role "Azure Kubernetes Service RBAC Reader" --assignee <AAD-ENTITY-ID> --scope $AKS_ID/namespaces/<namespace-name>
El siguiente ejemplo de una definición de roles personalizados permite a un usuario leer solo las implementaciones y nada más. Para obtener la lista completa de posibles acciones, consulte Operaciones de Microsoft.ContainerService.
Para crear sus propias definiciones de roles personalizados, copie el siguiente archivo, reemplace
<YOUR SUBSCRIPTION ID>
por su propio id. de suscripción y guárdelo comodeploy-view.json
.{ "Name": "AKS Deployment Reader", "Description": "Lets you view all deployments in cluster/namespace.", "Actions": [], "NotActions": [], "DataActions": [ "Microsoft.ContainerService/managedClusters/apps/deployments/read" ], "NotDataActions": [], "assignableScopes": [ "/subscriptions/<YOUR SUBSCRIPTION ID>" ] }
Cree la definición de roles mediante el comando
az role definition create
y establezca el--role-definition
al archivodeploy-view.json
que creó en el paso anterior.az role definition create --role-definition @deploy-view.json
Asigne la definición de roles a un usuario u otra identidad mediante el comando
az role assignment create
.az role assignment create --role "AKS Deployment Reader" --assignee <AAD-ENTITY-ID> --scope $AKS_ID
Asegúrese de que tiene el rol integrado de usuario de clúster de Azure Kubernetes Service y, a continuación, obtenga la kubeconfig del clúster de AKS mediante el comando
az aks get-credentials
.az aks get-credentials --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME
Ahora puede usar
kubectl
para administrar el clúster. Por ejemplo, puede hacer una lista de los nodos de su clúster conkubectl get nodes
.kubectl get nodes
Ejemplo:
NAME STATUS ROLES AGE VERSION aks-nodepool1-93451573-vmss000000 Ready agent 3h6m v1.15.11 aks-nodepool1-93451573-vmss000001 Ready agent 3h6m v1.15.11 aks-nodepool1-93451573-vmss000002 Ready agent 3h6m v1.15.11
AKS creó el complemento kubelogin
para ayudar a desbloquear escenarios como inicios de sesión no interactivos, versiones kubectl
anteriores o aprovechar el inicio de sesión único en varios clústeres sin necesidad de iniciar sesión en un nuevo clúster.
Ejecute el siguiente comando para usar el complemento
kubelogin
:export KUBECONFIG=/path/to/kubeconfig kubelogin convert-kubeconfig
Ahora puede usar
kubectl
para administrar el clúster. Por ejemplo, puede hacer una lista de los nodos de su clúster conkubectl get nodes
.kubectl get nodes
Ejemplo:
NAME STATUS ROLES AGE VERSION aks-nodepool1-93451573-vmss000000 Ready agent 3h6m v1.15.11 aks-nodepool1-93451573-vmss000001 Ready agent 3h6m v1.15.11 aks-nodepool1-93451573-vmss000002 Ready agent 3h6m v1.15.11
Enumere las asignaciones de roles mediante el comando
az role assignment list
.az role assignment list --scope $AKS_ID --query [].id --output tsv
Elimine las asignaciones de roles mediante el comando
az role assignment delete
.az role assignment delete --ids <LIST OF ASSIGNMENT IDS>
Elimine la definición de rol personalizado mediante el comando
az role definition delete
.az role definition delete --name "AKS Deployment Reader"
Elimine el grupo de recursos y el clúster de AKS mediante el comando
az group delete
.az group delete --name $RESOURCE_GROUP --yes --no-wait
Para obtener más información sobre la autenticación de AKS, la autorización, Kubernetes RBAC y Azure RBAC, consulte:
Comentarios de Azure Kubernetes Service
Azure Kubernetes Service es un proyecto de código abierto. Seleccione un vínculo para proporcionar comentarios: