Usare il controllo degli accessi in base al ruolo di Azure nei cluster Kubernetes abilitati per Azure Arc
I tipi di oggetto ClusterRoleBinding e RoleBinding Kubernetes consentono di definire l'autorizzazione in Kubernetes in modo nativo. Usando questa funzionalità, è possibile usare le assegnazioni di ruolo e Microsoft Entra ID in Azure per controllare i controlli delle autorizzazioni nel cluster. Le assegnazioni di ruolo di Azure consentono di controllare in modo granulare quali utenti possono leggere, scrivere ed eliminare oggetti Kubernetes, ad esempio distribuzione, pod e servizio.
Per una panoramica concettuale di questa funzionalità, vedere Controllo degli accessi in base al ruolo di Azure in Kubernetes abilitato per Azure Arc.
Prerequisiti
Installare o aggiornare l'interfaccia della riga di comando di Azure all'ultima versione.
Installare l'ultima versione dell'interfaccia della riga di comando di Azure
connectedk8s
:az extension add --name connectedk8s
Se l'estensione
connectedk8s
è già installata, è possibile aggiornarla all'ultima versione usando il comando seguente:az extension update --name connectedk8s
Connettere un cluster Kubernetes esistente abilitato per Azure Arc:
- Se non è ancora stato connesso un cluster, usare la guida introduttiva.
- Aggiornare gli agenti all'ultima versione.
Nota
Il controllo degli accessi in base al ruolo di Azure non è disponibile per le offerte Red Hat OpenShift o Kubernetes gestite in cui l'accesso utente al server API è limitato, ad esempio Amazon Elastic Kubernetes Service (EKS), Google Kubernetes Engine (GKE).
Il controllo degli accessi in base al ruolo di Azure attualmente non supporta i cluster Kubernetes che operano nell'architettura ARM64. Usare il controllo degli accessi in base al ruolo di Kubernetes per gestire il controllo di accesso per i cluster Kubernetes basati su ARM64.
Per i cluster del servizio Azure Kubernetes (AKS), questa funzionalità è disponibile in modo nativo e non richiede che il cluster del servizio Azure Kubernetes sia connesso ad Azure Arc.
Per i cluster servizio Azure Kubernetes (AKS) abilitati da Azure Arc in Azure Stack HCI 23H2, l'abilitazione del controllo degli accessi in base al ruolo di Azure è attualmente supportata solo durante la creazione del cluster Kubernetes. Per creare un cluster del servizio Azure Kubernetes abilitato da Azure Arc con il controllo degli accessi in base al ruolo di Azure abilitato, seguire la guida usare il controllo degli accessi in base al ruolo di Azure per Kubernetes . Si noti che il controllo degli accessi in base al ruolo di Azure non è supportato per Azure Stack HCI versione 22H2.
Abilitare il controllo degli accessi in base al ruolo di Azure nel cluster
Ottenere l'identità MSI del cluster eseguendo il comando seguente:
az connectedk8s show -g <resource-group> -n <connected-cluster-name>
Ottenere l'ID (
identity.principalId
) dall'output ed eseguire il comando seguente per assegnare il ruolo lettore controllo accessi dell'identità gestita del cluster connesso a MSI del cluster:az role assignment create --role "Connected Cluster Managed Identity CheckAccess Reader" --assignee "<Cluster MSI ID>" --scope <cluster ARM ID>
Abilitare il controllo degli accessi in base al ruolo (RBAC) di Azure nel cluster Kubernetes abilitato per Azure Arc eseguendo il comando seguente:
az connectedk8s enable-features -n <clusterName> -g <resourceGroupName> --features azure-rbac
Nota
Prima di eseguire il comando precedente, assicurarsi che il file
kubeconfig
nel computer punti al cluster in cui si abiliterà la funzionalità di Controllo degli accessi in base al ruolo di Azure.Usare
--skip-azure-rbac-list
con il comando precedente per un elenco delimitato da virgole di nomi utente, indirizzi di posta elettronica e connessioni OpenID sottoposti a controlli di autorizzazione usando oggettiClusterRoleBinding
eRoleBinding
nativi per i Kubernetes anziché il controllo degli accessi in base al ruolo di Azure.
Cluster generico in cui non è in esecuzione alcun riconciliatore nella specifica apiserver
Eseguire SSH in ogni nodo master del cluster e seguire questa procedura:
Se
kube-apiserver
è un pod statico:Il segreto
azure-arc-guard-manifests
nello spazio dei nomikube-system
contiene due file:guard-authn-webhook.yaml
eguard-authz-webhook.yaml
. Copiare questi file nella directory/etc/guard
del nodo.sudo mkdir -p /etc/guard kubectl get secrets azure-arc-guard-manifests -n kube-system -o json | jq -r '.data."guard-authn-webhook.yaml"' | base64 -d > /etc/guard/guard-authn-webhook.yaml kubectl get secrets azure-arc-guard-manifests -n kube-system -o json | jq -r '.data."guard-authz-webhook.yaml"' | base64 -d > /etc/guard/guard-authz-webhook.yaml
Aprire il manifesto
apiserver
in modalità di modifica:sudo vi /etc/kubernetes/manifests/kube-apiserver.yaml
Aggiungere la specifica seguente in
volumes
:- hostPath path: /etc/guard type: Directory name: azure-rbac
Aggiungere la specifica seguente in
volumeMounts
:- mountPath: /etc/guard name: azure-rbac readOnly: true
Se
kube-apiserver
non è un pod statico:Aprire il manifesto
apiserver
in modalità di modifica:sudo vi /etc/kubernetes/manifests/kube-apiserver.yaml
Aggiungere la specifica seguente in
volumes
:- name: azure-rbac secret: secretName: azure-arc-guard-manifests
Aggiungere la specifica seguente in
volumeMounts
:- mountPath: /etc/guard name: azure-rbac readOnly: true
Aggiungere gli argomenti
apiserver
seguenti:- --authentication-token-webhook-config-file=/etc/guard/guard-authn-webhook.yaml - --authentication-token-webhook-cache-ttl=5m0s - --authorization-webhook-cache-authorized-ttl=5m0s - --authorization-webhook-config-file=/etc/guard/guard-authz-webhook.yaml - --authorization-webhook-version=v1 - --authorization-mode=Node,RBAC,Webhook
Se il cluster Kubernetes è aggiornato alla versione 1.19.0 o successiva, è necessario impostare anche l'argomento
apiserver
seguente:- --authentication-token-webhook-version=v1
Salvare e chiudere l'editor per aggiornare il pod
apiserver
.
Cluster creato tramite l'API cluster
Copiare il segreto guardia che contiene i file di configurazione del webhook di autenticazione e autorizzazione dal cluster del carico di lavoro nel computer:
kubectl get secret azure-arc-guard-manifests -n kube-system -o yaml > azure-arc-guard-manifests.yaml
Modificare il campo
namespace
nel file azure-arc-guard-manifests.yaml nello spazio dei nomi all'interno del cluster di gestione in cui si applicano le risorse personalizzate per la creazione di cluster del carico di lavoro.Applicare questo manifesto:
kubectl apply -f azure-arc-guard-manifests.yaml
Modificare l'oggetto
KubeadmControlPlane
eseguendokubectl edit kcp <clustername>-control-plane
:Aggiungere il frammento di codice seguente in
files
:- contentFrom: secret: key: guard-authn-webhook.yaml name: azure-arc-guard-manifests owner: root:root path: /etc/kubernetes/guard-authn-webhook.yaml permissions: "0644" - contentFrom: secret: key: guard-authz-webhook.yaml name: azure-arc-guard-manifests owner: root:root path: /etc/kubernetes/guard-authz-webhook.yaml permissions: "0644"
Aggiungere il frammento di codice seguente in
apiServer
>extraVolumes
:- hostPath: /etc/kubernetes/guard-authn-webhook.yaml mountPath: /etc/guard/guard-authn-webhook.yaml name: guard-authn readOnly: true - hostPath: /etc/kubernetes/guard-authz-webhook.yaml mountPath: /etc/guard/guard-authz-webhook.yaml name: guard-authz readOnly: true
Aggiungere il frammento di codice seguente in
apiServer
>extraArgs
:authentication-token-webhook-cache-ttl: 5m0s authentication-token-webhook-config-file: /etc/guard/guard-authn-webhook.yaml authentication-token-webhook-version: v1 authorization-mode: Node,RBAC,Webhook authorization-webhook-cache-authorized-ttl: 5m0s authorization-webhook-config-file: /etc/guard/guard-authz-webhook.yaml authorization-webhook-version: v1
Salvare e chiudere per aggiornare l'oggetto
KubeadmControlPlane
. Attendere che queste modifiche vengano visualizzate nel cluster del carico di lavoro.
Creare assegnazioni di ruolo agli utenti per accedere al cluster
I proprietari della risorsa Kubernetes abilitata per Azure Arc possono usare ruoli predefiniti o ruoli personalizzati per concedere ad altri utenti l'accesso al cluster Kubernetes.
Ruoli predefiniti
Ruolo | Descrizione |
---|---|
Visualizzatore di Kubernetes con abilitazione di Azure Arc | Consente l'accesso in sola lettura per visualizzare la maggior parte degli oggetti in uno spazio dei nomi. Questo ruolo non consente la visualizzazione dei segreti, perché l'autorizzazione read per i segreti consentirebbe l'accesso alle credenziali ServiceAccount nello spazio dei nomi. Queste credenziali a loro volta consentono l'accesso all'API tramite tale valore ServiceAccount (una forma di escalation dei privilegi). |
Ruolo con autorizzazioni di scrittura per Kubernetes con abilitazione di Azure Arc | 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 di accedere ai segreti e di eseguire pod come qualunque valore ServiceAccount nello spazio dei nomi, per cui può essere usato per ottenere i livelli di accesso alle API di qualsiasi valore ServiceAccount nello spazio dei nomi. |
Amministratore di Kubernetes con abilitazione di Azure Arc | Consente l'accesso amministratore. Deve essere concesso all'interno di uno spazio dei nomi tramite RoleBinding . Se si usa in RoleBinding , 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. |
Amministratore del cluster di Kubernetes con abilitazione di Azure Arc | Consente all'utente con privilegi avanzati di eseguire qualsiasi azione su qualsiasi risorsa. Quando si usa in ClusterRoleBinding , fornisce il controllo completo su ogni risorsa nel cluster e in tutti gli spazi dei nomi. Quando lo si usa in RoleBinding , fornisce il controllo completo su ogni risorsa nello spazio dei nomi dell'associazione di ruoli, incluso lo spazio dei nomi stesso. |
È possibile creare assegnazioni di ruolo con ambito al cluster Kubernetes abilitato per Azure Arc nel portale di Azure, nel riquadro Controllo di accesso (IAM) della risorsa del cluster. È anche possibile usare i comandi seguenti dell'interfaccia della riga di comando di Azure:
az role assignment create --role "Azure Arc Kubernetes Cluster Admin" --assignee <AZURE-AD-ENTITY-ID> --scope $ARM_ID
In questi comandi, AZURE-AD-ENTITY-ID
può essere un nome utente (ad esempio, testuser@mytenant.onmicrosoft.com
) o anche il valore appId
di un'entità servizio.
Ecco un altro esempio di creazione di un'assegnazione di ruolo con ambito per uno spazio dei nomi specifico all'interno del cluster:
az role assignment create --role "Azure Arc Kubernetes Viewer" --assignee <AZURE-AD-ENTITY-ID> --scope $ARM_ID/namespaces/<namespace-name>
Nota
È possibile creare assegnazioni di ruolo con ambito al cluster usando il portale di Azure o l'interfaccia della riga di comando di Azure. Tuttavia, solo l'interfaccia della riga di comando di Azure può essere usata per creare assegnazioni di ruolo con ambito per lo spazi dei nomi.
Ruoli personalizzati
È possibile scegliere di creare una definizione di ruolo personalizzata da usare nelle assegnazioni di ruolo.
Esaminare l'esempio seguente di una definizione di ruolo che consente a un utente di leggere solo le distribuzioni. Per altre informazioni, vedere l'elenco completo delle azioni sui dati che è possibile usare per costruire una definizione del ruolo.
Copiare l'oggetto JSON seguente in un file denominato custom-role.json. Sostituire il segnaposto <subscription-id>
con l'ID della sottoscrizione effettivo. Il ruolo personalizzato usa una delle azioni di dati e consente di visualizzare tutte le distribuzioni nell'ambito (cluster o spazio dei nomi) in cui viene creata l'assegnazione di ruolo.
{
"Name": "Arc Deployment Viewer",
"Description": "Lets you view all deployments in cluster/namespace.",
"Actions": [],
"NotActions": [],
"DataActions": [
"Microsoft.Kubernetes/connectedClusters/apps/deployments/read"
],
"NotDataActions": [],
"assignableScopes": [
"/subscriptions/<subscription-id>"
]
}
Creare la definizione del ruolo eseguendo il comando seguente dalla cartella in cui è stato salvato custom-role.json:
az role definition create --role-definition @custom-role.json
Creare un'assegnazione di ruolo usando questa definizione di ruolo personalizzata:
az role assignment create --role "Arc Deployment Viewer" --assignee <AZURE-AD-ENTITY-ID> --scope $ARM_ID/namespaces/<namespace-name>
Configurare kubectl con le credenziali utente
Esistono due modi per ottenere il file kubeconfig che è necessario per accedere al cluster:
- Usare la funzionalità di connessione del cluster (
az connectedk8s proxy
) del cluster Kubernetes abilitato per Azure Arc. - L'amministratore del cluster condivide il file kubeconfig con ogni altro utente.
Usare la connessione del cluster
Eseguire il comando seguente per avviare il processo proxy:
az connectedk8s proxy -n <clusterName> -g <resourceGroupName>
Dopo l'esecuzione del processo proxy, è possibile aprire un'altra scheda nella console per avviare l'invio delle richieste al cluster.
Usare un file kubeconfig condiviso
L'uso di un kubeconfig condiviso richiede passaggi leggermente diversi a seconda della versione di Kubernetes.
Eseguire il comando seguente per impostare le credenziali per l'utente. Specificare
serverApplicationId
come6256c85f-0aad-4d50-b960-e6e9b21efe35
eclientApplicationId
come3f4439ff-e698-4d6d-84fe-09c9d574f06b
:kubectl config set-credentials <testuser>@<mytenant.onmicrosoft.com> \ --auth-provider=azure \ --auth-provider-arg=environment=AzurePublicCloud \ --auth-provider-arg=client-id=<clientApplicationId> \ --auth-provider-arg=tenant-id=<tenantId> \ --auth-provider-arg=apiserver-id=<serverApplicationId>
Aprire il file kubeconfig creato in precedenza. In
contexts
, verificare che il contesto associato al cluster punti alle credenziali utente create nel passaggio precedente. Per impostare il contesto corrente su queste credenziali utente, eseguire il comando seguente:kubectl config set-context --current=true --user=<testuser>@<mytenant.onmicrosoft.com>
Aggiungere l'impostazione config-mode in
user
>config
:name: testuser@mytenant.onmicrosoft.com user: auth-provider: config: apiserver-id: $SERVER_APP_ID client-id: $CLIENT_APP_ID environment: AzurePublicCloud tenant-id: $TENANT_ID config-mode: "1" name: azure
Nota
Il plug-in exec è una strategia di autenticazione Kubernetes che consente a
kubectl
di eseguire un comando esterno per ricevere le credenziali utente da inviare aapiserver
. A partire da Kubernetes versione 1.26, il plug-in di autorizzazione di Azure predefinito non è più incluso inclient-go
ekubectl
. Con le versioni successive, per usare il plug-in exec per ricevere le credenziali utente, è necessario usare Azure Kubelogin, unclient-go
plug-in credenziali (exec) che implementa l'autenticazione di Azure.Installare Azure Kubelogin:
Per Windows o Mac, seguire le istruzioni di installazione di Azure Kubelogin.
Per Linux o Ubuntu, scaricare l'ultima versione di kubelogin, quindi eseguire i comandi seguenti:
curl -LO https://github.com/Azure/kubelogin/releases/download/"$KUBELOGIN_VERSION"/kubelogin-linux-amd64.zip unzip kubelogin-linux-amd64.zip sudo mv bin/linux_amd64/kubelogin /usr/local/bin/ sudo chmod +x /usr/local/bin/kubelogin
Kubelogin può essere usato per eseguire l'autenticazione con i cluster abilitati per Azure Arc richiedendo un token di verifica del possesso (PoP). Convertire kubeconfig usando kubelogin per usare la modalità di accesso appropriata. Ad esempio, per l'accesso al codice del dispositivo con un utente di Microsoft Entra, i comandi sono i seguenti:
export KUBECONFIG=/path/to/kubeconfig kubelogin convert-kubeconfig --pop-enabled --pop-claims 'u=<ARM ID of cluster>"
Inviare richieste al cluster
Eseguire qualsiasi comando
kubectl
. Ad esempio:kubectl get nodes
kubectl get pods
Dopo aver richiesto l'autenticazione basata su browser, copiare l'URL di accesso del dispositivo (
https://microsoft.com/devicelogin
) e aprirlo nel Web browser.Immettere il codice stampato sulla console. Copiare e incollare il codice sul terminale nella richiesta di input di autenticazione del dispositivo.
Immettere il nome utente (
testuser@mytenant.onmicrosoft.com
) e la password associata.Se viene visualizzato un messaggio di errore simile al seguente, significa che non si è autorizzati ad accedere alla risorsa richiesta:
Error from server (Forbidden): nodes is forbidden: User "testuser@mytenant.onmicrosoft.com" cannot list resource "nodes" in API group "" at the cluster scope: User doesn't have access to the resource in Azure. Update role assignment to allow access.
Un amministratore deve creare una nuova assegnazione di ruolo che autorizza l'utente ad accedere alla risorsa.
Usare l'accesso condizionale con Microsoft Entra ID
Quando si integra Microsoft Entra ID con il cluster Kubernetes abilitato per Azure Arc, è anche possibile usare l'accesso condizionale per controllare l'accesso al cluster.
Nota
L'accesso condizionale di Microsoft Entra è una funzionalità di Microsoft Entra ID P2.
Per creare un esempio di criteri di accesso condizionale da usare con il cluster:
Nella parte superiore del portale di Azure, cercare e selezionare Microsoft Entra ID.
Nel menu per Microsoft Entra ID sul lato sinistro, selezionare Applicazioni aziendali.
Nel menu per le applicazioni aziendali a sinistra, selezionare Accesso condizionale.
Nel menu per l'accesso condizionale a sinistra, selezionare Criteri>Nuovo criterio.
Immettere un nome per il criterio, ad esempio arc-k8s-policy.
Selezionare Utenti e gruppi. In Includi, scegliere Seleziona utenti e gruppi. Scegliere gli utenti e i gruppi a cui applicare i criteri. Per questo esempio scegliere lo stesso gruppo Microsoft Entra con accesso amministrativo al cluster.
Selezionare Applicazioni cloud o azioni. In Includi, scegliere Selezionare le app. Quindi, cercare e selezionare l'applicazione server creata in precedenza.
In Controlli di accesso selezionare Concedi. Selezionare Concedi accesso>Richiedi che i dispositivi siano contrassegnati come conformi.
In Abilita criterio selezionare Sì>Crea.
Accedere di nuovo al cluster. Ad esempio, eseguire il comando kubectl get nodes
per visualizzare i nodi nel cluster:
kubectl get nodes
Seguire le istruzioni per accedere nuovamente. Un messaggio di errore indica che l'accesso è stato eseguito correttamente, ma l'amministratore richiede che il dispositivo che richiede l'accesso venga gestito da Microsoft Entra ID per accedere alla risorsa. Seguire questa procedura:
Nel portale di Azure passare a Microsoft Entra ID.
Selezionare Applicazioni aziendali. Quindi, in Attività selezionare Accessi.
Una voce nella parte superiore mostra Non riuscito per Stato e Riuscito per Accesso condizionale. Selezionare la voce, quindi selezionare Accesso condizionale in Dettagli. Si noti che sono elencati i criteri di accesso condizionale.
Configurare l'accesso just-in-time del cluster con Microsoft Entra ID
Un'altra opzione per il controllo di accesso del cluster consiste nell'usare Privileged Identity Management (PIM) per le richieste JIT.
Nota
PIM di Microsoft Entra è una funzionalità di Microsoft Entra ID P2. Per altre informazioni sugli SKU di Microsoft Entra ID, vedere la guida ai prezzi.
Per configurare le richieste di accesso just-in-time per il cluster, completare la procedura seguente:
Nella parte superiore del portale di Azure, cercare e selezionare Microsoft Entra ID.
Prendere nota dell'ID tenant. Per il resto di queste istruzioni, si farà riferimento a tale ID come
<tenant-id>
.Nel menu per Microsoft Entra ID sul lato sinistro, in Gestisci, selezionare Gruppi>Nuovo gruppo.
Assicurarsi che l'opzione Sicurezza sia selezionata per Tipo di gruppo. Immettere un nome per il gruppo, ad esempio myJITGroup. In I ruoli di Microsoft Entra possono essere assegnati al gruppo (anteprima), selezionare Sì. Infine, selezionare Crea.
Si torna alla pagina Gruppi. Selezionare il gruppo appena creato e prendere nota dell'ID oggetto. Per il resto di queste istruzioni, si farà riferimento a questo ID come
<object-id>
.Tornare al portale di Azure, nel menu Attività sul lato sinistro selezionare Accesso con privilegi (anteprima).Back in the Azure portal, on the menu for Activity on the left side, select Privileged Access (Preview). Quindi, selezionare Abilita accesso privilegiato.
Selezionare Aggiungi assegnazioni per iniziare a concedere l'accesso.
Selezionare un ruolo di Membro e selezionare gli utenti e i gruppi a cui si vuole concedere l'accesso al cluster. Un amministratore del gruppo può modificare queste assegnazioni in qualsiasi momento. Quando si è pronti per procedere, selezionare Avanti.
Scegliere un tipo di assegnazione Attivo, selezionare la durata desiderata e fornire una giustificazione. Quando si è pronti per continuare, selezionare Assegna. Per altre informazioni sui tipi di assegnazione, vedere Assegnare l'idoneità per un gruppo di accesso con privilegi (anteprima) in Privileged Identity Management.
Dopo aver eseguito le assegnazioni, verificare che l'accesso just-in-time funzioni accedendo al cluster. Ad esempio, usare il comando kubectl get nodes
per visualizzare i nodi nel cluster:
kubectl get nodes
Prendere nota del requisito di autenticazione e seguire la procedura per l'autenticazione. Se l'autenticazione ha esito positivo, verrà visualizzato un output simile al seguente:
To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code AAAAAAAAA to authenticate.
NAME STATUS ROLES AGE VERSION
node-1 Ready agent 6m36s v1.18.14
node-2 Ready agent 6m42s v1.18.14
node-3 Ready agent 6m33s v1.18.14
Passaggi successivi
- Connettersi in modo sicuro al cluster usando Cluster Connect.
- Informazioni sull'architettura del controllo degli accessi in base al ruolo di Azure nei Kubernetes abilitati per ARC.