Händelser
17 mars 21 - 21 mars 10
Gå med i mötesserien för att skapa skalbara AI-lösningar baserat på verkliga användningsfall med andra utvecklare och experter.
Registrera dig nuDistribuera och konfigurera arbetsbelastningsidentitet på en AKS som aktiveras av Azure Arc-kluster (förhandsversion)
Gäller för: Azure Local, version 23H2
Med arbetsbelastningsidentitetsfederation kan du konfigurera en användartilldelad hanterad identitet eller appregistrering i Microsoft Entra-ID för att lita på token från en extern identitetsprovider (IdP), till exempel Kubernetes, vilket ger åtkomst till resurser som skyddas av Microsoft Entra, till exempel Azure Key Vault eller Azure Blob Storage.
Azure Kubernetes Service (AKS) som aktiveras av Azure Arc är en hanterad Kubernetes-tjänst som gör att du enkelt kan distribuera arbetsbelastningsidentitetsaktiverade Kubernetes-kluster. I den här artikeln beskrivs hur du utför följande uppgifter:
- Skapa ett AKS Arc-kluster med arbetsbelastningsidentitet aktiverat (förhandsversion).
- 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.
För en översikt av identitetsfederation för arbetsbelastningar, se Identitetsfederation för arbetsbelastningar 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. Azure Kubernetes Service, som aktiveras av Förhandsversioner av Azure Arc, omfattas delvis av kundsupport på bästa sätt.
Anteckning
I offentlig förhandsversion stöder AKS på Azure Local version 23H2 aktivering av arbetsbelastningsidentitet när AKS-kluster skapas. Det går dock inte att aktivera arbetsbelastningsidentiteten när klustret har skapats eller inaktiverats efteråt.
Innan du distribuerar ett Kubernetes-kluster med Azure Arc aktiverat måste du ha följande förutsättningar:
- Om du inte har en Azure-prenumeration skapar du ett kostnadsfritt konto innan du börjar.
- Den här artikeln kräver version 1.4.23 eller senare av Azure CLI. Om du använder Azure Cloud Shell är den senaste versionen redan installerad.
För att förenkla stegen för att konfigurera de identiteter som krävs definierar följande kommandon miljövariabler som refereras i exemplen i den här artikeln. Ersätt följande värden med dina egna:
Azure CLI
$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"
# To access key vault secrets from a pod in the cluster, include these variables:
$KVName = "KV-workload-id"
$KVSecretName= "KV-secret"
Börja med att ange din prenumeration som den aktuella aktiva prenumerationen. Kör kommandot az account set med ditt prenumerations-ID:
Azure CLI
az login
az account set -s $AZSubscriptionID
En Azure-resursgrupp är en logisk grupp där Azure-resurser distribueras och hanteras. När du skapar en resursgrupp uppmanas du att ange en plats. Den här platsen är lagringsplatsen för dina resursgruppsmetadata och där dina resurser körs i Azure om du inte anger en annan region när du skapar resurser.
Du kan skapa en resursgrupp med hjälp av kommandot az group create:
Azure CLI
az group create --name $resource_group_name --location $Location
Följande exempelutdata visar hur en resursgrupp har skapats:
JSON
{
"id": "/subscriptions/<guid>/resourceGroups/myResourceGroup",
"location": "westeurope",
"managedBy": null,
"name": "$resource_group_name",
"properties": {
"provisioningState": "Succeeded"
},
"tags": null
}
För att skapa ett AKS Arc-kluster behöver du både $customlocation_ID värdena och $logicnet_Id .
-
$customlocation_ID: Azure Resource Manager-ID för den anpassade platsen. Den anpassade platsen konfigureras under distributionen av Azure Local-kluster, version 23H2. Infrastrukturadministratören bör ge dig Resource Manager-ID:t för den anpassade platsen. Du kan också hämta Resource Manager-ID:t med ,$customlocation_ID = $(az customlocation show --name "<your-custom-location-name>" --resource-group $resource_group_name --query "id" -o tsv)om infrastrukturadministratören tillhandahåller ett anpassat platsnamn och resursgruppsnamn. -
$logicnet_Id: Azure Resource Manager-ID:t för det lokala logiska Azure-nätverket som skapats enligt dessa steg. Infrastrukturadministratören bör ge dig Resource Manager-ID:t för det logiska nätverket. Du kan också hämta Resource Manager-ID:t med ,$logicnet_Id = $(az stack-hci-vm network lnet show --name "<your-lnet-name>" --resource-group $resource_group_name --query "id" -o tsv)om infrastrukturadministratören tillhandahåller ett logiskt nätverksnamn och resursgruppsnamn.
Kör kommandot az aksarc create med parametern --enable-oidc-issuer --enable-workload-identity . Ange dina entra-admin-group-object-ids och se till att du är medlem i administratörsgruppen för Microsoft Entra-ID för åtkomst till proxyläge:
Azure CLI
az aksarc create
-n $aks_cluster_name -g $resource_group_name
--custom-location $customlocation_ID --vnet-ids $logicnet_Id
--aad-admin-group-object-ids <entra-admin-group-object-ids>
--generate-ssh-keys
--enable-oidc-issuer --enable-workload-identity
Efter några minuter slutförs kommandot och returnerar JSON-formaterad information om klustret.
Det kan ta lite tid innan arbetsbelastningsidentitetstillägget distribueras när ett etablerat kluster har skapats. Använd följande kommando för att kontrollera status för arbetsbelastningsidentitetstillägget:
Azure CLI
az connectedk8s show -n $aks_cluster_name -g $resource_group_name
JSON
# 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/"}
I Azure Portal kan du visa wiextension-tillägget under avsnittet Egenskaper i kubernetes-klustret.
Viktigt
Som en del av säkerhetsförbättringen för AKS Arc-kluster utlöser arbetsbelastningsidentitetsaktivering två ändringar. För det första roteras signeringsnyckeln för Kubernetes-tjänstkontot automatiskt var 45:e dag och förblir giltig i 90 dagar.
--service-account-extend-token-expiration För det andra är flaggan inaktiverad, vilket minskar tokens giltighet från ett år till högst 24 timmar.
När AKS-klustret har skapats kan du hämta URL:en för OIDC-utfärdaren och spara den i en miljövariabel. Kör följande kommando:
Azure CLI
$SERVICE_ACCOUNT_ISSUER =$(az connectedk8s show --n $aks_cluster_name --resource-group $resource_group_name --query "oidcIssuerProfile.issuerUrl" --output tsv)
Skapa först en hanterad identitet. Kör kommandot az identity create:
Azure CLI
az identity create --name $MSIName --resource-group $resource_group_name --location $Location --subscription $AZSubscriptionID
Skapa sedan variabler för den hanterade identitetens klient-ID:
Azure CLI
$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)
I det här steget skapar du ett Kubernetes-tjänstkonto och kommenterar det med klient-ID:t för den hanterade identitet som du skapade i föregående steg.
Använd klusteranslutning för att komma åt klustret från en klientenhet. Mer information finns i Komma åt klustret från en klientenhet:
Azure CLI
az connectedk8s proxy -n $aks_cluster_name -g $resource_group_name
Öppna ett nytt CLI-kommandofönster. Kopiera och klistra in följande kommandon:
Azure CLI
$yaml = @"
apiVersion: v1
kind: ServiceAccount
metadata:
annotations:
azure.workload.identity/client-id: $MSIId
name: $SERVICE_ACCOUNT_NAME
namespace: $SERVICE_ACCOUNT_NAMESPACE
"@
$yaml = $yaml -replace '\$MSIId', $MSIId `
-replace '\$SERVICE_ACCOUNT_NAME', $SERVICE_ACCOUNT_NAME `
-replace '\$SERVICE_ACCOUNT_NAMESPACE', $SERVICE_ACCOUNT_NAMESPACE
$yaml | kubectl apply -f -
Följande utdata visar hur tjänstkontot har skapats:
Output
serviceaccount/workload-identity-sa created
Steg 3: Skapa en federerad autentiseringsuppgift för den hanterade identiteten för att lita på OIDC-utfärdaren
Skapa först en federerad identitetsautentiseringsuppgift. Anropa kommandot az identity federated-credential create för att skapa den federerade identitetsautentiseringsuppgiften mellan den hanterade identiteten, utfärdaren av tjänstkontot och ämnet. Mer information om federerade identitetsuppgifter i Microsoft Entra finns i Översikt över federerade identitetsautentiseringsuppgifter i Microsoft Entra-ID.
Azure CLI
# 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
Anteckning
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.
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:
Azure CLI
$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.
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.
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:
Azure CLIaz 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)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.
Azure CLI$CALLER_OBJECT_ID=$(az ad signed-in-user show --query id -o tsv) az role assignment create --assignee-object-id $CALLER_OBJECT_ID --role "Key Vault Secrets Officer" --scope $KVId --assignee-principal-type ServicePrincipalSkapa en hemlighet i nyckelvalvet:
Azure CLIaz keyvault secret set --vault-name $KVName --name $KVSecretName --value "Hello!"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:
Azure CLI$IDENTITY_PRINCIPAL_ID=$(az identity show --name "$USER_ASSIGNED_IDENTITY_NAME" --resource-group "$resource_group_name" --query principalId --output tsv) az role assignment create --assignee-object-id $IDENTITY_PRINCIPAL_ID --role "Key Vault Secrets User" --scope $KVId --assignee-principal-type ServicePrincipalSkapa en miljövariabel för nyckelvalvs-URL:en:
Azure CLI$KVUrl=$(az keyvault show --resource-group $resource_group_name --name $KVName --query properties.vaultUri --output tsv)Distribuera en podd som refererar till tjänstkontot och key vault-URL:en:
Azure CLI$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 <path-to-aks-cluster-kubeconfig> apply -f -
Om du vill ta bort AKS Arc-klustret använder du kommandot az aksarc delete:
Azure CLI
az aksarc delete -n $aks_cluster_name -g $resource_group_name
Anteckning
Det finns ett känt problem när du tar bort ett AKS Arc-kluster med PodDisruptionBudget(PDB)-resurser: borttagningen kan misslyckas med att ta bort dessa PDB-resurser. Microsoft är medveten om problemet och arbetar med en korrigering.
PDB installeras som standard i arbetsbelastningsidentitetsaktiverade AKS Arc-kluster. För instruktioner om hur du tar bort ett AKS Arc-kluster med workload identity, se felsökningsguidenför
I den här artikeln distribuerade du ett Kubernetes-kluster och konfigurerade det 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.
Ytterligare resurser
Utbildning
Certifiering
Microsoft-certifierad: Identitets- och åtkomstadministratör Associate - Certifications
Demonstrera funktionerna i Microsoft Entra ID för att modernisera identitetslösningar, implementera hybridlösningar och implementera identitetsstyrning.