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

  • Articolo

I tipi di oggetto Kubernetes ClusterRoleBinding e RoleBinding consentono di definire l'autorizzazione in Kubernetes in modo nativo. Usando questa funzionalità, è possibile usare l'ID e le assegnazioni di ruolo di Microsoft Entra 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.

Importante

Le funzionalità di anteprima di Kubernetes abilitate per Azure Arc sono disponibili in base al consenso esplicito self-service. Le anteprime vengono fornite "così com'è" e "come disponibili" e vengono escluse dai contratti di servizio e dalla garanzia limitata. Le anteprime di Kubernetes abilitate per Azure Arc sono parzialmente coperte dal supporto tecnico per i clienti in modo ottimale.

Prerequisiti

  • Installare o aggiornare l'interfaccia della riga di comando di Azure alla versione più recente.

  • Installare la versione più recente dell'estensione dell'interfaccia della riga di comando di connectedk8s Azure:

    az extension add --name connectedk8s

    Se l'estensione connectedk8s è già installata, è possibile aggiornarla alla versione più recente usando il comando seguente:

    az extension update --name connectedk8s

  • Connettere un cluster Kubernetes esistente abilitato per Azure Arc:

Nota

Non è possibile configurare questa funzionalità per Red Hat OpenShift o per le offerte Kubernetes gestite di provider di servizi cloud come il servizio Elastic Kubernetes o il motore Google Kubernetes in cui l'utente non ha accesso al server API del cluster. Per i cluster servizio Azure Kubernetes (servizio Azure Kubernetes), questa funzionalità è disponibile in modo nativo e non richiede che il cluster del servizio Azure Kubernetes sia connesso ad Azure Arc.

Configurare le applicazioni Microsoft Entra

Creare un'applicazione server

  1. Creare una nuova applicazione Microsoft Entra e ottenere il relativo appId valore. Questo valore viene usato nei passaggi successivi come serverApplicationId.

    CLUSTER_NAME="<name-of-arc-connected-cluster>"
TENANT_ID="<tenant>"
SERVER_UNIQUE_SUFFIX="<identifier_suffix>"
SERVER_APP_ID=$(az ad app create --display-name "${CLUSTER_NAME}Server" --identifier-uris "api://${TENANT_ID}/${SERVER_UNIQUE_SUFFIX}" --query appId -o tsv)
echo $SERVER_APP_ID

  2. Per concedere le autorizzazioni API "Accedi e leggi profilo utente" all'applicazione server, copiare il codice JSON e salvarlo in un file denominato oauth2-permissions.json:

    {
    "oauth2PermissionScopes": [
        {
            "adminConsentDescription": "Sign in and read user profile",
            "adminConsentDisplayName": "Sign in and read user profile",
            "id": "<paste_the_SERVER_APP_ID>",
            "isEnabled": true,
            "type": "User",
            "userConsentDescription": "Sign in and read user profile",
            "userConsentDisplayName": "Sign in and read user profile",
            "value": "User.Read"
        }
    ]
}

  3. Aggiornare le attestazioni di appartenenza al gruppo dell'applicazione. Eseguire i comandi nella stessa directory del oauth2-permissions.json file. Il controllo degli accessi in base al ruolo per Kubernetes abilitato per Azure Arc deve essere impostato su AzureADMyOrg:signInAudience

    az ad app update --id "${SERVER_APP_ID}" --set groupMembershipClaims=All
az ad app update --id ${SERVER_APP_ID} --set  api=@oauth2-permissions.json
az ad app update --id ${SERVER_APP_ID} --set  signInAudience=AzureADMyOrg
SERVER_OBJECT_ID=$(az ad app show --id "${SERVER_APP_ID}" --query "id" -o tsv)
az rest --method PATCH --headers "Content-Type=application/json" --uri https://graph.microsoft.com/v1.0/applications/${SERVER_OBJECT_ID}/ --body '{"api":{"requestedAccessTokenVersion": 1}}'

  4. Creare un'entità servizio e ottenere il relativo password valore di campo. Questo valore è necessario in un secondo momento, come serverApplicationSecret quando si abilita questa funzionalità nel cluster. Questo segreto è valido per un anno per impostazione predefinita e dovrà essere ruotato dopo tale anno. Per impostare una durata di scadenza personalizzata, usare az ad sp credential reset:

    az ad sp create --id "${SERVER_APP_ID}"
