Condividi tramite


Usare il controllo degli accessi in base al ruolo di Azure nei cluster Kubernetes abilitati per Azure Arc

È possibile usare Microsoft Entra ID e il controllo degli accessi in base al ruolo di Azure per controllare i controlli di autorizzazione nel cluster Kubernetes abilitato per Azure Arc. Le assegnazioni di ruolo di Azure consentono di controllare in modo granulare quali utenti possono leggere, scrivere ed eliminare oggetti Kubernetes, ad esempio una distribuzione, un pod e un servizio. I tipi di oggetto ClusterRoleBinding e RoleBinding Kubernetes consentono di definire l'autorizzazione in Kubernetes in modo nativo.

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’estensione di Azure CLI:

    az extension add --name connectedk8s
    

    Se l'estensione connectedk8s è già installata, è possibile aggiornarla all'ultima versione utilizzando il comando seguente:

    az extension update --name connectedk8s
    
  • Connettere un cluster Kubernetes abilitato per Azure Arc esistente:

Nota

Il RBAC di Azure non è supportato per le offerte gestite di Red Hat OpenShift o Kubernetes in cui l'accesso degli utenti al server API è limitato (ad esempio Amazon Elastic Kubernetes Service (EKS) o Google Kubernetes Engine (GKE)).

Attualmente, Azure RBAC non supporta i cluster Kubernetes che operano sull'architettura Arm64. Per questi cluster, utilizzare RBAC di Kubernetes per gestire l'accesso.

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 di Azure Kubernetes Service (AKS) abilitati tramite Azure Arc su Azure Local, versione 23H2, Azure RBAC è attualmente supportato solo se abilitato al momento della creazione dei cluster. Per creare un cluster AKS abilitato da Azure Arc con Azure RBAC, vedere Usare Azure RBAC per l'autorizzazione di Kubernetes. Il controllo degli accessi in base ai ruoli di Azure non è supportato per Azure Locale, versione 22H2.

Abilitare il controllo degli accessi in base al ruolo di Azure nel cluster

  1. Ottenere l'identità MSI del cluster eseguendo il comando seguente:

    az connectedk8s show -g <resource-group> -n <connected-cluster-name>
    
  2. 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>
    
  3. 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 enable-features, assicurati che il file kubeconfig nel computer punti al cluster in cui vuoi abilitare Azure RBAC.

    Utilizzare --skip-azure-rbac-list con il comando precedente per un elenco delimitato da virgole di nomi utente, indirizzi e-mail e connessioni OpenID sottoposti a controlli di autorizzazione utilizzando oggetti ClusterRoleBinding e RoleBinding nativi per Kubernetes anziché il controllo degli accessi in base al ruolo di Azure.

Seguire quindi i passaggi nella sezione appropriata, a seconda che si usi un cluster generico in cui non è in esecuzione alcun riconciliatore nella apiserver specifica o un cluster creato usando l'API cluster.

Cluster generico in cui non è in esecuzione alcun riconciliatore nella specifica apiserver

  1. Eseguire ssh in ogni nodo master del cluster, quindi completare i passaggi seguenti:

    Se kube-apiserver è un pod statico:

    1. Il segreto azure-arc-guard-manifests nello spazio dei nomi kube-system contiene due file: guard-authn-webhook.yaml e guard-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
      
    2. Aprire il manifesto apiserver in modalità di modifica:

      sudo vi /etc/kubernetes/manifests/kube-apiserver.yaml
      
    3. Aggiungere la specifica seguente in volumes:

      - hostPath:
          path: /etc/guard
          type: Directory
        name: azure-rbac
      
    4. Aggiungere la specifica seguente in volumeMounts:

      - mountPath: /etc/guard
        name: azure-rbac
        readOnly: true
      

    Se il tuo kube-apiserver non è un pod statico:

    1. Aprire il manifesto apiserver in modalità di modifica:

      sudo vi /etc/kubernetes/manifests/kube-apiserver.yaml
      
    2. Aggiungere la specifica seguente in volumes:

      - name: azure-rbac
        secret:
          secretName: azure-arc-guard-manifests
      
    3. Aggiungere la specifica seguente in volumeMounts:

      - mountPath: /etc/guard
        name: azure-rbac
        readOnly: true
      
  2. 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
    

    Impostare il seguente argomento apiserver:

    - --authentication-token-webhook-version=v1
    
  3. Salvare e chiudere l'editor per aggiornare il pod apiserver.

Cluster creato tramite l'API cluster

  1. 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
    
  2. 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.

  3. Applicare questo manifesto:

    kubectl apply -f azure-arc-guard-manifests.yaml
    
  4. Modificare l'oggetto KubeadmControlPlane eseguendo kubectl edit kcp <clustername>-control-plane:

    1. Aggiungere la specifica 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"
      
    2. Aggiungere la specifica 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
      
    3. Aggiungere la specifica 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
      
    4. Salvare e chiudere per aggiornare l'oggetto KubeadmControlPlane. Attendere che queste modifiche vengano visualizzate nel cluster del carico di lavoro.

