Workloadidentiteit implementeren en configureren op een AKS die is ingeschakeld door een Azure Arc-cluster (preview)

Artikel
11/23/2024

Van toepassing op: Azure Local, versie 23H2

Met federatie van workloadidentiteit kunt u een door de gebruiker toegewezen beheerde identiteit of app-registratie in Microsoft Entra ID configureren om tokens van een externe id-provider (IdP) te vertrouwen, zoals Kubernetes, waardoor toegang tot resources die worden beveiligd door Microsoft Entra, zoals Azure Key Vault of Azure Blob Storage, kunnen worden ingeschakeld.

Azure Kubernetes Service (AKS) die is ingeschakeld door Azure Arc, is een beheerde Kubernetes-service waarmee u eenvoudig Kubernetes-clusters met workloadidentiteit kunt implementeren. In dit artikel wordt beschreven hoe u de volgende taken uitvoert:

Maak een AKS Arc-cluster waarvoor workloadidentiteit is ingeschakeld (preview).
Maak een Kubernetes-serviceaccount en bind dit aan azure Managed Identity.
Maak een federatieve referentie voor de beheerde identiteit om de OIDC-verlener te vertrouwen.
Implementeer uw toepassing.
Voorbeeld: Een pod in het cluster toegang verlenen tot geheimen in een Azure-sleutelkluis.

Belangrijk

Deze preview-functies zijn beschikbaar op selfservice, opt-in basis. Previews worden geleverd 'zoals is' en 'als beschikbaar' en ze worden uitgesloten van de serviceovereenkomsten en beperkte garantie. Azure Kubernetes Service, ingeschakeld door Azure Arc Previews, wordt gedeeltelijk gedekt door klantondersteuning op basis van best effort.

Notitie

In openbare preview ondersteunt AKS in Azure Stack HCI het inschakelen van workloadidentiteit tijdens het maken van een AKS-cluster. Het inschakelen van de workloadidentiteit nadat het cluster is gemaakt of uitgeschakeld, wordt momenteel niet ondersteund.

Vereisten

Voordat u een Kubernetes-cluster implementeert waarvoor Azure Arc is ingeschakeld, moet u aan de volgende vereisten voldoen:

Als u geen Azure-abonnement hebt, maakt u een gratis Azure-account voordat u begint.
Voor dit artikel is versie 1.4.23 of hoger van de Azure CLI vereist. Als u Azure Cloud Shell gebruikt, is de nieuwste versie al geïnstalleerd.

Omgevingsvariabelen exporteren

Om de stappen voor het configureren van de vereiste identiteiten te vereenvoudigen, definiëren de volgende opdrachten omgevingsvariabelen waarnaar wordt verwezen in de voorbeelden in dit artikel. Vervang de volgende waarden door uw eigen waarden:

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

Het actieve abonnement instellen

Stel eerst uw abonnement in als het huidige actieve abonnement. Voer de opdracht az account set uit met uw abonnements-id:

az login  
az account set -s $AZSubscriptionID

Een brongroep maken

Een Azure-resourcegroep is een logische groep waarin Azure-resources worden geïmplementeerd en beheerd. Wanneer u een resourcegroep maakt, wordt u gevraagd een locatie op te geven. Deze locatie is de opslaglocatie van de metagegevens van uw resourcegroep en waar uw resources worden uitgevoerd in Azure als u geen andere regio opgeeft tijdens het maken van de resource.

Voer de opdracht az group create uit om een resourcegroep te maken:

az group create --name $resource_group_name --location $Location

In de volgende voorbeelduitvoer ziet u hoe een resourcegroep is gemaakt:

{ 
  "id": "/subscriptions/<guid>/resourceGroups/myResourceGroup", 
  "location": "westeurope", 
  "managedBy": null, 
  "name": "$resource_group_name", 
  "properties": { 
    "provisioningState": "Succeeded" 
  }, 
  "tags": null 
}

Stap 1: Een AKS Arc-cluster maken waarvoor de workloadidentiteit is ingeschakeld

Als u een AKS Arc-cluster wilt maken, hebt u zowel de als $logicnet_Id de $customlocation_ID waarden nodig.

