Konfigurera arbetsbelastningsidentitet i ett AKS Edge Essentials kluster (förhandsversion)

Azure Kubernetes Service (AKS) Edge Essentials är en lokal Kubernetes-implementering av Azure Kubernetes Service (AKS) som automatiserar körningen av containerbaserade program i stor skala. I den här artikeln beskrivs hur du utför följande uppgifter:

  • Skapa ett Kubernetes-tjänstkonto och binda det till den hanterade Azure-identiteten.
  • Skapa en federerad autentiseringsuppgift för den hanterade identiteten för att lita på OIDC-utfärdaren.
  • Distribuera ditt program.
  • Exempel: Bevilja en pod i klustret åtkomst till hemligheter i ett Azure-nyckelvalv.

För en översikt av identitetsfederation för arbetsbelastningar, se Identitetsfederation för arbetsbelastningar i Azure Arc-aktiverade Kubernetes (förhandsversion).

Important

De här förhandsversionsfunktionerna är tillgängliga via självbetjäning och opt-in. Förhandsversioner tillhandahålls "i befintligt skick" och "i mån av tillgång," och de är undantagna från servicenivåavtal och begränsad garanti. Azure Kubernetes Service Edge Essentials förhandsversioner omfattas delvis av kundsupport efter bästa förmåga.

Note

I den här offentliga förhandsversionen gör AKS Edge Essentials att du kan aktivera arbetsbelastningsidentitet under den första distributionen av Azure IoT Operations snabbstartsskript. Den här funktionen är inte tillgänglig för andra AKS Edge Essentials scenarier.

Förutsättningar

Innan du använder arbetsbelastningsidentitetsfederation för ett AKS Edge Essentials kluster måste du distribuera snabbstartsskriptet Azure IoT Åtgärd enligt beskrivningen i Skapa och konfigurera ett AKS Edge Essentials kluster som kan köra Azure IoT Operations. Skriptet aktiverar automatiskt funktionen för arbetsbelastningsidentitetsfederation i AKS Edge Essentials klustret.

När du har distribuerat AKS Edge Essentials klustret kan du använda följande kommando för att kontrollera statusen för arbetsbelastningsidentitetstillägget:

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

I Azure-portalen kan du visa tillägget wiextension under avsnittet Properties i kubernetes-klustret.

Exportera miljövariabler

För att förenkla stegen för att konfigurera de identiteter som krävs definierar följande steg miljövariabler som refereras i exemplen i den här artikeln. Kom ihåg att ersätta de värden som visas med dina egna värden:

$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"

Spara OIDC-utfärdarens URL till en miljövariabel

Kör följande kommando för att hämta url:en för OIDC-utfärdaren och spara den i en miljövariabel:

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

Steg 1: Skapa ett Kubernetes-tjänstkonto och binda det till den Azure hanterade identiteten

Anropa först kommandot az identity create för att skapa en hanterad identitet:

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

Skapa sedan variabler för den hanterade identitetens klient-ID:

$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)

Skapa ett Kubernetes-tjänstkonto

Skapa ett Kubernetes-tjänstkonto och kommentera det med klient-ID:t för den hanterade identitet som du skapade i föregående steg. Kopiera och klistra in följande Azure CLI kommandon:

$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 -

Följande utdata visar den arbetsbelastningsidentitet som har skapats framgångsrikt:

serviceaccount/workload-identity-sa created

Steg 2: Skapa en federerad autentiseringsuppgift för den hanterade identiteten för att lita på OIDC-utfärdaren

För att skapa den federerade identitetsuppgiften mellan den hanterade identiteten, tjänstkontots utfärdare och entiteten, använd kommandot az identity federated-credential create. Mer information om federerade identitetsautentiseringsuppgifter i Microsoft Entra finns i Översikt över federerade identitetsautentiseringsuppgifter i 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

Note

När du har lagt till en federerad identitetsautentiseringsuppgift tar det några sekunder att sprida. Tokenbegäranden som görs omedelbart efteråt kan misslyckas tills cachen uppdateras. Du kan förhindra det här problemet genom att lägga till en kort fördröjning när du har skapat den federerade identitetsautentiseringsuppgiften.

Steg 3: Distribuera ditt program

När du distribuerar programpoddar bör manifestet referera till tjänstkontot som skapades i steget Skapa Kubernetes-tjänstkonto . Följande manifest visar hur du refererar till kontot, särskilt metadata\namespace egenskaperna och spec\serviceAccountName . Se till att ange en avbildning för image och ett containernamn för 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 - 

Important

Kontrollera att programpoddarna som använder arbetsbelastningsidentiteten innehåller etiketten azure.workload.identity/use: "true" i poddspecifikationen. Annars misslyckas poddarna när de startas om.

Exempel: Bevilja behörigheter för åtkomst till Azure Key Vault

Anvisningarna i det här steget beskriver hur du kommer åt hemligheter, nycklar eller certifikat i ett Azure-nyckelvalv från podden. Exemplen i det här avsnittet konfigurerar åtkomst till hemligheter i nyckelvalvet för arbetsbelastningsidentiteten, men du kan utföra liknande steg för att konfigurera åtkomst till nycklar eller certifikat.

I följande exempel visas hur du använder azure-behörighetsmodellen för rollbaserad åtkomstkontroll (Azure RBAC) för att ge podden åtkomst till nyckelvalvet. Mer information om Azure RBAC-behörighetsmodellen för Azure Key Vault finns i Bevilja behörighet till program för att få åtkomst till ett Azure-nyckelvalv med hjälp av Azure RBAC.

  1. Skapa ett nyckelvalv med rensningsskydd och RBAC-auktorisering aktiverat. Du kan också använda ett befintligt nyckelvalv om det är konfigurerat för både rensningsskydd och RBAC-auktorisering:

    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. Tilldela rollen RBAC Key Vault Secrets Officer till dig själv så att du kan skapa en hemlighet i det nya nyckelvalvet. Nya rolltilldelningar kan ta upp till fem minuter att sprida och uppdateras av auktoriseringsservern.

    az role assignment create --assignee-object-id $MSIPrincipalId --role "Key Vault Secrets Officer" --scope $KVId --assignee-principal-type ServicePrincipal
    
  3. Skapa en hemlighet i nyckelvalvet:

    az keyvault secret set --vault-name $KVName --name $KVSecretName --value "Hello!"
    
  4. Tilldela rollen Key Vault Secrets User till den användartilldelade hanterade identiteten som du skapade tidigare. Det här steget ger den hanterade identiteten behörighet att läsa konfidentiell information från nyckelvalvet.

    az role assignment create --assignee-object-id $MSIPrincipalId --role "Key Vault Secrets User" --scope $KVId --assignee-principal-type ServicePrincipal
    
  5. Skapa en miljövariabel för nyckelvalvs-URL:en:

    $KVUrl=$(az keyvault show --resource-group $resource_group_name --name $KVName --query properties.vaultUri --output tsv)
    
  6. Distribuera en pod som refererar till tjänstekontot och nyckelvalv-URL:en.

    $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 -
    

Nästa steg

I den här artikeln beskrivs hur du konfigurerar en arbetslastidentitet för att förbereda programarbetslaster att autentisera med dessa uppgifter. Nu är du redo att distribuera ditt program och konfigurera det så att det använder arbetsbelastningsidentiteten med den senaste versionen av Azure Identity-klientbiblioteket.