Controllare l'accesso tramite Microsoft Entra ID e controllo degli accessi in base al ruolo kubernetes nel servizio Azure Kubernetes abilitato da Azure Arc
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 almenov1.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.
Create 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
Create un'associazione del ruolo RBAC kubernetes personalizzata nella risorsa del cluster del servizio Azure Kubernetes per il gruppo 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 Create gruppi demo in Microsoft Entra ID.
Ottenere le credenziali di amministratore del cluster usando il comando Get-AksHciCredential :
Get-AksHciCredential -name <name-of-your-cluster>
Create 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.
Create 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.
Create 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: ["*"]
Create il ruolo usando il comando kubectl apply e specificare il nome del 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 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 comegroupObjectId
:38E5FA30-XXXX-4895-9A00-050712E3673A
Create un file denominato rolebinding-dev-namespace.yaml e incollarlo nel 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 sostituiregroupObjectId
con l'IDaz 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 sostituiregroupObjectId
con il nome dell'entità utente (UPN) nell'esempio.Create roleBinding usando il comando kubectl apply e specificare il nome 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 RBAC predefinito di Kubernetes con Microsoft Entra ID, seguire questa procedura:
Applicare il ruolo RBAC predefinito
view
di Kubernetes al gruppo di Microsoft Entra:kubectl create clusterrolebinding <name of your cluster role binding> --clusterrole=view --group=<Azure AD group object ID>
Applicare il ruolo RBAC predefinito
view
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à di Microsoft Entra
Testare ora le autorizzazioni previste quando si creano e gestiscono le risorse in un cluster Kubernetes. In questi esempi si pianificano e visualizzano i pod nello spazio dei nomi assegnato dall'utente. Provare quindi a pianificare e visualizzare i pod all'esterno dello spazio dei nomi assegnato.
Accedere ad Azure usando l'account
$AKSDEV_ID
utente passato come input alaz ad group member add
comando. Eseguire ilaz connectedk8s proxy
comando per aprire un canale nel 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 comando kubectl run 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 è stato pianificato correttamente, viene visualizzato l'output seguente:
pod/nginx-dev created
Usare ora il comando kubectl get pods per visualizzare i pod nello
dev
spazio dei nomi:kubectl get pods --namespace dev
Quando NGINX è stato eseguito correttamente, viene visualizzato l'output seguente:
$ kubectl get pods --namespace dev NAME READY STATUS RESTARTS AGE nginx-dev 1/1 Running 0 4m
Create 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
Commenti e suggerimenti
https://aka.ms/ContentUserFeedback.
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedereInvia e visualizza il feedback per