Condividi tramite


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 un cluster esistente 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 AKS esistente.
  • Assicurarsi che sia installata e configurata l'interfaccia della riga di comando di Azure versione 2.0.61 o successiva. Per trovare la versione, eseguire az --version. Per installare o eseguire 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.

Per la verifica tramite il portale di Azure

  1. Accedere al portale di Azure e passare alla risorsa cluster del servizio Azure Kubernetes.
  2. Nel menu del servizio, in Impostazioni, selezionare Configurazione di sicurezza.
  3. Nella sezione Autenticazione e autorizzazione verificare che sia selezionata l'opzione Autenticazione di Microsoft Entra con controllo degli accessi in base al ruolo di Kubernetes.

Creare gruppi demo in Microsoft Entra ID

In questo articolo, crei due ruoli utente per mostrare come il controllo degli accessi in base al ruolo di Kubernetes RBAC 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
    

    Suggerimento

    Se viene visualizzato un errore, ad esempio Principal 35bfec9328bd4d8d9b54dea6dac57b82 doesn't exist in the directory a5443dcd-cd0e-494d-a387-3039b419f0d5., attendere qualche secondo prima che l'ID oggetto del gruppo di Microsoft Entra venga propagato nella directory, quindi provare di nuovo a eseguire il comando az role assignment create.

  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 gli SRE, è possibile creare due utenti di esempio. Per testare l'integrazione RBAC di Kubernetes alla fine dell'articolo, accedi al cluster AKS 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 [email protected]. Per individuare (o impostare) i nomi di dominio verificati nel tenant, vedere Gestione dei nomi di dominio personalizzati nell'ID Microsoft Entra.

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 [email protected]. 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 Entra ID 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. Configurare ora 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
    

    Nota

    In Kubernetes i Ruoli definiscono le autorizzazioni da concedere e le associazioni di ruoli le applicano a utenti o gruppi desiderati. Queste assegnazioni possono essere applicate a uno spazio dei nomi specifico o all'intero cluster. Per altre informazioni, vedere Uso dell'autorizzazione del controllo degli accessi in base al ruolo di Kubernetes.

    Se l'utente a cui si concede l'associazione del controllo degli accessi in base al ruolo di Kubernetes si trova nello stesso tenant di Microsoft Entra, assegnare le autorizzazioni in base a userPrincipalName (UPN). Se l'utente si trova in un tenant di Microsoft Entra diverso, cercare tramite query e usare la proprietà objectId.

  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
    

    Suggerimento

    Se vuoi creare il RoleBinding per un singolo utente, specificare il tipo: Utente e sostituire groupObjectId con il nome dell'entità utente (UPN) nello schema precedente.

  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

Ora, ripetere i passaggi precedenti per creare uno spazio dei nomi, un ruolo e un RoleBinding per gli SRE.

  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
    
  5. 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
    
  6. 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

Verificare ora che le autorizzazioni previste funzionino quando si creano e gestiscono le risorse in un cluster del servizio Azure Kubernetes. In questi esempi si pianificano e si visualizzano i pod nello spazio dei nomi assegnato dell'utente e si tenta di 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 [email protected] 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 è 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 "[email protected]" 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 "[email protected]" 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 al gruppo Microsoft Entra e i ruoli di Kubernetes funzionino correttamente tra utenti e gruppi diversi, provare i comandi precedenti quando si è connessi 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 [email protected] 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. Per accedere, usare un Web browser per aprire la pagina https://microsoft.com/devicelogin e immettere il codice BM4RHP3FD per l'autenticazione.

    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 "[email protected]" 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 "[email protected]" 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