SERVER_APP_SECRET=$(az ad sp credential reset --id "${SERVER_APP_ID}"  --query password -o tsv)

  5. Concedere le autorizzazioni API "Accesso e lettura profilo utente" all'applicazione usando az ad app permission:

    az ad app permission add --id "${SERVER_APP_ID}" --api 00000003-0000-0000-c000-000000000000 --api-permissions e1fe6dd8-ba31-4d61-89e7-88639da4683d=Scope
az ad app permission grant --id "${SERVER_APP_ID}" --api 00000003-0000-0000-c000-000000000000 --scope User.Read

    Nota

    Un amministratore di applicazioni di Azure deve eseguire questo passaggio.

    Per l'utilizzo di questa funzionalità nell'ambiente di produzione, è consigliabile creare un'applicazione server diversa per ogni cluster.

Creare un'applicazione client

  1. Creare una nuova applicazione Microsoft Entra e ottenere il relativo appId valore. Questo valore viene usato nei passaggi successivi come clientApplicationId.

    CLIENT_UNIQUE_SUFFIX="<identifier_suffix>" 
CLIENT_APP_ID=$(az ad app create --display-name "${CLUSTER_NAME}Client" --is-fallback-public-client --public-client-redirect-uris "api://${TENANT_ID}/${CLIENT_UNIQUE_SUFFIX}" --query appId -o tsv)
echo $CLIENT_APP_ID

  2. Creare un'entità servizio per questa applicazione client:

    az ad sp create --id "${CLIENT_APP_ID}"

  3. Ottenere il oAuthPermissionId valore per l'applicazione server:

        az ad app show --id "${SERVER_APP_ID}" --query "api.oauth2PermissionScopes[0].id" -o tsv

  4. Concedere le autorizzazioni necessarie per l'applicazione client. Il controllo degli accessi in base al ruolo per Kubernetes abilitato per Azure Arc deve essere impostato su AzureADMyOrg:signInAudience

        az ad app permission add --id "${CLIENT_APP_ID}" --api "${SERVER_APP_ID}" --api-permissions <oAuthPermissionId>=Scope
    RESOURCE_APP_ID=$(az ad app show --id "${CLIENT_APP_ID}"  --query "requiredResourceAccess[0].resourceAppId" -o tsv)
    az ad app permission grant --id "${CLIENT_APP_ID}" --api "${RESOURCE_APP_ID}" --scope User.Read
    az ad app update --id ${CLIENT_APP_ID} --set  signInAudience=AzureADMyOrg
    CLIENT_OBJECT_ID=$(az ad app show --id "${CLIENT_APP_ID}" --query "id" -o tsv)
    az rest --method PATCH --headers "Content-Type=application/json" --uri https://graph.microsoft.com/v1.0/applications/${CLIENT_OBJECT_ID}/ --body '{"api":{"requestedAccessTokenVersion": 1}}'

Creare un'assegnazione di ruolo per un'applicazione del server

L'applicazione server necessita delle Microsoft.Authorization/*/read autorizzazioni in modo che possa confermare che l'utente che effettua la richiesta sia autorizzato negli oggetti Kubernetes inclusi nella richiesta.

  1. Creare un file denominato accessCheck.json con il contenuto seguente:

    {
"Name": "Read authorization",
"IsCustom": true,
"Description": "Read authorization",
"Actions": ["Microsoft.Authorization/*/read"],
"NotActions": [],
"DataActions": [],
"NotDataActions": [],
"AssignableScopes": [
  "/subscriptions/<subscription-id>"
  ]
}

    Sostituire <subscription-id> con l'ID sottoscrizione effettivo.

  2. Eseguire il comando seguente per creare il nuovo ruolo personalizzato:

    ROLE_ID=$(az role definition create --role-definition ./accessCheck.json --query id -o tsv)

  3. Creare un'assegnazione di ruolo nell'applicazione server come assignee usando il ruolo creato:

    az role assignment create --role "${ROLE_ID}" --assignee "${SERVER_APP_ID}" --scope /subscriptions/<subscription-id>

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

Abilitare il controllo degli accessi in base al ruolo di Azure nel cluster Kubernetes abilitato per Azure Arc eseguendo il comando seguente:

