Dela via


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 podd i klustret åtkomst till hemligheter i ett Azure-nyckelvalv.

En konceptuell översikt över arbetsbelastningsidentitetsfederation finns i Arbetsbelastningsidentitetsfederation i Azure Arc-aktiverade Kubernetes (förhandsversion).

Viktigt!

De här förhandsversionsfunktionerna är tillgängliga via självbetjäning och opt-in. Förhandsversioner tillhandahålls "som är" och "som tillgängliga", och de undantas från serviceavtalen och den begränsade garantin. Förhandsversioner av Azure Kubernetes Service Edge Essentials omfattas delvis av kundsupport på bästa sätt.

Kommentar

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-snabbstartsskriptet. 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 för Azure IoT Operation 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 Portal kan du visa wiextension tillägget under avsnittet Egenskaper i ditt Kubernetes-kluster.

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 hanterade Azure-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:

serviceaccount/workload-identity-sa created

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

Om du vill skapa den federerade identitetsautentiseringsuppgiften mellan den hanterade identiteten, utfärdaren av tjänstkontot och ämnet anropar du kommandot az identity federated-credential create . Mer information om federerade identitetsuppgifter 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

Kommentar

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 - 

Viktigt!

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 å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 hemligheter 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 podd som refererar till tjänstkontot och key vault-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 konfigurerade du den att använda en arbetsbelastningsidentitet inför programarbetsbelastningar för att autentisera med den autentiseringsuppgiften. 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.