Workloadidentiteit implementeren en configureren op een AKS-cluster (Azure Kubernetes Service)
Artikel
Azure Kubernetes Service (AKS) is een beheerde Kubernetes-service waarmee u Kubernetes-clusters snel kunt implementeren en beheren. Dit artikel laat het volgende zien:
Implementeer een AKS-cluster met behulp van de Azure CLI met de OpenID Connect-verlener en een Microsoft Entra Workload-ID.
Maak een Microsoft Entra Workload-ID- en Kubernetes-serviceaccount.
Configureer de beheerde identiteit voor tokenfederatie.
Implementeer de workload en controleer de verificatie met de workload-id.
U kunt desgewenst een pod in het cluster toegang verlenen tot geheimen in een Azure-sleutelkluis.
Voor dit artikel is versie 2.47.0 of hoger van de Azure CLI vereist. Als u Azure Cloud Shell gebruikt, is de nieuwste versie al geïnstalleerd.
Zorg ervoor dat de identiteit die u gebruikt om uw cluster te maken over de juiste minimale machtigingen beschikt. Zie Toegangs- en identiteitsopties voor Azure Kubernetes Service (AKS) voor meer informatie over toegang en identiteit voor AKS.
Als u meerdere Azure-abonnementen hebt, selecteert u de juiste abonnements-id waarin de resources moeten worden gefactureerd met behulp van de opdracht az account set .
Stel eerst uw abonnement in als het huidige actieve abonnement door de opdracht az account set aan te roepen en uw abonnements-id door te geven.
az account set --subscription <subscription-id>
Omgevingsvariabelen exporteren
Om de stappen voor het configureren van de vereiste identiteiten te vereenvoudigen, definiëren de onderstaande 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:
export RESOURCE_GROUP="myResourceGroup"
export LOCATION="eastus"
export CLUSTER_NAME="myAKSCluster"
export SERVICE_ACCOUNT_NAMESPACE="default"
export SERVICE_ACCOUNT_NAME="workload-identity-sa"
export SUBSCRIPTION="$(az account show --query id --output tsv)"
export USER_ASSIGNED_IDENTITY_NAME="myIdentity"
export FEDERATED_IDENTITY_CREDENTIAL_NAME="myFedIdentity"
# Include these variables to access key vault secrets from a pod in the cluster.
export KEYVAULT_NAME="keyvault-workload-id"
export KEYVAULT_SECRET_NAME="my-secret"
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.
Maak een AKS-cluster met behulp van de opdracht az aks create met de --enable-oidc-issuer parameter om de OIDC-verlener in te schakelen. In het volgende voorbeeld wordt een cluster met één knooppunt gemaakt:
az aks create \
--resource-group "${RESOURCE_GROUP}" \
--name "${CLUSTER_NAME}" \
--enable-oidc-issuer \
--enable-workload-identity \
--generate-ssh-keys
Na enkele minuten is de opdracht voltooid en retourneert deze informatie over het cluster in JSON-indeling.
U kunt een AKS-cluster bijwerken om de OIDC-verlener te gebruiken en workloadidentiteit in te schakelen door de opdracht az aks update aan te roepen met de --enable-oidc-issuer en de --enable-workload-identity parameters. In het volgende voorbeeld wordt een bestaand cluster bijgewerkt:
az aks update \
--resource-group "${RESOURCE_GROUP}" \
--name "${CLUSTER_NAME}" \
--enable-oidc-issuer \
--enable-workload-identity
De URL van de OIDC-verlener ophalen
Voer de volgende opdracht uit om de URL van de OIDC-verlener op te halen en op te slaan in een omgevingsvariabele:
export AKS_OIDC_ISSUER="$(az aks show --name "${CLUSTER_NAME}" \
--resource-group "${RESOURCE_GROUP}" \
--query "oidcIssuerProfile.issuerUrl" \
--output tsv)"
De omgevingsvariabele moet de URL van de verlener bevatten, vergelijkbaar met het volgende voorbeeld:
De verlener is standaard ingesteld op het gebruik van de basis-URL https://{region}.oic.prod-aks.azure.com/{tenant_id}/{uuid}, waarbij de waarde voor {region} de locatie waarop het AKS-cluster wordt geïmplementeerd, overeenkomt met de locatie. De waarde {uuid} vertegenwoordigt de OIDC-sleutel. Dit is een willekeurig gegenereerde GUID voor elk cluster dat onveranderbaar is.
Maak een Kubernetes-serviceaccount en annotaeer dit met de client-id van de beheerde identiteit die u in de vorige stap hebt gemaakt. Gebruik de opdracht az aks get-credentials en vervang de waarden voor de clusternaam en de naam van de resourcegroep.
az aks get-credentials --name "${CLUSTER_NAME}" --resource-group "${RESOURCE_GROUP}"
Kopieer en plak de volgende invoer met meerdere regels in de Azure CLI.
Het duurt enkele seconden voordat de federatieve identiteitsreferentie is doorgegeven nadat deze is toegevoegd. Als er direct na het toevoegen van de federatieve identiteitsreferentie een tokenaanvraag wordt gedaan, mislukt de aanvraag mogelijk totdat de cache wordt vernieuwd. U kunt dit probleem voorkomen door een kleine vertraging toe te voegen nadat u de federatieve identiteitsreferentie hebt toegevoegd.
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 de eigenschappen metadata\namespace en spec\serviceAccountName . Zorg ervoor dat u een installatiekopieën voor en een containernaam opgeeft <image> voor <containerName>:
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
name: sample-workload-identity
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>
EOF
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.
Machtigingen verlenen voor toegang tot Azure Key Vault
In de instructies in deze stap ziet u hoe u vanuit de pod toegang krijgt tot geheimen, sleutels of certificaten in een Azure-sleutelkluis. 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:
Wijs uzelf de rol RBAC Key Vault Secrets Officer toe, zodat u een geheim kunt maken in de nieuwe sleutelkluis:
export KEYVAULT_RESOURCE_ID=$(az keyvault show --resource-group "${KEYVAULT_RESOURCE_GROUP}" \
--name "${KEYVAULT_NAME}" \
--query id \
--output tsv)
az role assignment create --assignee "\<user-email\>" \
--role "Key Vault Secrets Officer" \
--scope "${KEYVAULT_RESOURCE_ID}"
Maak een geheim in de sleutelkluis:
export KEYVAULT_SECRET_NAME="my-secret"
az keyvault secret set \
--vault-name "${KEYVAULT_NAME}" \
--name "${KEYVAULT_SECRET_NAME}" \
--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:
Het kan tot tien minuten duren voordat Azure RBAC-roltoewijzingen zijn doorgegeven. Als de pod geen toegang heeft tot het geheim, moet u mogelijk wachten totdat de roltoewijzing is doorgegeven. Zie Problemen met Azure RBAC oplossen voor meer informatie.
Workloadidentiteit uitschakelen
Als u de Microsoft Entra Workload-ID wilt uitschakelen op het AKS-cluster waarvoor het is ingeschakeld en geconfigureerd, kunt u de volgende opdracht uitvoeren:
az aks update \
--resource-group "${RESOURCE_GROUP}" \
--name "${CLUSTER_NAME}" \
--disable-workload-identity
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 . Als u uw toepassing niet kunt herschrijven om de nieuwste versie van de clientbibliotheek te gebruiken, kunt u uw toepassingspod instellen voor verificatie met beheerde identiteit met workloadidentiteit als een kortetermijnmigratieoplossing.
De serviceconnectorintegratie vereenvoudigt de verbindingsconfiguratie voor AKS-workloads en Azure-backingservices. Het verwerkt verificatie- en netwerkconfiguraties veilig en volgt aanbevolen procedures voor het maken van verbinding met Azure-services. Zie Verbinding maken met De Azure OpenAI-service in AKS met behulp van workloadidentiteit en de inleiding tot de serviceconnector voor meer informatie.
Met ons samenwerken op GitHub
De bron voor deze inhoud vindt u op GitHub, waar u ook problemen en pull-aanvragen kunt maken en controleren. Bekijk onze gids voor inzenders voor meer informatie.
Azure Kubernetes Service-feedback
Azure Kubernetes Service is een open source project. Selecteer een koppeling om feedback te geven:
Meer informatie over het maken, beheren en verlenen van machtigingen voor workloadidentiteiten, waarmee uw implementatiewerkstromen veilig kunnen worden geverifieerd bij Azure.
Meer informatie over Microsoft Entra Workload-ID voor Azure Kubernetes Service (AKS) en het migreren van uw toepassing voor verificatie met behulp van deze identiteit.
Meer informatie over het gebruik van een door het systeem toegewezen of door de gebruiker toegewezen beheerde identiteit in Azure Kubernetes Service (AKS).