az connectedk8s enable-features -n <clusterName> -g <resourceGroupName> --features azure-rbac --app-id "${SERVER_APP_ID}" --app-secret "${SERVER_APP_SECRET}"

Nota

Prima di eseguire il comando precedente, assicurarsi che il kubeconfig file nel computer punti al cluster in cui si abiliterà la funzionalità 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, messaggi di posta elettronica e connessioni OpenID sottoposti a controlli di autorizzazione usando oggetti e RoleBinding nativi ClusterRoleBinding kubernetes anziché il controllo degli accessi in base al ruolo di Azure.

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

  1. Eseguire la connessione SSH in ogni nodo master del cluster e seguire questa procedura:

    Se si kube-apiserver tratta di un pod statico:

    1. Il azure-arc-guard-manifests segreto nello spazio dei kube-system nomi contiene due file: guard-authn-webhook.yaml e guard-authz-webhook.yaml. Copiare questi file nella /etc/guard directory 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 apiserver manifesto in modalità di modifica:

      sudo vi /etc/kubernetes/manifests/kube-apiserver.yaml

    3. Aggiungere la specifica seguente in volumes:

      - name: azure-rbac
    hostPath:
    path: /etc/guard
    type: Directory

    4. Aggiungere la specifica seguente in volumeMounts:

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

    Se non kube-apiserver è un pod statico:

    1. Aprire il apiserver manifesto 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 seguenti apiserver :

    - --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 è versione 1.19.0 o successiva, è necessario impostare anche l'argomento seguente apiserver :

    - --authentication-token-webhook-version=v1

  3. Salvare e chiudere l'editor per aggiornare il apiserver pod.

Cluster creato tramite l'API cluster

  1. Copiare il segreto guard 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 namespace campo 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 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"

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

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

    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 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 Kubernetes 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é read l'autorizzazione per i segreti consente l'accesso alle ServiceAccount credenziali nello spazio dei nomi. Queste credenziali a loro volta consentono l'accesso all'API tramite tale ServiceAccount valore (una forma di escalation dei privilegi).
Azure Arc Kubernetes Writer 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 valore nello spazio dei nomi, in modo che possa essere usato per ottenere i livelli di accesso api di qualsiasi ServiceAccount valore nello spazio dei nomi.
Amministrazione di Azure Arc Kubernetes Consente l'accesso amministratore. Deve essere concesso all'interno di uno spazio dei nomi tramite RoleBinding. Se lo 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.
Amministrazione del cluster Azure Arc Kubernetes Consente all'utente con privilegi avanzati di eseguire qualsiasi azione su qualsiasi risorsa. Quando lo 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 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 può AZURE-AD-ENTITY-ID essere un nome utente (ad esempio, testuser@mytenant.onmicrosoft.com) o anche il valore di un'entità appId 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 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 di ruolo.

Copiare l'oggetto JSON seguente in un file denominato custom-role.json. Sostituire il <subscription-id> segnaposto con l'ID 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>"
    ]
}

  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 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 accedere al cluster:

  • Si usa la funzionalità Connessione 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 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.

  1. Eseguire il comando seguente per impostare le credenziali per l'utente:

    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 contextsverificare 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 della modalità di configurazione in userconfig>:

    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 di kubectl eseguire un comando esterno per ricevere le credenziali utente da inviare a apiserver. A partire da Kubernetes versione 1.26, il plug-in di autorizzazione di Azure predefinito non è più incluso in client-go e kubectl. Con le versioni successive, per usare il plug-in exec per ricevere le credenziali utente, è necessario usare Azure Kubelogin, un client-go plug-in credenziali (exec) che implementa l'autenticazione di Azure.

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

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

Inviare richieste al cluster

  1. Eseguire qualsiasi kubectl comando. 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 nella console. Copiare e incollare il codice nel terminale nella richiesta di input di autenticazione del dispositivo.

  4. Immettere il nome utente (testuser@mytenant.onmicrosoft.com) e la password associata.

  5. 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 avere accesso 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 Microsoft Entra è una funzionalità Microsoft Entra ID P2.