$customlocation_ID: De Azure Resource Manager-id van de aangepaste locatie. De aangepaste locatie wordt geconfigureerd tijdens de implementatie van het Azure Stack HCI-cluster. De infrastructuurbeheerder moet u de Resource Manager-id van de aangepaste locatie geven. U kunt ook de Resource Manager-id ophalen met behulp van $customlocation_ID = $(az customlocation show --name "<your-custom-location-name>" --resource-group $resource_group_name --query "id" -o tsv), als de infrastructuurbeheerder een aangepaste locatienaam en resourcegroepnaam biedt.
$logicnet_Id: De Azure Resource Manager-id van het logische Azure-netwerk dat is gemaakt volgens deze stappen. De infrastructuurbeheerder moet u de Resource Manager-id van het logische netwerk geven. U kunt ook de Resource Manager-id ophalen met behulp van $logicnet_Id = $(az stack-hci-vm network lnet show --name "<your-lnet-name>" --resource-group $resource_group_name --query "id" -o tsv), als de infrastructuurbeheerder een logische netwerknaam en resourcegroepnaam biedt.

Voer de opdracht az aksarc create uit met de --enable-oidc-issuer --enable-workload-identity parameter. Geef uw entra-admin-group-object-id's op en zorg ervoor dat u lid bent van de Microsoft Entra ID-beheergroep voor toegang tot de proxymodus:

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

Na enkele minuten is de opdracht voltooid en retourneert deze informatie over het cluster in JSON-indeling.

Het kan enige tijd duren voordat de workload-id-extensie is geïmplementeerd nadat een ingericht cluster is gemaakt. Gebruik de volgende opdracht om de status van de workload-id-extensie te controleren:

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/"}

In Azure Portal kunt u de wiextension-extensie bekijken in de sectie Eigenschappen van uw Kubernetes-cluster.

Belangrijk

Als onderdeel van de beveiligingsverbetering voor AKS Arc-clusters activeert de activering van workloadidentiteit twee wijzigingen. Eerst draait de ondertekeningssleutel van het Kubernetes-serviceaccount automatisch om de 45 dagen en blijft deze 90 dagen geldig. Ten tweede is de --service-account-extend-token-expiration vlag uitgeschakeld, waardoor de geldigheid van het token wordt verlaagd van één jaar tot maximaal 24 uur.

De URL van de OIDC-verlener opslaan in een omgevingsvariabele

Zodra het AKS-cluster is gemaakt, kunt u de URL van de OIDC-verlener ophalen en opslaan in een omgevingsvariabele. Voer de volgende opdracht uit:

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

Stap 2: Een Kubernetes-serviceaccount maken en dit verbinden met de Azure Managed Identity

Maak eerst een beheerde identiteit. Voer de opdracht az identity create uit :

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

Maak vervolgens variabelen voor de client-id van de beheerde identiteit:

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

Een Kubernetes-serviceaccount maken

Maak een Kubernetes-serviceaccount en annotaeer dit met de client-id van de beheerde identiteit die u in de vorige stap hebt gemaakt:

az connectedk8s proxy -n $aks_cluster_name -g $resource_group_name

Open een nieuw venster. Kopieer en plak de volgende CLI-opdrachten:

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

In de volgende uitvoer ziet u dat het serviceaccount is gemaakt:

serviceaccount/workload-identity-sa created

Stap 3: Maak een federatieve referentie voor de beheerde identiteit om de OIDC-verlener te vertrouwen

Maak eerst een federatieve identiteitsreferentie. Roep de opdracht az identity federated-credential create aan om de federatieve identiteitsreferentie te maken tussen de beheerde identiteit, de verlener van het serviceaccount en het onderwerp. Zie Overzicht van federatieve identiteitsreferenties in Microsoft Entra voor meer informatie over federatieve identiteitsreferenties 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

Notitie

Nadat u een federatieve identiteitsreferentie hebt toegevoegd, duurt het enkele seconden voordat deze is doorgegeven. Tokenaanvragen die onmiddellijk daarna zijn gedaan, kunnen mislukken totdat de cache wordt vernieuwd. U kunt dit probleem voorkomen door een korte vertraging toe te voegen nadat u de federatieve identiteitsreferentie hebt gemaakt.

Stap 4: Uw toepassing implementeren

