Distribuire e configurare la federazione delle identità del carico di lavoro in Kubernetes abilitato per Azure Arc

È possibile abilitare la funzionalità di identità del carico di lavoro in un cluster Kubernetes abilitato per Azure Arc utilizzando l'interfaccia della riga di comando di Azure. Il processo segue questi passaggi generali:

1. Abilitare la funzionalità di identità del carico di lavoro in un cluster Kubernetes abilitato per Arc nuovo o esistente.
2. Creare un'identità gestita (o una registrazione dell'app) e un account del servizio Kubernetes.
3. Configurare l'identità gestita per la federazione dei token.
4. Configurare le annotazioni dell'account del servizio e le etichette dei pod dell'applicazione per utilizzare l'identità del carico di lavoro.
5. Configurare le impostazioni dell'identità del carico di lavoro nel cluster Kubernetes.
6. Disabilitare l'identità del carico di lavoro nel cluster.

Per una panoramica di questa funzionalità, consulta Federazione delle identità del carico di lavoro in Kubernetes con abilitazione Azure Arc.

Prerequisiti

• L'identità del carico di lavoro per i cluster Kubernetes abilitati per Azure Arc supporta le distribuzioni Kubernetes seguenti:
  • Cluster Ubuntu Linux che esegue K3s
  • AKS abilitato da Azure Arc
  • Red Hat OpenShift
  • VMware Tanzu TKGm
  • Servizio Azure Kubernetes in Edge Essentials

Per utilizzare la funzionalità di identità del carico di lavoro, è necessario disporre dell'interfaccia della riga di comando di Azure versione 2.64 o successiva e az connectedk8s la versione 1.10.0 o successiva. Aggiornare la versione interfaccia della riga di comando di Azure prima di aggiornare la versione az connectedk8s. Se si usa Azure Cloud Shell, viene installata la versione più recente di interfaccia della riga di comando di Azure.

Abilitare l'identità del carico di lavoro nel cluster

Seguire i passaggi appropriati per abilitare la funzionalità di identità del carico di lavoro per un nuovo cluster Kubernetes abilitato per Arc o per uno esistente. In entrambi i casi sostituire il nome e il gruppo di risorse con i valori e configurare i parametri in base alle esigenze.

Impostare le variabili di ambiente

Per praticità, gli esempi in questo articolo fanno riferimento alle variabili di ambiente definite nella sezione seguente. Sostituire questi valori con i propri valori:

export RESOURCE_GROUP="myRG"
export LOCATION="eastus"
export CLUSTER_NAME="mycluster"
export SERVICE_ACCOUNT_NAMESPACE="myKubernetesnamespace"
export SERVICE_ACCOUNT_NAME="mysa"
export SUBSCRIPTION="$(az account show --query id --output tsv)"
export USER_ASSIGNED_IDENTITY_NAME="myIdentity"
export FEDERATED_IDENTITY_CREDENTIAL_NAME="myFedIdentity"

Per creare un cluster abilitato per Azure Arc con l'identità del carico di lavoro abilitata, utilizzare il comando seguente:

az connectedk8s connect --name "${CLUSTER_NAME}" --resource-group "${RESOURCE_GROUP}" --enable-oidc-issuer --enable-workload-identity

Per abilitare l'identità del carico di lavoro in un cluster Kubernetes abilitato per Arc esistente, utilizzare il comando update.

az connectedk8s update --name "${CLUSTER_NAME}" --resource-group "${RESOURCE_GROUP}" --enable-oidc-issuer --enable-workload-identity

Recuperare l'URL dell'autorità di certificazione OIDC

Recuperare l'URL dell'autorità emittente OIDC e salvarlo in una variabile di ambiente. Usare questo URL dell'autorità di certificazione nel passaggio seguente.

export OIDC_ISSUER="$(az connectedk8s show --name "${CLUSTER_NAME}" --resource-group "${RESOURCE_GROUP}" \ 
    --query "oidcIssuerProfile.issuerUrl" \  
    --output tsv)"

