Usare il controllo degli accessi in base al ruolo di Kubernetes con Microsoft Entra ID nel servizio Azure Kubernetes

Il servizio Azure Kubernetes può essere configurato per l'uso di Microsoft Entra ID per l'autenticazione utente. In questa configurazione si accede a un cluster del servizio Azure Kubernetes usando un token di autenticazione di Microsoft Entra. Dopo l'autenticazione, è possibile usare il controllo degli accessi in base al ruolo di Kubernetes predefinito per gestire l'accesso agli spazi dei nomi e alle risorse del cluster in base all'identità o all'appartenenza a un gruppo dell'utente.

Questo articolo illustra come:

• Controllare l'accesso usando il controllo degli accessi in base al ruolo di Kubernetes in un cluster del servizio Azure Kubernetes in base all'appartenenza a un gruppo di Microsoft Entra.
• Creare gruppi di esempio e utenti in Microsoft Entra ID.
• Creare ruoli e associazioni di ruolo in un cluster del servizio Azure Kubernetes per concedere le autorizzazioni appropriate per creare e visualizzare le risorse.

Operazioni preliminari

• È disponibile un cluster del servizio Azure Kubernetes esistente con l'integrazione di Microsoft Entra abilitata. Se è necessario un cluster del servizio Azure Kubernetes con questa configurazione, vedere Integrare Microsoft Entra ID con il servizio Azure Kubernetes.
• Il controllo degli accessi in base al ruolo di Kubernetes è abilitato per impostazione predefinita durante la creazione del cluster del servizio Azure Kubernetes. Per aggiornare il cluster con l'integrazione di Microsoft Entra e il controllo degli accessi in base al ruolo di Kubernetes, Abilitare l'integrazione di Microsoft Entra nel cluster del servizio Azure Kubernetes esistente.
• Assicurarsi che sia installata e configurata l'interfaccia della riga di comando di Azure versione 2.0.61 o successiva. Eseguire az --version per trovare la versione. Se è necessario eseguire l'installazione o l'aggiornamento, vedere Installare l'interfaccia della riga di comando di Azure.
• Se si usa Terraform, installare Terraform versione 2.99.0 o successiva.

Usare il portale di Azure o l'interfaccia della riga di comando di Azure per verificare che l'integrazione di Microsoft Entra con il controllo degli accessi in base al ruolo di Kubernetes sia abilitata.

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

Creare gruppi demo in Microsoft Entra ID

In questo articolo verranno creati due ruoli utente per illustrare in che modo Il controllo degli accessi in base al ruolo di Kubernetes e Microsoft Entra ID controllano l'accesso alle risorse del cluster. Vengono usati i due ruoli di esempio seguenti:

• Sviluppatore di applicazioni
  • Un utente denominato aksdev che fa parte del gruppo appdev.
• Site Reliability Engineer
  • Un utente denominato akssre che fa parte del gruppo opssre.

Negli ambienti di produzione è possibile usare utenti e gruppi esistenti all'interno di un tenant di Microsoft Entra.

1. Ottenere prima di tutto l'ID risorsa del cluster del servizio Azure Kubernetes usando il comando az aks show. Assegnare quindi l'ID risorsa a una variabile denominata AKS_ID in modo che possa esservi fatto riferimento in altri comandi.

   AKS_ID=$(az aks show \
       --resource-group myResourceGroup \
       --name myAKSCluster \
       --query id -o tsv)
   

2. Creare il primo gruppo di esempio in Microsoft Entra ID per gli sviluppatori di applicazioni usando il comando az ad group create. L'esempio seguente crea un gruppo denominato appdev:

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

3. Creare un'assegnazione di ruolo di Azure per il gruppo appdev usando il comando az role assignment create. Questa assegnazione consente a qualsiasi membro del gruppo di usare kubectl per interagire con un cluster del servizio Azure Kubernetes concedendo il Ruolo utente del cluster del servizio Azure Kubernetes.

   az role assignment create \
     --assignee $APPDEV_ID \
     --role "Azure Kubernetes Service Cluster User Role" \
     --scope $AKS_ID
   

4. Creare un secondo gruppo di esempio denominato opssre per i Site Reliability Engineer.

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

5. Creare un'assegnazione di ruolo di Azure per concedere ai membri del gruppo il Ruolo utente del cluster del servizio Azure Kubernetes.

   az role assignment create \
     --assignee $OPSSRE_ID \
     --role "Azure Kubernetes Service Cluster User Role" \
     --scope $AKS_ID
   

Creare utenti demo in Microsoft Entra ID