Wanneer u uw toepassingspods implementeert, moet het manifest verwijzen naar het serviceaccount dat is gemaakt in de stap Kubernetes-serviceaccount maken. In het volgende manifest ziet u hoe u naar het account verwijst, met name naar de metadata\namespace en spec\serviceAccountName eigenschappen. Zorg ervoor dat u een installatiekopieën voor en een containernaam opgeeft image voor 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 -

Belangrijk

Zorg ervoor dat de toepassingspods die gebruikmaken van de workloadidentiteit het label azure.workload.identity/use: "true" in de podspecificatie bevatten. Anders mislukken de pods nadat ze opnieuw zijn opgestart.

Voorbeeld: Machtigingen verlenen voor toegang tot Azure Key Vault

In de instructies in deze stap wordt beschreven hoe u toegang krijgt tot geheimen, sleutels of certificaten in een Azure-sleutelkluis vanuit de pod. In de voorbeelden in deze sectie wordt de toegang tot geheimen in de sleutelkluis voor de workloadidentiteit geconfigureerd, maar u kunt vergelijkbare stappen uitvoeren om toegang tot sleutels of certificaten te configureren.

In het volgende voorbeeld ziet u hoe u het machtigingsmodel voor op rollen gebaseerd toegangsbeheer (Azure RBAC) van Azure gebruikt om de pod toegang te verlenen tot de sleutelkluis. Zie Machtiging verlenen aan toepassingen voor toegang tot een Azure-sleutelkluis met behulp van Azure RBAC voor meer informatie over het Azure RBAC-machtigingsmodel voor Azure Key Vault.

Maak een sleutelkluis met beveiliging tegen opschonen en RBAC-autorisatie ingeschakeld. U kunt ook een bestaande sleutelkluis gebruiken als deze is geconfigureerd voor zowel beveiliging tegen opschonen als RBAC-autorisatie:

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)

Wijs de rol RBAC Key Vault Secrets Officer toe aan uzelf, zodat u een geheim kunt maken in de nieuwe sleutelkluis. Het kan vijf minuten duren voordat nieuwe roltoewijzingen zijn doorgegeven en bijgewerkt door de autorisatieserver.
```
az role assignment create --assignee-object-id $MSIPrincipalId --role "Key Vault Secrets Officer" --scope $KVId --assignee-principal-type ServicePrincipal
```

Maak een geheim in de sleutelkluis:

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

Wijs de rol Key Vault Secrets User toe aan de door de gebruiker toegewezen beheerde identiteit die u eerder hebt gemaakt. Deze stap geeft de beheerde identiteit toestemming om geheimen uit de sleutelkluis te lezen:
```
az role assignment create --assignee-object-id $MSIPrincipalId --role "Key Vault Secrets User" --scope $KVId --assignee-principal-type ServicePrincipal
```

Maak een omgevingsvariabele voor de URL van de sleutelkluis:

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

Implementeer een pod die verwijst naar de URL van het serviceaccount en de sleutelkluis:

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

Volgende stappen

In dit artikel hebt u een Kubernetes-cluster geïmplementeerd en geconfigureerd voor het gebruik van een workloadidentiteit ter voorbereiding op toepassingsworkloads voor verificatie met die referentie. U bent nu klaar om uw toepassing te implementeren en deze te configureren voor het gebruik van de workloadidentiteit met de nieuwste versie van de Azure Identity-clientbibliotheek.

Delen via

Workloadidentiteit implementeren en configureren op een AKS die is ingeschakeld door een Azure Arc-cluster (preview)

Vereisten

Omgevingsvariabelen exporteren

Het actieve abonnement instellen

Een brongroep maken

Stap 1: Een AKS Arc-cluster maken waarvoor de workloadidentiteit is ingeschakeld

De URL van de OIDC-verlener opslaan in een omgevingsvariabele

Stap 2: Een Kubernetes-serviceaccount maken en dit verbinden met de Azure Managed Identity

Een Kubernetes-serviceaccount maken

Stap 3: Maak een federatieve referentie voor de beheerde identiteit om de OIDC-verlener te vertrouwen

Stap 4: Uw toepassing implementeren

Voorbeeld: Machtigingen verlenen voor toegang tot Azure Key Vault

Volgende stappen

Feedback

Aanvullende resources