Per visualizzare la variabile di ambiente, immettere echo ${OIDC_ISSUER}. La variabile di ambiente deve contenere l'URL dell'autorità di certificazione, in modo simile all'esempio seguente:

https://northamerica.oic.prod-arc.azure.com/00000000-0000-0000-0000-000000000000/12345678-1234-1234-1234-123456789123/

Per impostazione predefinita, l'autorità emittente usa l'URL https://{region}.oic.prod-arc.azure.com/{tenant_id}/{uuid}di base , dove il valore per {region} corrisponde alla posizione in cui è stato creato il cluster Kubernetes abilitato per Arc. Il valore {uuid} rappresenta la chiave OIDC (OpenID Connect), che è un GUID non modificabile generato in modo casuale per ogni cluster.

Creare un'identità gestita

Utilizzare il comando az identity create per creare un'identità gestita assegnata dall'utente. Usando l'identità del carico di lavoro, crei una relazione di fiducia tra il token dell'identità gestita assegnata dall'utente e il token dell'account del servizio del cluster Kubernetes.

az identity create \ 
    --name "${USER_ASSIGNED_IDENTITY_NAME}" \
    --resource-group "${RESOURCE_GROUP}" \
    --location "${LOCATION}" \
    --subscription "${SUBSCRIPTION}"

Recuperare l'ID client dell'identità gestita e archiviarlo in una variabile di ambiente.

export USER_ASSIGNED_CLIENT_ID="$(az identity show \ 
    --resource-group "${RESOURCE_GROUP}" \
    --name "${USER_ASSIGNED_IDENTITY_NAME}" \
    --query 'clientId' \
    --output tsv)"

Creare un account del servizio Kubernetes

Creare un account del servizio Kubernetes e annotarlo con l'ID client dell'identità gestita creata nel passaggio precedente. Dopo aver stabilito la relazione di trust tra i due, i token firmati associati all'account del servizio Kubernetes vengono scambiati per un token Microsoft Entra ID.

Applicare il seguente frammento YAML per creare un account del servizio con l'annotazione dell'identità del carico di lavoro aggiunta.

apiVersion: v1 
kind: ServiceAccount 
metadata: 
  annotations: 
    azure.workload.identity/client-id: "${USER_ASSIGNED_CLIENT_ID}" 
  name: "${SERVICE_ACCOUNT_NAME}" 
  namespace: "${SERVICE_ACCOUNT_NAMESPACE}" 

Creare le credenziali dell'identità federata

Utilizzare il az identity federated-credential create comando per creare le credenziali di identità federate tra l'identità gestita, l'autorità di certificazione dell'account del servizio e l'oggetto. Questo passaggio stabilisce la relazione di trust tra il cluster Kubernetes e Microsoft Entra per lo scambio di token. Per altre informazioni sulle credenziali di identità federate in Microsoft Entra, vedere Panoramica delle credenziali di identità federate in Microsoft Entra ID.

az identity federated-credential create \ 
    --name ${FEDERATED_IDENTITY_CREDENTIAL_NAME} \ 
    --identity-name "${USER_ASSIGNED_IDENTITY_NAME}" \ 
    --resource-group "${RESOURCE_GROUP}" \ 
    --issuer "${OIDC_ISSUER}" \ 
    --subject system:serviceaccount:"${SERVICE_ACCOUNT_NAMESPACE}":"${SERVICE_ACCOUNT_NAME}" \ 
    --audience api://AzureADTokenExchange 

Configurare le annotazioni dell'account del servizio e le etichette dei pod

Sono disponibili gli account del servizio e le annotazioni dei pod seguenti per configurare l'identità del carico di lavoro in base ai requisiti dell'applicazione. L'etichetta del pod specificata nella sezione seguente è obbligatoria se si imposta --enable-workload-identity su true.

Annotazioni dell'account del servizio

Tutte le annotazioni dell'account del servizio sono facoltative. Se non si specifica un'annotazione, viene usato il valore predefinito.

Etichette dei pod

Annotazioni dei pod