Creare assegnazioni di ruolo per consentire agli utenti per accedere al cluster

I proprietari della risorsa Kubernetes abilitata per Azure Arc possono utilizzare ruoli predefiniti o ruoli personalizzati per concedere ad altri utenti l'accesso al cluster Kubernetes.

Ruoli predefiniti

I ruoli predefiniti seguenti forniscono l'accesso per eseguire attività comuni nei cluster Kubernetes. Questi ruoli possono essere concessi a utenti, gruppi o entità servizio di Microsoft Entra ID.

Ruolo Descrizione
Visualizzatore di Kubernetes abilitato per 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 abilitato per 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 utilizzato 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. Questo ruolo viene spesso concesso all'interno di uno spazio dei nomi tramite l'oggetto RoleBinding di . Se si utilizza 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. Tuttavia, questo ruolo non consente l'accesso in scrittura alla quota di risorse o allo spazio dei nomi stesso.
Amministratore del cluster di Kubernetes abilitato per Azure Arc Consente di eseguire qualsiasi azione su qualsiasi risorsa all'interno dell'ambito concesso. Quando lo si usa in ClusterRoleBinding, consente il controllo completo su ogni risorsa nel cluster e in tutti gli spazi dei nomi. Quando lo si utilizza in RoleBinding, consente 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 predefinite con ambito al cluster usando il portale di Azure o l'interfaccia della riga di comando di Azure. Tuttavia, è possibile utilizzare solo l'interfaccia della riga di comando di Azure per creare assegnazioni di ruolo con ambito per lo spazi dei nomi.

Per creare assegnazioni di ruolo con ambito al cluster Kubernetes abilitato per Azure Arc nel portale di Azure, passare al cluster e quindi selezionare Controllo di accesso (IAM) dal menu del servizio.

Per creare assegnazioni di ruolo usando l'interfaccia della riga di comando di Azure, usare il comando seguente:

az role assignment create --role "Azure Arc Kubernetes Cluster Admin" --assignee <AZURE-AD-ENTITY-ID> --scope $ARM_ID

AZURE-AD-ENTITY-ID può essere un nome utente (ad esempio, [email protected]) o il valore di un principale del servizio appId.

Per creare un'assegnazione di ruolo con ambito a uno spazio dei nomi specifico all'interno del cluster, modificare l'ambito:

az role assignment create --role "Azure Arc Kubernetes Viewer" --assignee <AZURE-AD-ENTITY-ID> --scope $ARM_ID/namespaces/<namespace-name>

Ruoli personalizzati

È possibile scegliere di creare una definizione di ruolo personalizzata da utilizzare nelle assegnazioni di ruolo. Per altre informazioni, vedere l'elenco completo delle azioni sui dati che è possibile utilizzare per creare una definizione del ruolo.

L'esempio seguente mostra una definizione di ruolo personalizzata che consente a un utente di leggere le distribuzioni, ma non fornisce altro accesso. Il ruolo personalizzato utilizza 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>"
    ]
}

Per usare questa definizione di ruolo, copiare l'oggetto JSON seguente in un file denominato custom-role.json. Sostituire il segnaposto <subscription-id> con l'ID della sottoscrizione effettivo. Completare quindi questi passaggi:

  1. 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
    
  2. Creare un'assegnazione di ruolo per assegnare 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 può condividere il file kubeconfig con ogni utente.

Utilizzare 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.

