Configurare l'identità del carico di lavoro in un cluster Azure Kubernetes Edge Essentials (anteprima)

Servizio Azure Kubernetes (AKS) Edge Essentials è un'implementazione kubernetes locale di servizio Azure Kubernetes (servizio Azure Kubernetes) che automatizza l'esecuzione di applicazioni in contenitori su larga scala. Questo articolo descrive come eseguire le attività seguenti:

• Creare un account del servizio Kubernetes e associarlo all'identità gestita di Azure.
• Creare una credenziale federata nell'identità gestita per considerare attendibile l'emittente OIDC.
• Distribuire l'applicazione.
• Esempio: concedere a un pod nel cluster l'accesso ai segreti in un insieme di credenziali delle chiavi di Azure.

Per una panoramica concettuale della federazione delle identità del carico di lavoro, vedere Federazione delle identità del carico di lavoro in Kubernetes abilitato per Azure Arc (anteprima).

Prerequisiti

Prima di usare la federazione delle identità del carico di lavoro per un cluster Azure Kubernetes Edge Essentials, è necessario distribuire lo script di avvio rapido dell'operazione IoT di Azure come descritto in Creare e configurare un cluster Azure Kubernetes Edge Essentials in grado di eseguire operazioni IoT di Azure. Lo script abilita automaticamente la funzionalità di federazione delle identità del carico di lavoro nel cluster Azure Kubernetes Edge Essentials.

Dopo aver distribuito il cluster Azure Kubernetes Edge Essentials, è possibile usare il comando seguente per controllare lo stato dell'estensione dell'identità del carico di lavoro:

az connectedk8s show -n $aks_cluster_name -g $resource_group_name

