Delen via

Workloadidentiteit configureren op een AKS Edge Essentials-cluster (preview)

  • Artikel

Azure Kubernetes Service (AKS) Edge Essentials is een on-premises Kubernetes-implementatie van Azure Kubernetes Service (AKS) die het uitvoeren van containertoepassingen op schaal automatiseert. In dit artikel wordt beschreven hoe u de volgende taken uitvoert:

  • 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.

Zie Workload-identiteitsfederatie in Kubernetes met Azure Arc (preview) voor een conceptueel overzicht van workloadidentiteitsfederatie.

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. Previews van Azure Kubernetes Service Edge Essentials worden gedeeltelijk gedekt door klantondersteuning op basis van best effort.

Notitie

In deze openbare preview kunt u met AKS Edge Essentials de workloadidentiteit inschakelen tijdens de eerste implementatie van het quickstartscript voor Azure IoT Operations. Deze functie is niet beschikbaar voor andere AKS Edge Essentials-scenario's.

Vereisten

Voordat u workloadidentiteitsfederatie gebruikt voor een AKS Edge Essentials-cluster, moet u het quickstartscript voor De Azure IoT-bewerking implementeren, zoals beschreven in Een AKS Edge Essentials-cluster maken en configureren waarmee Azure IoT Operations kan worden uitgevoerd. Met het script wordt automatisch de functie voor federatie van workloadidentiteiten ingeschakeld op het AKS Edge Essentials-cluster.

Nadat u het AKS Edge Essentials-cluster hebt geïmplementeerd, kunt u de volgende opdracht gebruiken om de status van de workloadidentiteitsextensie 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/", 

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

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

Omgevingsvariabelen exporteren

Om de stappen voor het configureren van de vereiste identiteiten te vereenvoudigen, definiëren de volgende stappen omgevingsvariabelen waarnaar wordt verwezen in de voorbeelden in dit artikel. Vergeet niet om de waarden te vervangen die worden weergegeven 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" 

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

De URL van de OIDC-verlener opslaan in een omgevingsvariabele

Voer de volgende opdracht uit om de URL van de OIDC-verlener op te halen en op te slaan in een omgevingsvariabele:

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

Stap 1: Maak een Kubernetes-serviceaccount en bind dit aan de Beheerde identiteit van Azure

Roep eerst de opdracht az identity create aan om een beheerde identiteit te maken:

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. Kopieer en plak de volgende Azure CLI-opdrachten:

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

In de volgende uitvoer ziet u de workloadidentiteit die is gemaakt:

serviceaccount/workload-identity-sa created

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

Als u de federatieve identiteitsreferentie tussen de beheerde identiteit, de verlener van het serviceaccount en het onderwerp wilt maken, roept u de opdracht az identity federated-credential create aan . 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 3: 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.

  1. 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)

  2. 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

  3. Maak een geheim in de sleutelkluis:

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

  4. 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

  5. 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)

  6. 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 deze 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.