Usare Privileged Identity Management (PIM) per controllare l'accesso ai cluster servizio Azure Kubernetes (AKS)

Articolo
09/04/2024

Quando si configurano le autorizzazioni per team diversi, è possibile impostare le autorizzazioni predefinite per i team specificati, quindi concedere l'accesso con privilegi a utenti specifici quando necessario. L'uso di servizio Azure Kubernetes (AKS) con Microsoft Entra ID consente di configurare Privileged Identity Management (PIM) per le richieste JIT (Just-In-Time).

In questo articolo vengono illustrate le operazioni seguenti:

Impostare i ruoli predefiniti per i gruppi di esempio per accedere o eseguire operazioni sui cluster del servizio Azure Kubernetes in base alle appartenenze ai gruppi di Microsoft Entra.
Configurare i ruoli di base per l'accesso ai cluster del servizio Azure Kubernetes.
Attivare automaticamente i ruoli per ottenere l'accesso JIT ai cluster del servizio Azure Kubernetes.
Impostare responsabili approvazione per approvare o negare le richieste di approvazione per l'accesso JUST-In-Time.

Nota

Microsoft Entra Privileged Identity Management (PIM) dispone di funzionalità microsoft Entra ID P2 o Microsoft Entra ID Governance che richiedono uno SKU Premium P2. Per altre informazioni, vedere Microsoft Entra ID Governance licensing fundamentals and pricing guide (Nozioni fondamentali sulle licenze e prezzi di Microsoft Entra ID Governance).

Prerequisiti

Questo articolo presuppone che si disponga di un cluster del servizio Azure Kubernetes esistente con l'integrazione di Microsoft Entra ID. Se non è disponibile, vedere Creare un cluster del servizio Azure Kubernetes con l'integrazione di Microsoft Entra ID.

Creare gruppi demo in Microsoft Entra ID

In questa sezione vengono creati tre gruppi in Microsoft Entra ID:

Impostazione predefinita: questo gruppo ha accesso in sola lettura (Azure Kubernetes Service RBAC Reader) alle risorse nel cluster del servizio Azure Kubernetes.
Amministratore: questo gruppo ha accesso amministratore (Azure Kubernetes Service RBAC Admin) alle risorse nel cluster del servizio Azure Kubernetes.
Responsabile approvazione: questo gruppo dispone delle autorizzazioni per approvare o negare le richieste di accesso JIT al cluster del servizio Azure Kubernetes.

È possibile usare solo i gruppi predefiniti e di amministrazione anziché creare un gruppo di responsabili approvazione separato. Tuttavia, se si includono le autorizzazioni di approvazione nel gruppo di amministrazione , il membro che ottiene l'accesso JITE può approvare le proprie richieste e le richieste di altri utenti. Non è consigliabile usare questa configurazione in un ambiente di produzione, ma è utile a scopo di test.

Creare un gruppo predefinito

Ottenere l'ID risorsa del cluster del servizio Azure Kubernetes usando il az aks show comando .

AKS_ID=$(az aks show \
    --resource-group <resource-group-name> \
    --name <cluster-name> \
    --query id \
    --output tsv)

Ottenere l'ID del gruppo di risorse del cluster del servizio Azure Kubernetes usando il az group show comando .
```
RG_ID=$(az group show \
    --resource-group <resource-group-name> \
    --query id \
    --output tsv)
```

Creare il gruppo predefinito usando il az ad group create comando .

DEFAULT_ID=$(az ad group create \
    --display-name default \
    --mail-nickname default \
    --query id \
    --output tsv)

Creare un'assegnazione di ruolo di Azure per il gruppo predefinito usando il az role assignment create comando .

Esistono tre ruoli che è possibile assegnare al gruppo predefinito a seconda dei requisiti specifici:
- Azure Kubernetes Service RBAC Reader: assegnato all'ambito del cluster del servizio Azure Kubernetes e fornisce l'accesso di sola lettura di base alla maggior parte delle risorse nel cluster.
- Reader: assegnato nell'ambito del gruppo di risorse e consente l'accesso in sola lettura alle risorse nel gruppo di risorse.
- Azure Kubernetes Service Cluster User Role: assegnato all'ambito del cluster del servizio Azure Kubernetes e fornisce l'accesso per ottenere il contesto kubeconfig per il cluster del servizio Azure Kubernetes.
```
# Assign the Azure Kubernetes Service RBAC Reader role to the default group
az role assignment create \
    --role "Azure Kubernetes Service RBAC Reader" \
    --assignee $DEFAULT_ID \
    --scope $AKS_ID

# Assign the Reader role to the default group
az role assignment create \
    --role "Reader" \
    --assignee $DEFAULT_ID \
    --scope $RG_ID

# Assign the Azure Kubernetes Service Cluster User Role to the default group
az role assignment create \
    --role "Azure Kubernetes Service Cluster User Role" \
    --assignee $DEFAULT_ID \
    --scope $AKS_ID
```