Ora che sono stati creati due gruppi di esempio in Microsoft Entra ID per gli sviluppatori di applicazioni e i Site Reliability Engineer, verranno creati due utenti di esempio. Per testare l'integrazione del controllo degli accessi in base al ruolo di Kubernetes alla fine dell'articolo, si accederà al cluster del servizio Azure Kubernetes con questi account.

Impostare il nome dell'entità utente e la password per gli sviluppatori di applicazioni

Impostare il nome dell'entità utente (UPN) e la password per gli sviluppatori di applicazioni. L'UPN deve includere il nome di dominio verificato del tenant, ad esempio aksdev@contoso.com.

Il comando seguente richiede l'UPN e lo imposta su AAD_DEV_UPN in modo che possa essere usato in un comando successivo:

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

Il comando seguente richiede la password e la imposta su AAD_DEV_PW per l'uso in un comando successivo:

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

Creare gli account utente

1. Creare il primo account utente in Microsoft Entra ID usando il comando az ad user create. L'esempio seguente crea un utente con il nome visualizzato AKS Dev e l'UPN e la password sicura usando i valori in AAD_DEV_UPN e 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)

2. Aggiungere l'utente al gruppo appdev creato nella sezione precedente usando il comando az ad group member add.

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

3. Configurare l'UPN e la password per i Site Reliability Engineer. L'UPN deve includere il nome di dominio verificato del tenant, ad esempio akssre@contoso.com. Il comando seguente richiede l'UPN e lo imposta su AAD_SRE_UPN per l'uso in un comando successivo:

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

4. Il comando seguente richiede la password e la imposta su AAD_SRE_PW per l'uso in un comando successivo:

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

5. Creare un secondo account utente. L'esempio seguente crea un utente con il nome visualizzato AKS SRE e l'UPN e la password sicura usando i valori in AAD_SRE_UPN e 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

Creare risorse cluster del servizio Azure Kubernetes per sviluppatori di app

Sono stati creati i gruppi di Microsoft Entra, gli utenti e le assegnazioni di ruolo di Azure. A questo punto si configurerà il cluster del servizio Azure Kubernetes per consentire a questi diversi gruppi di accedere a risorse specifiche.

1. Ottenere le credenziali di amministratore del cluster usando il comando az aks get-credentials. In una delle sezioni seguenti si ottengono le normali credenziali user del cluster per visualizzare il flusso di autenticazione di Microsoft Entra in azione.

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

2. Creare uno spazio dei nomi nel cluster del servizio Azure Kubernetes usando il comando kubectl create namespace. L'esempio seguente crea uno spazio dei nomi denominato dev:

kubectl create namespace dev

3. Creare un ruolo per lo spazio dei nomi dev, che concede autorizzazioni complete per lo spazio dei nomi. Negli ambienti di produzione è possibile specificare autorizzazioni più granulari per utenti o gruppi diversi. Creare un file denominato role-dev-namespace.yaml e incollare il manifesto YAML seguente:

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. Creare il ruolo usando il comando kubectl apply e specificare il nome file del manifesto YAML.

kubectl apply -f role-dev-namespace.yaml

5. Ottenere l'ID risorsa per il gruppo appdev usando il comando az ad group show. Questo gruppo viene impostato come oggetto di un'associazione di ruoli nel passaggio successivo.

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

6. Creare un'associazione di ruoli per il gruppo appdev per usare il ruolo creato in precedenza per l'accesso allo spazio dei nomi. Creare un file denominato rolebinding-dev-namespace.yaml e incollare il manifesto YAML seguente. Nell'ultima riga sostituire groupObjectId con l'output dell'ID oggetto gruppo del comando precedente.

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

7. Creare l'associazione di ruoli usando il comando kubectl apply e specificare il nome file del manifesto YAML:

kubectl apply -f rolebinding-dev-namespace.yaml

Creare le risorse del cluster del servizio Azure Kubernetes per i Site Reliability Engineer

A questo punto verranno ripetuti i passaggi precedenti per creare uno spazio dei nomi, un ruolo e un'associazione di ruoli per i Site Reliability Engineer.

1. Creare uno spazio dei nomi per sre usando il comando kubectl create namespace.

kubectl create namespace sre

2. Creare un file denominato role-sre-namespace.yaml e incollare il manifesto YAML seguente:

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: ["*"]

3. Creare il ruolo usando il comando kubectl apply e specificare il nome file del manifesto YAML.

kubectl apply -f role-sre-namespace.yaml

4. Ottenere l'ID risorsa per il gruppo opssre usando il comando az ad group show.

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

