Controllare l'accesso con Microsoft Entra ID e Controllo degli accessi in base al ruolo di Kubernetes per Windows Server

Articolo
08/10/2024

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

Il servizio Azure Kubernetes (AKS) può essere configurato per usare 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 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 descrive come controllare l'accesso usando il controllo degli accessi in base al ruolo di Kubernetes in un cluster Kubernetes basato sull'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 ID, sono necessari i prerequisiti seguenti:

Un cluster Kubernetes creato in AKS Arc. Se è necessario configurare il cluster, vedere le istruzioni per l'uso di Windows Admin Center o PowerShell per distribuire il servizio Azure Kubernetes .
Connessione di Azure Arc. È necessario avere una connessione di Azure Arc al cluster Kubernetes. Per informazioni sull'abilitazione di Azure Arc, vedere Connettere un servizio Azure Kubernetes nel cluster locale di Azure a Kubernetes abilitato per Azure Arc.
È necessario accedere agli strumenti da riga di comando seguenti:
- Interfaccia della riga di comando di Azure e estensione connectedk8s. L'interfaccia della riga di comando di Azure è un set di comandi usati per creare e gestire le risorse di Azure. Per verificare se è disponibile l'interfaccia della riga di comando di Azure, aprire uno strumento da riga di comando e digitare : az -v. Installare anche l'estensione connectedk8s per aprire un canale per il cluster Kubernetes. Per istruzioni sull'installazione, vedere Come installare l'interfaccia della riga di comando di Azure.
- Kubectl. Questo strumento da riga di comando kubernetes consente di eseguire comandi destinati ai cluster Kubernetes. Per verificare se kubectl è stato installato, aprire un prompt dei comandi e digitare : kubectl version --client. Assicurarsi che la versione del client kubectl sia almeno la versione 1.24.0. Per istruzioni sull'installazione, vedere kubectl.
- PowerShell e il modulo di PowerShell AksHci. PowerShell è una soluzione di automazione delle attività multipiattaforma costituita da una shell della riga di comando, un linguaggio di scripting e un framework di gestione della configurazione. Se è stato installato Il servizio Azure Kubernetes Arc, è possibile accedere al modulo Azure Kubernetes PowerShell .
- Per accedere al cluster Kubernetes da qualsiasi posizione con una modalità proxy usando az connectedk8s proxy il comando , è necessaria l'autorizzazione Utente del cluster Kubernetes/connectedClusters/listClusterUserCredential/action, inclusa nell'autorizzazione utente del cluster Kubernetes abilitata per Azure Arc. Nel frattempo, è necessario verificare che gli agenti e il computer che eseguono il processo di onboarding soddisfino i requisiti di rete nei requisiti di rete kubernetes abilitati per Azure Arc.

Passaggi preliminari facoltativi

Se non si dispone già di un gruppo 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 Microsoft Entra per gli sviluppatori di applicazioni che possono essere usati per mostrare in che modo Kubernetes RBAC e Microsoft Entra ID controllano l'accesso alle risorse del cluster. Negli ambienti di produzione è possibile usare utenti e gruppi esistenti all'interno di un tenant di 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 az ad group create comando . L'esempio seguente chiede di accedere al tenant di Azure e quindi di creare 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. Questo account utente viene usato per accedere al cluster del servizio Azure Kubernetes e testare l'integrazione del controllo degli accessi in base al ruolo di Kubernetes.

Aggiungere un utente al gruppo appdev creato nella sezione precedente usando il az ad group member add comando . 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 ruolo del controllo degli accessi in base al ruolo di Kubernetes personalizzata nella risorsa cluster del servizio Azure Kubernetes per il gruppo Microsoft Entra

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