Per creare un esempio di criteri di accesso condizionale da usare con il cluster:

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

  2. Nel menu per Microsoft Entra ID sul lato sinistro selezionare Applicazioni aziendali.

  3. Nel menu per le applicazioni aziendali a sinistra selezionare Accesso condizionale.

  4. Nel menu per l'accesso condizionale a sinistra selezionare Criteri>Nuovo criterio.

    Screenshot showing how to add a conditional access policy in the Azure portal.

  5. Immettere un nome per il criterio, ad esempio arc-k8s-policy.

  6. Selezionare Utenti e gruppi. In Includi scegliere Seleziona utenti e gruppi. Scegliere quindi gli utenti e i gruppi in cui si desidera applicare i criteri. Per questo esempio, scegliere lo stesso gruppo di Microsoft Entra con accesso amministrativo al cluster.

    Screenshot that shows selecting users or groups to apply the Conditional Access policy.

  7. Selezionare Applicazioni cloud o azioni. In Includi scegliere Seleziona app. Cercare quindi e selezionare l'applicazione server creata in precedenza.

    Screenshot showing how to select a server application in the Azure portal.

  8. In Controlli di accesso selezionare Concedi. Selezionare Concedi accesso>Richiedi che il dispositivo sia contrassegnato come conforme.

    Screenshot showing how to allow only compliant devices in the Azure portal.

  9. In Abilita criterio selezionare Su>crea.

    Screenshot showing how to enable a conditional access policy in the Azure portal.

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

kubectl get nodes

Seguire le istruzioni per eseguire di nuovo l'accesso. 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. Eseguire i passaggi indicati di seguito:

  1. Nel portale di Azure passare a Microsoft Entra ID.

  2. Selezionare Applicazioni aziendali. Quindi in Attività selezionare Accessi.

  3. Una voce nella parte superiore mostra Non riuscito per stato e esito positivo per l'accesso condizionale. Selezionare la voce e quindi selezionare Accesso condizionale in Dettagli. Si noti che i criteri di accesso condizionale sono elencati.

    Screenshot showing a failed sign-in entry in the Azure portal.

Configurare l'accesso just-in-time al 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

Microsoft Entra PIM è una funzionalità Microsoft Entra ID P2. Per altre informazioni sugli SKU id di Microsoft Entra, vedere la guida ai prezzi.

Per configurare le richieste di accesso JUST-In-Time per il cluster, completare la procedura seguente:

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

  2. Prendere nota dell'ID tenant. Per il resto di queste istruzioni, si farà riferimento a tale ID come <tenant-id>.

    Screenshot showing Microsoft Entra ID details in the Azure portal.

  3. Nel menu per Microsoft Entra ID sul lato sinistro, in Gestisci selezionare Gruppi>Nuovo gruppo.

  4. Assicurarsi che l'opzione Sicurezza sia selezionata per Tipo di gruppo. Immettere un nome di gruppo, ad esempio myJITGroup. In Ruoli di Microsoft Entra può essere assegnato a questo gruppo (anteprima) selezionare Sì. Infine, selezionare Crea.

    Screenshot showing details for the new group in the Azure portal.

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

    Screenshot showing the object ID for the new group in the Azure portal.

  6. Tornare al portale di Azure, nel menu Attività sul lato sinistro selezionare Accesso con privilegi (anteprima). Selezionare quindi Abilita accesso con privilegi.

    Screenshot showing selections for enabling privileged access in the Azure portal.

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

    Screenshot showing how to add active assignments in the Azure portal.

  8. Selezionare un ruolo 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.

    Screenshot showing how to add assignments in the Azure portal.

  9. Scegliere un tipo di assegnazione Attivo, scegliere 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.

    Screenshot showing assignment properties in the Azure portal.

Dopo aver effettuato le assegnazioni, verificare che l'accesso JUST-In-Time funzioni accedendo al cluster. Ad esempio, usare il kubectl get nodes comando 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

Aggiornare il segreto dell'applicazione server

Se il segreto per l'entità servizio dell'applicazione server è scaduto, sarà necessario ruotarlo.

SERVER_APP_SECRET=$(az ad sp credential reset --name "${SERVER_APP_ID}" --credential-description "ArcSecret" --query password -o tsv)

Aggiornare il segreto nel cluster. Includere tutti i parametri facoltativi configurati quando il comando è stato originariamente eseguito.

az connectedk8s enable-features -n <clusterName> -g <resourceGroupName> --features azure-rbac --app-id "${SERVER_APP_ID}" --app-secret "${SERVER_APP_SECRET}"

Passaggi successivi