Creare un gruppo di amministratori

Creare il gruppo di amministratori usando il az ad group create comando .

ADMIN_ID=$(az ad group create \
    --display-name admin \
    --mail-nickname admin \
    --query id \
    --output tsv)

Assegnare il Azure Kubernetes Service RBAC Admin ruolo al gruppo di amministrazione usando il az role assignment create comando .

az role assignment create \
    --role "Azure Kubernetes Service RBAC Admin" \
    --assignee $ADMIN_ID \
    --scope $AKS_ID

Nota

Se si vuole consentire agli utenti nel gruppo amministratore di modificare le impostazioni del pool di nodi, ad esempio il ridimensionamento manuale, è necessario creare un'assegnazione Contributor di ruolo nel pool di nodi del cluster usando il comando seguente:

az role assignment create \
   --role "Contributor" \
   --assignee $ADMIN_ID \
   --scope $AKS_ID/nodepools/<node-pool-name>

Tenere presente che questo concede solo l'autorizzazione per aumentare o ridurre le istanze dalla risorsa del servizio Azure Kubernetes. Se si vuole consentire il ridimensionamento dalla risorsa del set di scalabilità di macchine virtuali, è necessario creare un'assegnazione a livello di set di scalabilità di macchine virtuali.

Creare un gruppo di responsabili approvazione

Creare il gruppo di responsabili approvazione usando il az ad group create comando .

APPROVER_ID=$(az ad group create \
    --display-name approver \
    --mail-nickname approver \
    --query id \
    --output tsv)

Creare utenti demo in Microsoft Entra ID

In questa sezione vengono creati due utenti in Microsoft Entra ID: un utente normale con solo il ruolo predefinito e un utente con privilegi che può approvare o negare richieste JIT all'utente normale .

Creare l'utente normale usando il az ad user create comando .

DOMAIN=contoso.com
PASSWORD=Password1

NUSER_ID=$(az ad user create \
    --display-name n01 \
    --password ${PASSWORD} \
    --user-principal-name n01@${DOMAIN} \
    --query id \
    --output tsv)

Aggiungere l'utente normale al gruppo predefinito usando il az ad group member add comando .
```
az ad group member add \
    --group $DEFAULT_ID \
    --member-id $NUSER_ID
```

Creare l'utente con privilegi usando il az ad user create comando .

PUSER_ID=$(az ad user create \
    --display-name p01 \
    --password ${PASSWORD} \
    --user-principal-name p01@${DOMAIN} \
    --query id \
    --output tsv)

Aggiungere l'utente con privilegi al gruppo di responsabili approvazione usando il az ad group member add comando .
```
az ad group member add \
    --group $APPROVER_ID \
    --member-id $PUSER_ID
```

Abilitare Privileged Identity Management (PIM) per il gruppo di amministrazione

Nella home page portale di Azure selezionare Microsoft Entra ID.
Dal menu del servizio, in Gestisci, selezionare Gruppi e quindi selezionare il gruppo di amministrazione .
Dal menu del servizio, in Attività, selezionare Privileged Identity Management e quindi selezionare Abilita PIM per questo gruppo.

Impostare un responsabile approvazione per il gruppo di amministratori

Nella home page portale di Azure cercare e selezionare Privileged Identity Management.
Dal menu del servizio, in Gestisci, selezionare Gruppi e quindi selezionare il gruppo di amministrazione .
Dal menu del servizio, in Gestisci, selezionare Assegnazioni>Aggiungi assegnazioni.
Nella scheda Appartenenza della pagina Aggiungi assegnazioni selezionare Membro come ruolo selezionato e impostazione predefinita come membro selezionato e quindi selezionare Avanti.
Nella scheda Impostazioni selezionare Idoneo come tipo di assegnazione e quindi selezionare Assegna.
Dal menu del servizio, in Gestisci, selezionare Impostazioni>Membro>Modifica.
Nella pagina Modifica impostazione ruolo - Membro selezionare la casella di controllo Richiedi approvazione per attivare e aggiungere il gruppo responsabile approvazione come responsabile approvazione selezionato.

Nota

Se non si seleziona la casella di controllo Richiedi approvazione per attivare , gli utenti del gruppo predefinito possono attivare automaticamente il ruolo per ottenere l'accesso JIT al cluster del servizio Azure Kubernetes senza approvazione. L'utente nel gruppo responsabile approvazione deve essere membro del gruppo. Anche se si imposta l'utente come proprietario, non sono ancora in grado di esaminare le richieste JUST-in-time perché il proprietario del gruppo ha solo diritti amministrativi per il gruppo, non l'assegnazione di ruolo. È possibile impostare l'utente come membro e proprietario dello stesso gruppo senza conflitti.
Apportare altre modifiche necessarie e quindi selezionare Aggiorna.

Per altre informazioni sulla configurazione di PIM, vedere Configurare PIM per i gruppi.