Ottenere le credenziali di amministratore del cluster usando il Get-AksHciCredential comando :
```
Get-AksHciCredential -name <name-of-your-cluster>
```
Creare uno spazio dei nomi nel cluster Kubernetes usando il kubectl create namespace comando . L'esempio seguente crea uno spazio dei nomi denominato dev:
```
kubectl create namespace dev
```
In Kubernetes i ruoli definiscono le autorizzazioni per concedere e RoleBindings applicano le autorizzazioni a utenti o 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 del 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 potrebbe essere necessario specificare autorizzazioni più granulari per utenti o gruppi diversi.

Creare un file denominato role-dev-namespace.yaml e copiare/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: ["*"]

Creare il ruolo usando il kubectl apply comando e specificare il nome file del manifesto YAML:
```
kubectl apply -f role-dev-namespace.yaml
```
Ottenere l'ID risorsa per il gruppo appdev usando il comando az ad group show. Questo gruppo viene impostato come oggetto di roleBinding nel passaggio successivo:
```
az ad group show --group appdev --query objectId -o tsv
```
Il az ad group show comando restituisce il valore usato come groupObjectId:
```
38E5FA30-XXXX-4895-9A00-050712E3673A
```
Creare un file denominato rolebinding-dev-namespace.yaml e copiare/incollare il manifesto YAML seguente. Si stabilisce l'associazione di ruoli che consente al gruppo appdev di usare il ruolo per l'accesso role-dev-namespace allo spazio dei nomi. Nell'ultima riga sostituire groupObjectId con l'ID oggetto gruppo prodotto dal az ad group show 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.

Creare RoleBinding usando il kubectl apply comando 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 predefiniti del controllo degli accessi in base al ruolo di Kubernetes per la risorsa del cluster del servizio Azure Kubernetes

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

Ruoli con privilegi avanzati (cluster-admin)
Ruoli destinati a essere concessi a livello di cluster tramite ClusterRoleBindings
Ruoli destinati a essere concessi all'interno di spazi dei nomi specifici usando RoleBindings (admin, edit, view)

Per altre informazioni sui ruoli predefiniti del controllo degli accessi in base al ruolo di Kubernetes, vedere Ruoli con controllo degli accessi in base al ruolo di Kubernetes.

Ruoli rivolti all'utente

ClusterRole predefinito	ClusterRoleBinding predefinito	Descrizione
cluster-admin	system:masters group	Consente l'accesso con privilegi avanzati agli utenti, 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. Se 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.
amministratore	None	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 possibilità di creare ruoli e associazioni di ruolo 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 con Kubernetes v1.22+. Per altre informazioni, vedere Accesso in scrittura per gli endpoint.
Modifica…	None	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 ruoli. Tuttavia, questo ruolo consente l'accesso ai segreti e l'esecuzione di 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 con Kubernetes v1.22+. Per altre informazioni, vedere Accesso in scrittura per gli endpoint.
view	None	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 ruolo. 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 api come qualsiasi ServiceAccount nello spazio dei nomi (una forma di escalation dei privilegi).

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

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

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

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

Applicare il ruolo predefinito view di Controllo degli accessi in base al ruolo di Kubernetes a ognuno degli utenti di Microsoft Entra:
```
kubectl create clusterrolebinding <name of your cluster role binding> --clusterrole=view --user=<Azure AD user object ID>
```

Usare le risorse del cluster con GLI ID Entra di Microsoft

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

Accedere ad Azure usando l'account $AKSDEV_ID utente specificato come input per il 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>
```
Dopo aver stabilito il canale proxy, aprire un'altra sessione e pianificare un pod NGINX usando il kubectl run comando nello spazio dei nomi di sviluppo :
```
kubectl run nginx-dev --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace dev
```
Quando NGINX è pianificato correttamente, verrà visualizzato l'output seguente:
```
pod/nginx-dev created
```
Usare ora il kubectl get pods comando per visualizzare i pod nello spazio dei dev nomi :
```
kubectl get pods --namespace dev
```
Quando NGINX è in esecuzione correttamente, verrà visualizzato l'output seguente:
```
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 kubectl get pods comando 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 genera un errore:

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

Passaggi successivi

Altre informazioni sulla sicurezza in AKS Arc in Windows Server

Condividi tramite