Tutte le annotazioni dei pod sono facoltative. Se non si specifica un'annotazione, viene usato il valore predefinito.

Configurare le impostazioni dell'identità del carico di lavoro nel cluster Kubernetes

Il server API nel cluster Kubernetes deve essere configurato per rilasciare token dell'account del servizio che includono l'URL dell'autorità di certificazione OIDC accessibile pubblicamente (in modo che Entra sappia dove trovare le chiavi pubbliche per convalidare il token).

Per configurare le impostazioni di identità del carico di lavoro nelle varie distribuzioni kubernetes, seguire questa procedura per completare la configurazione.

Cluster K3s

1. Creare il file di configurazione k3s.

2. Modificare /etc/rancher/k3s/config.yaml per aggiungere queste impostazioni:

      kube-apiserver-arg:  
        - "service-account-issuer=${OIDC_ISSUER}"
        - "service-account-max-token-expiration=24h"
   

3. Salvare config.yaml.

4. Riavviare il server API k3s eseguendo systemctl restart k3s.

   Cambiare spesso le chiavi di accesso dell'account del servizio. Per ulteriori informazioni, consultare Rotazione della chiave di firma dell'account di servizio nei cluster K3s.

Cluster di Red Hat OpenShift

1. Modificare la configurazione di autenticazione per il cluster:

   1. Aprire la configurazione di autenticazione per il cluster:

      kubectl edit authentications cluster
      

   2. Individuare la sezione relativa al valore dell'emittente e aggiornarla.

   3. Salvare il file e uscire dall'editor.

2. Riavviare le distribuzioni pertinenti nei namespace necessari:

   kubectl rollout restart deployment -n azure-arc
   kubectl rollout restart deployment -n arc-workload-identity
   

3. In alternativa, applicare le modifiche tramite un comando patch per aggiornare il valore dell'emittente senza modifiche manuali.

   kubectl patch authentication cluster \ 
   --type merge \ 
   -p '{"spec":{"serviceAccountIssuer":"<NEW_ISSUER_VALUE>"}}' \ 
   --kubeconfig /etc/kubernetes/admin.conf
   

4. Confermare le modifiche:

   1. Verificare il valore dell'emittente:

      kubectl get authentications cluster
      

   2. Controllare lo stato delle distribuzioni riavviate:

      kubectl get pods -n azure-arc
      kubectl get pods -n arc-workload-identity 
      

Cluster TKGm VMware Tanzu

1. Connettere il cluster ad Azure Arc con l'identità del workload attivata:

   1. Abilitare l'identità del carico di lavoro durante il processo di connessione Arc.
   2. Dopo la connessione, recuperare l'URL del fornitore OIDC.

2. Modificare la configurazione del cluster del carico di lavoro:

   1. Passare al contesto del cluster di gestione:

      kubectl config use-context mgmt-cluster-admin@mgmt-cluster 
      

   2. Visualizzare il cluster:

      kubectl get cluster
      

   3. Modificare la configurazione del cluster di destinazione:

      1. Cercare apiServerExtraArgs
      2. Se il valore esiste, aggiornarlo per includere l'URL dell'autorità di certificazione.
      3. Se non esiste, aggiungerlo sotto spec:topology:variables come mostrato:

      name: apiServerExtraArgs
      value:
        - 'service-account-issuer=<OIDC_ISSUER_URL>'
      

3. Tornare al cluster del carico di lavoro:

   kubectl config use-context <WORKLOAD_CLUSTER_CONTEXT>
   

4. Creare un account del servizio e un token di test:

   1. Creare un token per l'account del servizio:

      kubectl create token <SERVICE_ACCOUNT_NAME> -n <NAMESPACE>
      

   2. Verificare che l'autorità emittente del token corrisponda all'URL OIDC previsto.

5. Riavviare la distribuzione per applicare le modifiche:

   kubectl rollout restart deployment -n azure-arc
   

Ruotare la chiave di firma dell'account del servizio nei cluster K3s