Interagire con le risorse del cluster usando il ruolo predefinito

È ora possibile provare ad accedere al cluster del servizio Azure Kubernetes usando l'utente normale , membro del gruppo predefinito .

Accedere al portale di Azure come utente normale usando il az login comando .
```
az login --username n01@$DOMAIN --password ${PASSWORD}
```
Ottenere le credenziali utente per accedere al cluster usando il comando az aks get-credentials.
```
az aks get-credentials --resource-group <resource-group-name> --name <cluster-name>
```

Provare ad accedere ai pod del cluster usando il kubectl get comando .

kubectl get pods --namespace kube-system

L'output dovrebbe essere simile all'output di esempio seguente, che mostra i pod nello spazio dei kube-system nomi :

NAME                                   READY   STATUS    RESTARTS   AGE
azure-ip-masq-agent-2rdd9              1/1     Running   0          30h
azure-policy-767c9d9d9d-886rf          1/1     Running   0          31h
cloud-node-manager-92t6h               1/1     Running   0          30h
coredns-789789675-b2dhg                1/1     Running   0          31h
coredns-autoscaler-77bbc46446-pgt92    1/1     Running   0          31h
csi-azuredisk-node-lnzrf               3/3     Running   0          30h
csi-azurefile-node-lhbxr               3/3     Running   0          31h
konnectivity-agent-7645d94b-9wqct      1/1     Running   0          30h
kube-proxy-lkx4w                       1/1     Running   0          31h
metrics-server-5955767688-lpbjb        2/2     Running   0          30h

Provare ad accedere ai segreti del cluster usando il kubectl get comando .
```
kubectl get secrets --namespace kube-system
```
L'output dovrebbe essere simile all'output di esempio seguente, che mostra un messaggio di errore perché l'utente non dispone dell'autorizzazione per accedere ai segreti:
```
Error from server (Forbidden): secrets is forbidden: User "[email protected]" cannot list resource "secrets" in API group "" in the namespace "kube-system": User does not have access to the resource in Azure. Update role assignment to allow access.
```
Il Azure Kubernetes Service RBAC Reader ruolo non dispone dell'autorizzazione per accedere ai segreti, quindi questo errore è previsto.

Richiedere l'accesso JIT al cluster del servizio Azure Kubernetes

Questa volta, è possibile richiedere l'accesso JIT come temporaneo Azure Kubernetes Service RBAC Admin seguendo la procedura descritta in Attivare l'appartenenza al gruppo o la proprietà in Privileged Identity Management. Per informazioni su come approvare o negare le richieste come responsabile approvazione, vedere Approvare le richieste di attivazione per i membri e i proprietari del gruppo.

Interagire con le risorse del cluster usando il ruolo di amministratore

Dopo aver aggiunto temporaneamente il Azure Kubernetes Service RBAC Admin ruolo, è possibile accedere alle risorse del cluster che richiedono autorizzazioni di amministratore.

Rimuovere i token archiviati esistenti usando il comando seguente kubelogin :
```
kubelogin remove-tokens
```
Nota

Se si verifica un errore a causa della mancanza di autorizzazioni, accedere per aggiornare le autorizzazioni usando il az login comando .
Provare di nuovo ad accedere ai segreti del cluster usando il kubectl get secrets comando .
```
kubectl get secrets --namespace kube-system
```
L'output dovrebbe essere simile all'output di esempio seguente, che mostra i segreti nello spazio dei kube-system nomi :
```
NAME                     TYPE                            DATA   AGE
bootstrap-token-sw3rck   bootstrap.kubernetes.io/token   4      35h
konnectivity-certs       Opaque                          3      35h
```
L'utente può ora accedere ai segreti perché ha il Azure Kubernetes Service RBAC Admin ruolo .

Considerazioni sulla durata dei token

A causa della progettazione della durata dei token, se si concedono ruoli agli utenti che usano gli strumenti dell'interfaccia della riga di comando, ad esempio kubectl o kubelogin, la durata di attivazione tecnicamente non può essere inferiore a 60 minuti. Anche se la durata è impostata su meno di 60 minuti, la durata effettiva rimane compresa tra 60 e 75 minuti.

Quando kubelogin tenta di ottenere token da Microsoft Identity Platformaccess_token e refresh_token vengono restituiti per un ulteriore uso. Effettua access_token richieste all'API e refresh_token viene usato per ottenere un nuovo access_token quando scade quello corrente. access_token Non può essere revocato una volta generato, ma refresh_token può essere revocato. Se l'oggetto refresh_token viene revocato, l'utente deve ripetere l'autenticazione per ottenere un nuovo refresh_tokenoggetto . Per revocare manualmente , refresh_tokenè possibile usare Revoke-AzureADUserAllRefreshToken.

Passaggi successivi

Per altre informazioni, vedere gli articoli seguenti:

Condividi tramite