Utilizzare un file kubeconfig condiviso

  1. Eseguire il comando seguente per impostare le credenziali per l'utente. Specificare serverApplicationId come 6256c85f-0aad-4d50-b960-e6e9b21efe35 e clientApplicationId come 3f4439ff-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>
    
  2. 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>
    
  3. Aggiungere l'impostazione config-mode in user>config:

    name: [email protected]
    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
    
  4. plug-in exec è una strategia di autenticazione Kubernetes che consente a kubectl di eseguire un comando esterno per ricevere le credenziali utente da inviare a apiserver. A partire da Kubernetes versione 1.26, per usare il plug-in exec per ricevere le credenziali utente, è necessario usare azure kubelogin, un client-go plug-in credential (exec) che implementa l'autenticazione di Azure. Per installare Azure kubelogin:

    • Per Windows o Mac, seguire le istruzioni di installazione di Azure kubelogin.

    • Per Linux o Ubuntu, scaricare la versione più recente 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 
      
  5. Kubelogin può essere utilizzato 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

  1. Eseguire qualsiasi comando kubectl. Ad esempio:

    • kubectl get nodes
    • kubectl get pods
  2. Dopo aver richiesto l'autenticazione basata su browser, copiare l'URL di accesso del dispositivo (https://microsoft.com/devicelogin) e aprirlo nel Web browser.

  3. Immettere il codice stampato sulla console. Copiare e incollare il codice sul terminale nella richiesta di input di autenticazione del dispositivo.

  4. Immettere il nome utente ([email protected]) e la password associata.

  5. Se viene visualizzato un messaggio di errore che indica che gli utenti non hanno accesso alla risorsa in Azure, significa che non si è autorizzati ad accedere alla risorsa richiesta. In questo caso, un amministratore nel tenant di Azure deve creare una nuova assegnazione di ruolo che autorizza l'utente ad avere accesso alla risorsa.

Utilizzare l'accesso condizionale con Microsoft Entra ID

Quando si integra Microsoft Entra ID con il cluster Kubernetes abilitato per Azure Arc, è anche possibile utilizzare l'accesso condizionale per controllare l'accesso al cluster.

Nota

L'accesso condizionale 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 creare un esempio di criteri di accesso condizionale da utilizzare con il cluster:

  1. Nella parte superiore del portale di Azure, cercare e selezionare Microsoft Entra ID.
  2. Nel menu del servizio, in Gestisci, selezionare Applicazioni aziendali.
  3. Nel menu del servizio, in Sicurezza, selezionare Accesso condizionale.
  4. Nel menu del servizio selezionare Criteri. Selezionare quindi Crea nuovo criterio.
  5. Immettere un nome per il criterio, ad esempio arc-k8s-policy.
  6. In Assegnazioni, selezionare il valore corrente in Utenti o identità del carico di lavoro. Quindi, in Che cosa si applica questo criterio?, verificare che l'opzione Utenti e gruppi sia selezionata.
  7. 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.
  8. Selezionare il valore corrente in App o azioni cloud. Quindi, in Seleziona a cosa si applica questa regola, verificare che siano selezionate le App cloud.
  9. In Includi scegliere Seleziona risorse. Quindi, cercare e selezionare l'applicazione server creata in precedenza.
  10. In Controlli di accesso selezionare il valore corrente in Concedi. Selezionare quindi Concedi accesso.
  11. Spunta la casella per richiedere che il dispositivo sia contrassegnato come conforme, quindi fai clic su Seleziona.
  12. In Abilita criterio selezionare .
  13. Per applicare il criterio di accesso condizionale, selezionare Crea.

Accedere di nuovo al cluster. Ad esempio, eseguire il comando kubectl get nodes per visualizzare i nodi nel cluster:

kubectl get nodes

Per verificare che il criterio venga applicato correttamente, seguire le istruzioni per eseguire di nuovo l'accesso. Un messaggio di errore indica che l'accesso è stato eseguito correttamente, ma che l'amministratore richiede che il dispositivo che richiede l'accesso venga gestito da Microsoft Entra ID per accedere alla risorsa. Per visualizzare altri dettagli, seguire questa procedura:

  1. Nel portale di Azure passare a Microsoft Entra ID.
  2. Nel menu del servizio, in Gestisci, selezionare Applicazioni aziendali.
  3. Nel menu del servizio, in Attività, selezionare Log di accesso.
  4. Selezionare la voce nella parte superiore che mostra Non riuscito per stato e Operazione riuscita per l'accesso condizionale. Quindi, in Dettagli selezionare Accesso condizionale. Verranno visualizzati i criteri di accesso condizionale creati, che richiedono che il dispositivo sia conforme.

Configurare l'accesso just-in-time del cluster con Microsoft Entra ID

Un'altra opzione per il controllo di accesso del cluster è Privileged Identity Management (PIM), che consente un livello di accesso più elevato per gli utenti 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 un gruppo di utenti, completare i passaggi seguenti:

  1. Nella parte superiore del portale di Azure, cercare e selezionare Microsoft Entra ID.

  2. Nel menu del servizio, in Gestisci, selezionare Gruppi. Selezionare quindi Nuovo gruppo.

  3. Per Tipo di gruppo verificare che sia selezionata l'opzione Sicurezza . Immettere un nome di gruppo, ad esempio myJITGroup. Effettuare eventuali selezioni aggiuntive, quindi selezionare Crea.

    Screenshot che mostra i dettagli per il nuovo gruppo nel portale di Azure.

  4. Viene di nuovo visualizzata la pagina Gruppi. Cercare e selezionare il gruppo appena creato.

  5. Nel menu del servizio, in Attività, selezionare Privileged Identity Management. Selezionare quindi Abilita PIM per questo gruppo.

  6. Selezionare Aggiungi assegnazioni per iniziare a concedere l'accesso.

  7. In Seleziona ruolo scegliere Membro. Selezionare quindi 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.

    Screenshot che mostra come aggiungere assegnazioni nel portale di Azure.

  8. Scegliere un tipo di assegnazione Attivo, selezionare la durata desiderata e fornire una giustificazione. Quando si è pronti per continuare, selezionare Assegna.

    Screenshot che mostra le proprietà di assegnazione nel portale di Azure.

Per altre informazioni su questi passaggi e opzioni, vedere Assegnare l'idoneità per un gruppo in Privileged Identity Management.

Dopo aver eseguito le assegnazioni, verificare che l'accesso just-in-time funzioni accedendo al cluster. Ad esempio, utilizzare 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