Per i cluster K3s di cui viene eseguito l'onboarding in Azure Arc con la federazione delle identità del carico di lavoro abilitata, la rotazione della chiave dell'emittente dell'account del servizio è un'operazione di sicurezza importante. La rotazione delle chiavi è necessaria per l'igiene della sicurezza e potrebbe essere necessaria come parte della correzione degli eventi imprevisti.

La chiave emittente dell'account del servizio (service.key) è una chiave RSA privata usata per firmare i token dell'account del servizio. Quando si ruota la chiave, mantenere la chiave precedente nel file in modo che i token esistenti rimangano validi. Entrambe le chiavi devono coesistere finché tutti i token esistenti scadono o vengono aggiornati (almeno 24 ore).

Come procedura consigliata, è consigliabile ruotare le chiavi dell'emittente dell'account di servizio almeno una volta ogni tre mesi.

Prerequisiti

Per ruotare la chiave dell'emittente dell'account del servizio in un cluster K3s, assicurarsi di avere i seguenti prerequisiti:

• Cluster K3s integrato in Azure Arc con federazione delle identità dei carichi di lavoro abilitata
• sudo accesso radice nel nodo del server K3s
• OpenSSL 3 installato nel nodo
• Familiarità con l'interfaccia della riga di comando del certificato K3s

Generare una nuova chiave ed eseguire la rotazione

Eseguire i comandi seguenti nel nodo del server K3s per generare una nuova chiave e prepararla per la rotazione:

# Create a temporary directory for staging
mkdir -p /opt/k3s/server/tls

# Check OpenSSL version (OpenSSL 3.x requires -traditional flag)
openssl version | grep -qF 'OpenSSL 3' && OPENSSL_GENRSA_FLAGS=-traditional

# Generate a new RSA key
openssl genrsa ${OPENSSL_GENRSA_FLAGS:-} -out /opt/k3s/server/tls/service.key 2048

# Append the existing (old) key to preserve validity of current tokens
cat /var/lib/rancher/k3s/server/tls/service.key >> /opt/k3s/server/tls/service.key

# Load the updated key into the K3s datastore
k3s certificate rotate-ca --path=/opt/k3s/server

# Restart K3s to apply
sudo systemctl restart k3s

Dopo il riavvio:

• I nuovi token vengono coniati usando la nuova chiave.
• I token esistenti rimangono validi perché la chiave precedente è ancora presente nel file.

Per ulteriori dettagli sulla rotazione della chiave dell'emittente dell'account del servizio, vedere Rotazione della chiave dell'emittente dell'account del servizio nella documentazione di K3s.

Rimuovere la chiave emittente dell'account di servizio precedente

Eseguire i comandi seguenti nel nodo del server K3s per rimuovere la chiave precedente in modo sicuro:

# Backup the current key file
sudo cp /var/lib/rancher/k3s/server/tls/service.key /var/lib/rancher/k3s/server/tls/service.key.bak.$(date +%s)

# Split the keys into individual files
csplit -f /tmp/service-key- /var/lib/rancher/k3s/server/tls/service.key '/BEGIN RSA PRIVATE KEY/' '{*}'

# Copy only the new key (first key in the file) to staging
sudo cp /tmp/service-key-01 /opt/k3s/server/tls/service.key

# Load the updated key into the datastore
k3s certificate rotate-ca --path=/opt/k3s/server

# Restart K3s
sudo systemctl restart k3s

Disabilitare l'identità del carico di lavoro

Per disabilitare la funzionalità di identità del carico di lavoro in un cluster Kubernetes abilitato per Azure Arc, eseguire il comando seguente:

az connectedk8s update \
    --resource-group "${RESOURCE_GROUP}" \
    --name "${CLUSTER_NAME}" \
    --disable-workload-identity

Passaggi successivi

• Esplorare un esempio per configurare un'applicazione per l'uso dell'identità del carico di lavoro.
• Aiuta a proteggere il tuo cluster in altri modi seguendo le indicazioni riportate nel manuale di sicurezza per Kubernetes abilitato con Azure Arc.