Ansluta din Azure-identitetsprovider till Azure Key Vault Secrets Store CSI-drivrutinen i Azure Kubernetes Service (AKS)
CSI-drivrutinen (Secrets Store Container Storage Interface) i Azure Kubernetes Service (AKS) ger olika metoder för identitetsbaserad åtkomst till ditt Azure Key Vault. Den här artikeln beskriver dessa metoder och metodtips för när du ska använda rollbaserad åtkomstkontroll (RBAC) eller OpenID Connect-säkerhetsmodeller (OIDC) för att få åtkomst till ditt nyckelvalv och AKS-kluster.
Du kan använda någon av följande åtkomstmetoder:
Förutsättningar för CSI-drivrutin
- Innan du börjar måste du slutföra stegen i Använda Azure Key Vault-providern för Secrets Store CSI-drivrutinen i ett AkS-kluster (Azure Kubernetes Service) för att aktivera CSI-drivrutinen för Azure Key Vault Secrets Store i aks-klustret.
Åtkomst med ett Microsoft Entra-arbetsbelastnings-ID
Ett Microsoft Entra-arbetsbelastnings-ID är en identitet som ett program som körs på en podd använder för att autentisera sig mot andra Azure-tjänster, till exempel arbetsbelastningar i programvara. CSI-drivrutinen för Secret Store integreras med inbyggda Kubernetes-funktioner för att federera med externa identitetsprovidrar.
I den här säkerhetsmodellen fungerar AKS-klustret som tokenutfärdare. Microsoft Entra-ID använder sedan OIDC för att identifiera offentliga signeringsnycklar och verifiera autenticiteten för tjänstkontotoken innan du utbyter den mot en Microsoft Entra-token. För att din arbetsbelastning ska kunna byta ut en tjänstkontotoken som projiceras till dess volym för en Microsoft Entra-token behöver du Azure Identity-klientbiblioteket i Azure SDK eller Microsoft Authentication Library (MSAL)
Kommentar
- Den här autentiseringsmetoden ersätter Microsoft Entra poddhanterad identitet (förhandsversion). Microsoft Entra-poddhanterad identitet med öppen källkod (förhandsversion) i Azure Kubernetes Service har blivit inaktuell från och med 2022-01-24.
- Microsoft Entra-arbetsbelastnings-ID har stöd för både Windows- och Linux-kluster.
Konfigurera arbetsbelastningsidentitet
Ange din prenumeration med hjälp av
az account set
kommandot .export SUBSCRIPTION_ID=<subscription id> export RESOURCE_GROUP=<resource group name> export UAMI=<name for user assigned identity> export KEYVAULT_NAME=<existing keyvault name> export CLUSTER_NAME=<aks cluster name> az account set --subscription $SUBSCRIPTION_ID
Skapa en hanterad identitet med kommandot
az identity create
.az identity create --name $UAMI --resource-group $RESOURCE_GROUP export USER_ASSIGNED_CLIENT_ID="$(az identity show --resource-group $RESOURCE_GROUP --name $UAMI --query 'clientId' -o tsv)" export IDENTITY_TENANT=$(az aks show --name $CLUSTER_NAME --resource-group $RESOURCE_GROUP --query identity.tenantId -o tsv)
Skapa en rolltilldelning som ger arbetsbelastningsidentiteten behörighet att komma åt nyckelvalvets hemligheter, åtkomstnycklar och certifikat med hjälp av
az role assignment create
kommandot .Viktigt!
- Om ditt nyckelvalv har angetts med
--enable-rbac-authorization
och du använderkey
ellercertificate
skriver tilldelarKey Vault Certificate User
du rollen för att ge behörigheter. - Om ditt nyckelvalv har angetts med
--enable-rbac-authorization
och du användersecret
typ tilldelarKey Vault Secrets User
du rollen. - Om nyckelvalvet inte har angetts med
--enable-rbac-authorization
kan du användaaz keyvault set-policy
kommandot med parametern--key-permissions get
,--certificate-permissions get
eller--secret-permissions get
för att skapa en nyckelvalvsprincip för att bevilja åtkomst för nycklar, certifikat eller hemligheter. Till exempel:
az keyvault set-policy --name $KEYVAULT_NAME --key-permissions get --object-id $IDENTITY_OBJECT_ID
export KEYVAULT_SCOPE=$(az keyvault show --name $KEYVAULT_NAME --query id -o tsv) # Example command for key vault with RBAC enabled using `key` type az role assignment create --role "Key Vault Certificate User" --assignee $USER_ASSIGNED_CLIENT_ID --scope $KEYVAULT_SCOPE
- Om ditt nyckelvalv har angetts med
Hämta URL:en för AKS-klustrets OIDC-utfärdare med hjälp av
az aks show
kommandot .Kommentar
Det här steget förutsätter att du har ett befintligt AKS-kluster med URL:en för OIDC-utfärdaren aktiverad. Om du inte har aktiverat det kan du läsa Uppdatera ett AKS-kluster med OIDC-utfärdare för att aktivera det.
export AKS_OIDC_ISSUER="$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query "oidcIssuerProfile.issuerUrl" -o tsv)" echo $AKS_OIDC_ISSUER
Upprätta en federerad identitetsautentiseringsuppgift mellan Microsoft Entra-programmet, utfärdaren av tjänstkontot och ämnet. Hämta objekt-ID för Microsoft Entra-programmet med hjälp av följande kommandon. Se till att uppdatera värdena för
serviceAccountName
ochserviceAccountNamespace
med Kubernetes-tjänstkontots namn och dess namnområde.export SERVICE_ACCOUNT_NAME="workload-identity-sa" # sample name; can be changed export SERVICE_ACCOUNT_NAMESPACE="default" # can be changed to namespace of your workload cat <<EOF | kubectl apply -f - apiVersion: v1 kind: ServiceAccount metadata: annotations: azure.workload.identity/client-id: ${USER_ASSIGNED_CLIENT_ID} name: ${SERVICE_ACCOUNT_NAME} namespace: ${SERVICE_ACCOUNT_NAMESPACE} EOF
Skapa den federerade identitetsautentiseringsuppgiften mellan den hanterade identiteten, utfärdaren av tjänstkontot och ämnet med hjälp av
az identity federated-credential create
kommandot .export FEDERATED_IDENTITY_NAME="aksfederatedidentity" # can be changed as needed az identity federated-credential create --name $FEDERATED_IDENTITY_NAME --identity-name $UAMI --resource-group $RESOURCE_GROUP --issuer ${AKS_OIDC_ISSUER} --subject system:serviceaccount:${SERVICE_ACCOUNT_NAMESPACE}:${SERVICE_ACCOUNT_NAME}
Distribuera en
SecretProviderClass
med hjälp avkubectl apply
kommandot och följande YAML-skript.cat <<EOF | kubectl apply -f - # This is a SecretProviderClass example using workload identity to access your key vault apiVersion: secrets-store.csi.x-k8s.io/v1 kind: SecretProviderClass metadata: name: azure-kvname-wi # needs to be unique per namespace spec: provider: azure parameters: usePodIdentity: "false" clientID: "${USER_ASSIGNED_CLIENT_ID}" # Setting this to use workload identity keyvaultName: ${KEYVAULT_NAME} # Set to the name of your key vault cloudName: "" # [OPTIONAL for Azure] if not provided, the Azure environment defaults to AzurePublicCloud objects: | array: - | objectName: secret1 # Set to the name of your secret objectType: secret # object types: secret, key, or cert objectVersion: "" # [OPTIONAL] object versions, default to latest if empty - | objectName: key1 # Set to the name of your key objectType: key objectVersion: "" tenantId: "${IDENTITY_TENANT}" # The tenant ID of the key vault EOF
Kommentar
Om du använder
objectAlias
i stället förobjectName
uppdaterar du YAML-skriptet för att ta hänsyn till det.Kommentar
För att fungera
SecretProviderClass
korrekt måste du fylla i Ditt Azure Key Vault med hemligheter, nycklar eller certifikat innan du refererar till dem iobjects
avsnittet.Distribuera en exempelpodd med kommandot
kubectl apply
och följande YAML-skript.cat <<EOF | kubectl apply -f - # This is a sample pod definition for using SecretProviderClass and workload identity to access your key vault kind: Pod apiVersion: v1 metadata: name: busybox-secrets-store-inline-wi labels: azure.workload.identity/use: "true" spec: serviceAccountName: "workload-identity-sa" containers: - name: busybox image: registry.k8s.io/e2e-test-images/busybox:1.29-4 command: - "/bin/sleep" - "10000" volumeMounts: - name: secrets-store01-inline mountPath: "/mnt/secrets-store" readOnly: true volumes: - name: secrets-store01-inline csi: driver: secrets-store.csi.k8s.io readOnly: true volumeAttributes: secretProviderClass: "azure-kvname-wi" EOF
Åtkomst med hanterad identitet
Ett Microsoft Entra-hanterat ID är en identitet som en administratör använder för att autentisera sig mot andra Azure-tjänster. Den hanterade identiteten använder RBAC för att federera med externa identitetsprovidrar.
I den här säkerhetsmodellen kan du ge åtkomst till klustrets resurser till gruppmedlemmar eller klienter som delar en hanterad roll. Rollen kontrolleras för omfång för åtkomst till keyvault och andra autentiseringsuppgifter. När du aktiverade Azure Key Vault-providern för Secrets Store CSI-drivrutinen i ditt AKS-kluster skapade den en användaridentitet.
Konfigurera hanterad identitet
Få åtkomst till ditt nyckelvalv med kommandot
az aks show
och den användartilldelade hanterade identiteten som skapas av tillägget. Du bör också hämta identitetensclientId
, som du ska använda i senare steg när du skapar enSecretProviderClass
.az aks show --resource-group <resource-group> --name <cluster-name> --query addonProfiles.azureKeyvaultSecretsProvider.identity.objectId -o tsv az aks show --resource-group <resource-group> --name <cluster-name> --query addonProfiles.azureKeyvaultSecretsProvider.identity.clientId -o tsv
Du kan också skapa en ny hanterad identitet och tilldela den till vm-skalningsuppsättningen eller till varje VM-instans i tillgänglighetsuppsättningen med hjälp av följande kommandon.
az identity create --resource-group <resource-group> --name <identity-name> az vmss identity assign --resource-group <resource-group> --name <agent-pool-vmss> --identities <identity-resource-id> az vm identity assign --resource-group <resource-group> --name <agent-pool-vm> --identities <identity-resource-id> az identity show --resource-group <resource-group> --name <identity-name> --query 'clientId' -o tsv
Skapa en rolltilldelning som ger identiteten behörighet att komma åt nyckelvalvets hemligheter, åtkomstnycklar och certifikat med hjälp av
az role assignment create
kommandot .Viktigt!
- Om ditt nyckelvalv har angetts med
--enable-rbac-authorization
och du använderkey
ellercertificate
skriver tilldelarKey Vault Certificate User
du rollen. - Om ditt nyckelvalv har angetts med
--enable-rbac-authorization
och du användersecret
typ tilldelarKey Vault Secrets User
du rollen. - Om nyckelvalvet inte har angetts med
--enable-rbac-authorization
kan du användaaz keyvault set-policy
kommandot med parametern--key-permissions get
,--certificate-permissions get
eller--secret-permissions get
för att skapa en nyckelvalvsprincip för att bevilja åtkomst för nycklar, certifikat eller hemligheter. Till exempel:
az keyvault set-policy --name $KEYVAULT_NAME --key-permissions get --object-id $IDENTITY_OBJECT_ID
export IDENTITY_OBJECT_ID="$(az identity show --resource-group <resource-group> --name <identity-name> --query 'principalId' -o tsv)" export KEYVAULT_SCOPE=$(az keyvault show --name <key-vault-name> --query id -o tsv) # Example command for key vault with RBAC enabled using `key` type az role assignment create --role "Key Vault Certificate User" --assignee $USER_ASSIGNED_CLIENT_ID --scope $KEYVAULT_SCOPE
- Om ditt nyckelvalv har angetts med
Skapa en
SecretProviderClass
med hjälp av följande YAML. Se till att använda dina egna värden föruserAssignedIdentityID
,keyvaultName
,tenantId
och de objekt som ska hämtas från nyckelvalvet.# This is a SecretProviderClass example using user-assigned identity to access your key vault apiVersion: secrets-store.csi.x-k8s.io/v1 kind: SecretProviderClass metadata: name: azure-kvname-user-msi spec: provider: azure parameters: usePodIdentity: "false" useVMManagedIdentity: "true" # Set to true for using managed identity userAssignedIdentityID: <client-id> # Set the clientID of the user-assigned managed identity to use keyvaultName: <key-vault-name> # Set to the name of your key vault cloudName: "" # [OPTIONAL for Azure] if not provided, the Azure environment defaults to AzurePublicCloud objects: | array: - | objectName: secret1 objectType: secret # object types: secret, key, or cert objectVersion: "" # [OPTIONAL] object versions, default to latest if empty - | objectName: key1 objectType: key objectVersion: "" tenantId: <tenant-id> # The tenant ID of the key vault
Kommentar
Om du använder
objectAlias
i stället förobjectName
måste du uppdatera YAML-skriptet.Kommentar
För att fungera
SecretProviderClass
korrekt måste du fylla i Ditt Azure Key Vault med hemligheter, nycklar eller certifikat innan du refererar till dem iobjects
avsnittet.Använd på
SecretProviderClass
klustret med hjälp avkubectl apply
kommandot .kubectl apply -f secretproviderclass.yaml
Skapa en podd med hjälp av följande YAML.
# This is a sample pod definition for using SecretProviderClass and the user-assigned identity to access your key vault kind: Pod apiVersion: v1 metadata: name: busybox-secrets-store-inline-user-msi spec: containers: - name: busybox image: registry.k8s.io/e2e-test-images/busybox:1.29-4 command: - "/bin/sleep" - "10000" volumeMounts: - name: secrets-store01-inline mountPath: "/mnt/secrets-store" readOnly: true volumes: - name: secrets-store01-inline csi: driver: secrets-store.csi.k8s.io readOnly: true volumeAttributes: secretProviderClass: "azure-kvname-user-msi"
Använd podden på klustret med kommandot
kubectl apply
.kubectl apply -f pod.yaml
Verifiera Key Vault-hemligheter
När podden har startats är det monterade innehållet på den volymsökväg som anges i din distributions-YAML tillgängligt. Använd följande kommandon för att verifiera dina hemligheter och skriva ut en testhemlighet.
Visa hemligheter som lagras i hemlighetsarkivet med hjälp av följande kommando.
kubectl exec busybox-secrets-store-inline-user-msi -- ls /mnt/secrets-store/
Visa en hemlighet i arkivet med hjälp av följande kommando. Det här exempelkommandot visar testhemligheten
ExampleSecret
.kubectl exec busybox-secrets-store-inline-user-msi -- cat /mnt/secrets-store/ExampleSecret
Hämta certifikat och nycklar
Azure Key Vault-designen gör skarpa distinktioner mellan nycklar, hemligheter och certifikat. Certifikatfunktionerna i Key Vault-tjänsten är utformade för att använda nyckel- och hemlighetsfunktioner. När du skapar ett key vault-certifikat skapas en adresserbar nyckel och hemlighet med samma namn. Den här nyckeln tillåter autentiseringsåtgärder och hemligheten tillåter hämtning av certifikatvärdet som en hemlighet.
Ett key vault-certifikat innehåller även offentliga x509-certifikatmetadata. Nyckelvalvet lagrar både offentliga och privata komponenter i certifikatet i en hemlighet. Du kan hämta varje enskild komponent genom att objectType
ange i SecretProviderClass
. I följande tabell visas vilka objekt som mappas till de olika resurser som är associerade med certifikatet:
Objekt | Returvärde | Returnerar hela certifikatkedjan |
---|---|---|
key |
Den offentliga nyckeln i PEM-format (Privacy Enhanced Mail). | Ej tillämpligt |
cert |
Certifikatet i PEM-format. | Nej |
secret |
Den privata nyckeln och certifikatet i PEM-format. | Ja |
Inaktivera tillägget i befintliga kluster
Kommentar
Innan du inaktiverar tillägget kontrollerar du att inget SecretProviderClass
används. Om du försöker inaktivera tillägget medan det SecretProviderClass
finns resulterar det i ett fel.
Inaktivera funktionen Azure Key Vault-providern för Secrets Store CSI Driver i ett befintligt kluster med kommandot
az aks disable-addons
medazure-keyvault-secrets-provider
tillägget .az aks disable-addons --addons azure-keyvault-secrets-provider --resource-group myResourceGroup --name myAKSCluster
Kommentar
När du inaktiverar tillägget bör befintliga arbetsbelastningar inte ha några problem eller se uppdateringar i de monterade hemligheterna. Om podden startas om eller en ny podd skapas som en del av uppskalningshändelsen startar inte podden eftersom drivrutinen inte längre körs.
Nästa steg
I den här artikeln har du lärt dig hur du skapar och tillhandahåller en identitet för åtkomst till ditt Azure Key Vault. Integreringen av Service Connector förenklar anslutningskonfigurationen för AKS-arbetsbelastningar och Azure-säkerhetskopieringstjänster. Den hanterar autentisering och nätverkskonfigurationer på ett säkert sätt och följer metodtipsen för att ansluta till Azure-tjänster. Mer information finns i Använda Azure Key Vault-providern för Secrets Store CSI-drivrutinen i ett AKS-kluster och introduktionen till Service Connector.
Om du vill konfigurera extra konfigurationsalternativ eller utföra felsökning läser du Konfigurationsalternativ och felsökning av resurser för Azure Key Vault-provider med Secrets Store CSI-drivrutin i AKS.
Azure Kubernetes Service
Feedback
https://aka.ms/ContentUserFeedback.
Kommer snart: Under hela 2024 kommer vi att fasa ut GitHub-problem som feedbackmekanism för innehåll och ersätta det med ett nytt feedbacksystem. Mer information finns i:Skicka och visa feedback för