Controllare l'accesso tramite Microsoft Entra ID e controllo degli accessi in base al ruolo kubernetes nel servizio Azure Kubernetes abilitato da Azure Arc

  • Articolo

Si applica a: Servizio Azure Kubernetes in Azure Stack HCI 22H2, servizio Azure Kubernetes in Windows Server

servizio Azure Kubernetes (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 Kubernetes usando un token di autenticazione Microsoft Entra. Dopo l'autenticazione, è possibile usare il controllo degli accessi in base al ruolo (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 descrive come controllare l'accesso tramite il controllo degli accessi in base al ruolo di Kubernetes in un cluster Kubernetes in base all'appartenenza al gruppo Microsoft Entra in AKS Arc. Si crea un gruppo demo e gli utenti in Microsoft Entra ID. Creare quindi ruoli e associazioni di ruolo nel cluster per concedere le autorizzazioni appropriate per creare e visualizzare le risorse.

Prerequisiti

Prima di configurare il controllo degli accessi in base al ruolo di Kubernetes usando Microsoft Entra identity, è necessario:

  • Un cluster Kubernetes creato in AKS Arc

    È necessario un cluster Kubernetes creato in AKS Arc. Se è necessario configurare il cluster, è possibile trovare istruzioni per l'uso di Windows Admin Center o PowerShell per distribuire il servizio Azure Kubernetes.

  • Connessione di Azure Arc

    È necessario avere una connessione azure Arc al cluster Kubernetes. Per informazioni sull'abilitazione di Azure Arc, vedere Connettere un servizio Azure Kubernetes nel cluster Azure Stack HCI a Kubernetes abilitato per Azure Arc.

  • È necessario accedere agli strumenti della riga di comando seguenti:

    • Interfaccia della riga di comando di Azure e l'estensione connectedk8s

      L'interfaccia della riga di comando di Azure è un set di comandi che consente di creare e gestire le risorse di Azure. Per verificare se è disponibile l'interfaccia della riga di comando di Azure, aprire uno strumento della riga di comando e digitare: az -v. Sarà inoltre necessario installare l'estensione connectedk8s per aprire un canale al cluster Kubernetes.

      Per istruzioni sull'installazione, vedere Come installare l'interfaccia della riga di comando di Azure.

    • Kubectl

      Lo strumento da riga di comando Kubernetes, kubectl, consente di eseguire comandi destinati ai cluster Kubernetes. Per verificare se è stato installato kubectl, aprire uno strumento della riga di comando e digitare: kubectl version --client. Assicurarsi che la versione del client kubectl sia almeno v1.24.0.

      Per istruzioni di installazione, vedere kubectl.

    • PowerShell e il modulo AksHci PowerShell

      PowerShell è una soluzione di automazione attività multipiattaforma costituita da una shell della riga di comando, un linguaggio di scripting e un framework di gestione della configurazione. Se è stato installato AKS Arc, è possibile accedere al modulo AksHci PowerShell.

Primi passaggi facoltativi

Se non si dispone già di un gruppo di Microsoft Entra che contiene membri, è possibile creare un gruppo e aggiungere alcuni membri, in modo da poter seguire le istruzioni riportate in questo articolo.

Per illustrare l'uso di Microsoft Entra ID e controllo degli accessi in base al ruolo di Kubernetes, è possibile creare un gruppo di Microsoft Entra per gli sviluppatori di applicazioni che possono essere usati per mostrare come il controllo degli accessi in base al ruolo di Kubernetes e Microsoft Entra ID controllare l'accesso alle risorse del cluster. Negli ambienti di produzione è possibile usare utenti e gruppi esistenti all'interno di un tenant Microsoft Entra.

Creare un gruppo demo in Microsoft Entra ID

Creare prima di tutto il gruppo in Microsoft Entra ID nel tenant per gli sviluppatori di applicazioni usando il comando az ad group create. L'esempio seguente include l'accesso al tenant di Azure e quindi crea un gruppo denominato appdev:

az login
az ad group create --display-name appdev --mail-nickname appdev

Aggiungere utenti al gruppo

Con il gruppo di esempio creato in Microsoft Entra ID per gli sviluppatori di applicazioni, aggiungere un utente al appdev gruppo. Si userà questo account utente per accedere al cluster del servizio Azure Kubernetes e testare l'integrazione degli accessi in base al ruolo di Kubernetes.

Aggiungere un utente al gruppo appdev creato nella sezione precedente usando il comando az ad group member add . Se si chiude la sessione, riconnettersi ad Azure usando az login.

$AKSDEV_ID = az ad user create --display-name <name> --password <strongpassword> --user-principal-name <name>@contoso.onmicrosoft.com
az ad group member add --group appdev --member-id $AKSDEV_ID

Creare un'associazione di ruoli RBAC Kubernetes personalizzata nella risorsa del cluster del servizio Azure Kubernetes per il gruppo di Microsoft Entra

Configurare il cluster del servizio Azure Kubernetes per consentire al gruppo di Microsoft Entra di accedere al cluster. Per aggiungere un gruppo e gli utenti, vedere Creare gruppi demo in Microsoft Entra ID.

  1. Ottenere le credenziali di amministratore del cluster usando il comando Get-AksHciCredential :

    Get-AksHciCredential -name <name-of-your-cluster>

  2. Creare uno spazio dei nomi nel cluster Kubernetes usando il comando kubectl create namespace . Nell'esempio seguente viene creato uno spazio dei nomi denominato dev:

    kubectl create namespace dev

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

    Creare un ruolo per lo spazio dei nomi di sviluppo . Questo ruolo concede autorizzazioni complete allo spazio dei nomi. Negli ambienti di produzione è possibile specificare autorizzazioni più granulari per utenti o gruppi diversi.

  3. 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 del 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 RoleBinding nel passaggio successivo:

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

    Il az ad group show comando restituisce il valore che verrà usato come groupObjectId:

    38E5FA30-XXXX-4895-9A00-050712E3673A

  6. Creare un file denominato rolebinding-dev-namespace.yaml e incollare il manifesto YAML seguente. Si sta definendo l'associazione di ruoli che consente al gruppo appdev di usare il role-dev-namespace ruolo per l'accesso allo spazio dei nomi. Nell'ultima riga sostituire groupObjectId con l'ID az ad group show oggetto gruppo prodotto dal comando.

    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 si vuole creare RoleBinding per un singolo utente, specificare kind: User e sostituire groupObjectId con il nome dell'entità utente (UPN) nell'esempio.

  7. Creare RoleBinding usando il comando kubectl apply e specificare il nome del file del manifesto YAML:

    kubectl apply -f rolebinding-dev-namespace.yaml

    rolebinding.rbac.authorization.k8s.io/dev-user-access created

Usare i ruoli RBAC predefiniti di Kubernetes per la risorsa del cluster del servizio Azure Kubernetes

Kubernetes offre anche ruoli predefiniti per gli utenti. Questi ruoli predefiniti includono:

  • Ruoli utente avanzati (cluster-admin)
  • Ruoli destinati a essere concessi a livello di cluster usando ClusterRoleBindings
  • Ruoli destinati a essere concessi all'interno di spazi dei nomi specifici usando RoleBindings (amministratore, modifica, visualizzazione)

Per altre informazioni sui ruoli RBAC predefiniti di Kubernetes, vedere Ruoli di controllo degli accessi in base al ruolo degli utenti kubernetes

Ruoli destinati all'utente

ClusterRole predefinito ClusterRoleBinding predefinito Descrizione
cluster-admin system:master group Consente l'accesso superutente, per eseguire qualsiasi azione su qualsiasi risorsa. Se usato in un clusterRoleBinding, questo ruolo fornisce il controllo completo su ogni risorsa nel cluster e in tutti gli spazi dei nomi. Quando viene usato in un RoleBinding, fornisce il controllo completo su ogni risorsa nello spazio dei nomi dell'associazione di ruoli, incluso lo spazio dei nomi stesso.
admin Nessuno Consente l'accesso amministratore, destinato a essere concesso all'interno di uno spazio dei nomi usando un'associazione di ruoli. Se usato in un'associazione di ruoli, consente l'accesso in lettura/scrittura alla maggior parte delle risorse in uno spazio dei nomi, inclusa la funzionalità di creare ruoli e associazioni di ruoli all'interno dello spazio dei nomi. Questo ruolo non consente l'accesso in scrittura alla quota di risorse o allo spazio dei nomi stesso. Questo ruolo non consente anche l'accesso in scrittura agli endpoint nei cluster creati usando Kubernetes v1.22+. Per altre informazioni, vedere Accesso in scrittura per endpoint.
modifica Nessuno Consente l'accesso in lettura/scrittura alla maggior parte degli oggetti in uno spazio dei nomi. Questo ruolo non consente la visualizzazione o la modifica di ruoli o associazioni di ruolo. Tuttavia, questo ruolo consente di accedere ai segreti ed eseguire pod come qualsiasi ServiceAccount nello spazio dei nomi, in modo che possa essere usato per ottenere i livelli di accesso api di qualsiasi ServiceAccount nello spazio dei nomi. Questo ruolo non consente anche l'accesso in scrittura agli endpoint nei cluster creati usando Kubernetes v1.22+. Per altre informazioni, vedere Accesso in scrittura per endpoint.
vista Nessuno Consente l'accesso in sola lettura per visualizzare la maggior parte degli oggetti in uno spazio dei nomi. Non consente la visualizzazione di ruoli o associazioni di ruoli. Questo ruolo non consente la visualizzazione dei segreti, poiché la lettura del contenuto dei segreti consente l'accesso alle credenziali serviceAccount nello spazio dei nomi, che consente l'accesso alle API come qualsiasi ServiceAccount nello spazio dei nomi (una forma di escalation dei privilegi).

Usare un ruolo di controllo degli accessi in base al ruolo Kubernetes predefinito con Microsoft Entra ID

Per usare un ruolo predefinito del controllo degli accessi in base al ruolo di Kubernetes con Microsoft Entra ID, seguire questa procedura:

  1. Applicare il ruolo di controllo degli accessi in base al ruolo Kubernetes predefinito view al gruppo di Microsoft Entra:

    kubectl create clusterrolebinding <name of your cluster role binding> --clusterrole=view --group=<Azure AD group object ID>

  2. Applicare il ruolo di controllo degli accessi in view base al ruolo predefinito di Kubernetes a ognuno degli utenti Microsoft Entra:

    kubectl create clusterrolebinding <name of your cluster role binding> --clusterrole=view --user=<Azure AD user object ID>

Usare le risorse del cluster usando identità Microsoft Entra

Testare ora le autorizzazioni previste quando si creano e gestiscono le risorse in un cluster Kubernetes. In questi esempi vengono pianificati e visualizzati i pod nello spazio dei nomi assegnato dall'utente. Si tenta quindi di pianificare e visualizzare i pod all'esterno dello spazio dei nomi assegnato.

  1. Accedere ad Azure usando l'account $AKSDEV_ID utente passato come input al az ad group member add comando. Eseguire il az connectedk8s proxy comando per aprire un canale al cluster:

    az connectedk8s proxy -n <cluster-name> -g <resource-group>

  2. Dopo aver stabilito il canale proxy, aprire un'altra sessione e pianificare un pod NGINX 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

    Quando NGINX è stato pianificato correttamente, viene visualizzato l'output seguente:

    pod/nginx-dev created

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

    kubectl get pods --namespace dev

    Quando NGINX è in esecuzione correttamente, viene visualizzato l'output 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

Per tentare di visualizzare i pod all'esterno dello spazio dei nomi di sviluppo , usare il comando kubectl get pods con il --all-namespaces flag .

kubectl get pods --all-namespaces

L'appartenenza al gruppo dell'utente non ha un ruolo Kubernetes che consente questa azione. Senza l'autorizzazione, il comando genererà un errore.

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

Passaggi successivi