4. Creare un'associazione di ruoli per il gruppo opssre per usare il ruolo creato in precedenza per l'accesso allo spazio dei nomi. Creare un file denominato rolebinding-sre-namespace.yaml e incollare il manifesto YAML seguente. Nell'ultima riga sostituire groupObjectId con l'output dell'ID oggetto gruppo del comando precedente.

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

5. Creare l'associazione di ruoli usando il comando kubectl apply e specificare il nome file del manifesto YAML.

kubectl apply -f rolebinding-sre-namespace.yaml

Interagire con le risorse del cluster usando le identità di Microsoft Entra

A questo punto si verificherà che le autorizzazioni previste funzionino quando si creano e si gestiscono le risorse in un cluster del servizio Azure Kubernetes. In questi esempi verranno pianificati e visualizzati i pod nello spazio dei nomi assegnato dell'utente e si proverà a pianificare e visualizzare i pod all'esterno dello spazio dei nomi assegnato.

1. Reimpostare il contesto kubeconfig usando il comando az aks get-credentials. In una sezione precedente il contesto è stato impostato usando le credenziali di amministratore del cluster. L'utente amministratore ignora le richieste di accesso di Microsoft Entra. Senza il parametro --admin, viene applicato il contesto utente che richiede l'autenticazione di tutte le richieste tramite Microsoft Entra ID.

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

2. Pianificare un pod NGINX di base usando il comando kubectl run nello spazio dei nomi dev.

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

3. Immettere le credenziali per il proprio account appdev@contoso.com creato all'inizio dell'articolo come richiesta di accesso. Dopo aver eseguito l'accesso, il token dell'account viene memorizzato nella cache per i comandi futuri kubectl. NGINX è pianificato correttamente, come illustrato nell'output di esempio seguente:

$ 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

4. Usare il comando kubectl get pods per visualizzare i pod nello spazio dei nomi dev.

kubectl get pods --namespace dev

5. Verificare che lo stato del pod NGINX sia Running. L'output sarà simile al seguente:

$ kubectl get pods --namespace dev

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

Creare e visualizzare le risorse del cluster all'esterno dello spazio dei nomi assegnato

Provare a visualizzare i pod all'esterno dello spazio dei nomi dev. Usare di nuovo il comando kubectl get pods, questa volta per visualizzare --all-namespaces.

kubectl get pods --all-namespaces

L'appartenenza a un gruppo dell'utente non ha un ruolo Kubernetes che consente questa azione, come illustrato nell'output di esempio seguente:

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

Allo stesso modo, provare a pianificare un pod in uno spazio dei nomi diverso, ad esempio lo spazio dei nomi sre. L'appartenenza a un gruppo dell'utente non è allineata a un ruolo e a un'associazione di ruoli di Kubernetes per concedere queste autorizzazioni, come illustrato nell'output di esempio seguente:

$ 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"

Testare l'accesso del Site Reliability Engineer alle risorse del cluster del servizio Azure Kubernetes

Per verificare che l'appartenenza a un gruppo di Microsoft Entra e il controllo degli accessi in base al ruolo di Kubernetes funzionino correttamente tra utenti e gruppi diversi, provare i comandi precedenti dopo avere eseguito l'accesso come utente opssre.

1. Reimpostare il contesto kubeconfig usando il comando az aks get-credentials che cancella il token di autenticazione memorizzato nella cache in precedenza per l'utente aksdev.

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

2. Provare a pianificare e visualizzare i pod nello spazio dei nomi sre assegnato. Quando richiesto, accedere con le proprie credenziali opssre@contoso.com create all'inizio dell'articolo.

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

Come illustrato nell'output di esempio seguente, è possibile creare e visualizzare correttamente i pod:

$ 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

4. Provare a visualizzare o pianificare i pod all'esterno dello spazio dei nomi SRE assegnato.

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

Questi comandi kubectl hanno esito negativo, come illustrato nell'output di esempio seguente. L'appartenenza a un gruppo dell'utente e il ruolo e le associazioni di ruoli di Kubernetes non concedono autorizzazioni per creare o gestire risorse in altri spazi dei nomi.

$ 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"

Pulire le risorse

In questo articolo sono state create risorse nel cluster del servizio Azure Kubernetes e utenti e gruppi in Microsoft Entra ID. Per pulire tutte le risorse, eseguire i comandi seguenti:

# 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

Passaggi successivi

• Per altre informazioni su come proteggere i cluster Kubernetes, vedere Opzioni di accesso e identità per il servizio Azure Kubernetes.

• Per le procedure consigliate per il controllo delle identità e delle risorse, vedere Procedure consigliate per l'autenticazione e l'autorizzazione nel servizio Azure Kubernetes.