# agentState = "Succeeded" 
"agentPublicKeyCertificate": "", 
  "agentVersion": "1.21.10", 
  "arcAgentProfile": { 
    "agentAutoUpgrade": "Enabled", 
    "agentErrors": [], 
    "agentState": "Succeeded", 
    "desiredAgentVersion": "", 
    "systemComponents": null 

# oidcIssuerProfile "enabled": true and "issuerUrl" present 
"oidcIssuerProfile": { 
    "enabled": true, 
    "issuerUrl": "https://oidcdiscovery-{location}-endpoint-1111111111111111.000.azurefd.net/00000000-0000-0000-0000-000000000000/11111111-1111-1111-1111-111111111111/", 

# workloadIdentity "enabled": true 
"securityProfile": { 
    "workloadIdentity": { 
      "enabled": true

Nella portale di Azure è possibile visualizzare l'estensione wiextension nella sezione Proprietà del cluster Kubernetes.

Esportare le variabili di ambiente

Per semplificare la procedura per configurare le identità necessarie, i passaggi seguenti definiscono le variabili di ambiente a cui si fa riferimento negli esempi di questo articolo. Ricordarsi di sostituire i valori visualizzati con i propri valori:

$AZSubscriptionID = "00000000-0000-0000-0000-000000000000" 
$Location = "westeurope" 
$resource_group_name = "myResourceGroup" 

$aks_cluster_name = "myAKSCluster" 

$SERVICE_ACCOUNT_NAMESPACE = "default" 
$SERVICE_ACCOUNT_NAME = "workload-identity-sa" 

$FedIdCredentialName = "myFedIdentity" 
$MSIName = "myIdentity" 

# Include these variables to access key vault secrets from a pod in the cluster. 
$KVName = "KV-workload-id" 
$KVSecretName= "KV-secret"

Salvare l'URL dell'autorità emittente OIDC in una variabile di ambiente

Per ottenere l'URL dell'autorità emittente OIDC e salvarlo in una variabile di ambiente, eseguire il comando seguente:

$SERVICE_ACCOUNT_ISSUER =$(az connectedk8s show --n $aks_cluster_name --resource-group $resource_group_name --query "oidcIssuerProfile.issuerUrl" --output tsv)

Passaggio 1: Creare un account del servizio Kubernetes e associarlo all'identità gestita di Azure

Chiamare prima di tutto il comando az identity create per creare un'identità gestita:

az identity create --name $MSIName --resource-group $resource_group_name --location $Location --subscription $AZSubscriptionID

Creare quindi variabili per l'ID client dell'identità gestita:

$MSIId=$(az identity show --resource-group $resource_group_name --name $MSIName --query 'clientId' --output tsv)  
$MSIPrincipalId=$(az identity show --resource-group $resource_group_name --name $MSIName --query 'principalId' --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. Copiare e incollare i comandi seguenti dell'interfaccia della riga di comando di Azure:

$yaml = @" 
apiVersion: v1 
kind: ServiceAccount 
metadata: 
  annotations: 
    azure.workload.identity/client-id: $MSIId 
  name: $SERVICE_ACCOUNT_NAME 
  namespace: $SERVICE_ACCOUNT_NAMESPACE 
"@ 

# Replace variables within the YAML content 
$yaml = $yaml -replace '\$MSIId', $MSIId ` 
              -replace '\$SERVICE_ACCOUNT_NAME', $SERVICE_ACCOUNT_NAME ` 
              -replace '\$SERVICE_ACCOUNT_NAMESPACE', $SERVICE_ACCOUNT_NAMESPACE 

# Apply the YAML content to Kubernetes 
$yaml | kubectl apply -f -

L'output seguente mostra l'identità del carico di lavoro creata correttamente:

serviceaccount/workload-identity-sa created

Passaggio 2: Creare una credenziale federata nell'identità gestita per considerare attendibile l'emittente OIDC

Per creare le credenziali dell'identità federata tra l'identità gestita, l'autorità emittente dell'account del servizio e l'oggetto, chiamare il comando az identity federated-credential create . Per altre informazioni sulle credenziali di identità federate in Microsoft Entra, vedere Panoramica delle credenziali di identità federate in Microsoft Entra ID.

# Create a federated credential 
az identity federated-credential create --name $FedIdCredentialName --identity-name $MSIName --resource-group $resource_group_name --issuer $SERVICE_ACCOUNT_ISSUER --subject "system:serviceaccount:${SERVICE_ACCOUNT_NAMESPACE}:${SERVICE_ACCOUNT_NAME}" 

# Show the federated credential 
az identity federated-credential show --name $FedIdCredentialName --resource-group $resource_group_name --identity-name $MSIName

Passaggio 3: Distribuire l'applicazione

Quando si distribuiscono i pod dell'applicazione, il manifesto deve fare riferimento all'account del servizio creato nel passaggio Creare l'account del servizio Kubernetes. Il manifesto seguente mostra come fare riferimento all'account, in particolare le metadata\namespace proprietà e spec\serviceAccountName . Assicurarsi di specificare un'immagine per image e un nome del contenitore per containerName:

$image = "<image>"  # Replace <image> with the actual image name 
$containerName = "<containerName>"  # Replace <containerName> with the actual container name 

$yaml = @" 
apiVersion: v1 
kind: Pod 
metadata: 
  name: sample-quick-start 
  namespace: $SERVICE_ACCOUNT_NAMESPACE 
  labels: 
    azure.workload.identity/use: "true" # Required. Only pods with this label can use workload identity. 
spec: 
  serviceAccountName: $SERVICE_ACCOUNT_NAME 
  containers: 
    - image: $image 
      name: $containerName 
"@ 

# Replace variables within the YAML content 
$yaml = $yaml -replace '\$SERVICE_ACCOUNT_NAMESPACE', $SERVICE_ACCOUNT_NAMESPACE ` 
                -replace '\$SERVICE_ACCOUNT_NAME', $SERVICE_ACCOUNT_NAME 

# Apply the YAML configuration 
$yaml | kubectl apply -f - 

Esempio: Concedere le autorizzazioni per accedere ad Azure Key Vault

Le istruzioni in questo passaggio descrivono come accedere a segreti, chiavi o certificati in un insieme di credenziali delle chiavi di Azure dal pod. Gli esempi in questa sezione configurano l'accesso ai segreti in Key Vault per l'identità del carico di lavoro, ma è possibile eseguire passaggi simili per configurare l'accesso a chiavi o certificati.

L'esempio seguente illustra come usare il modello di autorizzazione Controllo degli accessi in base al ruolo di Azure per concedere al pod l'accesso a Key Vault. Per altre informazioni sul modello di autorizzazione Controllo degli accessi in base al ruolo di Azure per Azure Key Vault, vedere Concedere alle applicazioni l'autorizzazione per accedere ad Azure Key Vault usando il controllo degli accessi in base al ruolo di Azure.

1. Creare un'istanza di Key Vault con la protezione dall'eliminazione e l'autorizzazione di Controllo degli accessi in base al ruolo abilitata. È anche possibile usare un'istanza di Key Vault esistente se è configurata sia per la protezione dall'eliminazione che per l'autorizzazione di Controllo degli accessi in base al ruolo:

   az keyvault create --name $KVName --resource-group $resource_group_name --location $Location --enable-purge-protection --enable-rbac-authorization
   
   # retrieve the key vault ID for role assignment
   $KVId=$(az keyvault show --resource-group $resource_group_name --name $KVName --query id --output tsv)
   

2. Assegnare il ruolo Di responsabile dei segreti dell'insieme di credenziali delle chiavi di Controllo degli accessi in base al ruolo a se stessi in modo da poter creare un segreto nel nuovo insieme di credenziali delle chiavi. La propagazione delle nuove assegnazioni di ruolo può richiedere fino a cinque minuti, e possono essere aggiornate dal server di autorizzazione.

   az role assignment create --assignee-object-id $MSIPrincipalId --role "Key Vault Secrets Officer" --scope $KVId --assignee-principal-type ServicePrincipal
   

3. Creare un segreto in Key Vault:

   az keyvault secret set --vault-name $KVName --name $KVSecretName --value "Hello!"
   

4. Assegnare il ruolo Utente dei segreti di Key Vault all'identità gestita assegnata dall'utente creata in precedenza. Questo passaggio concede all'identità gestita l'autorizzazione per leggere i segreti da Key Vault:

   az role assignment create --assignee-object-id $MSIPrincipalId --role "Key Vault Secrets User" --scope $KVId --assignee-principal-type ServicePrincipal
   

5. Creare una variabile di ambiente per l'URL di Key Vault:

   $KVUrl=$(az keyvault show --resource-group $resource_group_name --name $KVName --query properties.vaultUri --output tsv)
   

6. Distribuire un pod che fa riferimento all'account del servizio e all'URL di Key Vault:

   $yaml = @" 
   apiVersion: v1 
   kind: Pod
   metadata:
     name: sample-quick-start
     namespace: $SERVICE_ACCOUNT_NAMESPACE
     labels:
       azure.workload.identity/use: "true"
   spec:
     serviceAccountName: $SERVICE_ACCOUNT_NAME 
     containers:
       - image: ghcr.io/azure/azure-workload-identity/msal-go 
         name: oidc 
         env: 
         - name: KEYVAULT_URL 
           value: $KVUrl 
         - name: SECRET_NAME 
           value: $KVSecretName 
     nodeSelector:
       kubernetes.io/os: linux
   "@
   
   # Replace variables within the YAML content 
   $yaml = $yaml -replace '\$SERVICE_ACCOUNT_NAMESPACE', $SERVICE_ACCOUNT_NAMESPACE ` 
                   -replace '\$SERVICE_ACCOUNT_NAME', $SERVICE_ACCOUNT_NAME ` 
                   -replace '\$KVUrl', $KVUrl ` 
                   -replace '\$KVSecretName', $KVSecretName 
   
   # Apply the YAML configuration
   $yaml | kubectl --kubeconfig $aks_cluster_name apply -f -
   

Passaggi successivi

In questo articolo è stato configurato per usare un'identità del carico di lavoro in preparazione per l'autenticazione dei carichi di lavoro dell'applicazione con tale credenziale. A questo punto è possibile distribuire l'applicazione e configurarla per usare l'identità dei carichi di lavoro con la versione più recente della libreria client Identità di Azure.