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:

• Tjänstanslutning med arbetsbelastnings-ID
• Arbetsbelastnings-ID
• Användartilldelad hanterad identitet

Lär dig hur du ansluter till Azure Key Vault med CSI-drivrutinen för Secrets Store i ett AKS-kluster (Azure Kubernetes Service) med hjälp av Service Connector. I den här artikeln utför du följande uppgifter:

• Skapa ett AKS-kluster och ett Azure Key Vault.
• Skapa en anslutning mellan AKS-klustret och Azure Key Vault med Service Connector.
• Skapa en SecretProviderClass CRD och en Pod som använder CSI-providern för att testa anslutningen.
• Rensa resurser.

Viktigt!

AKS-förhandsversionsfunktioner är tillgängliga via självbetjäning och anmäl dig. Förhandsversioner tillhandahålls "som är" och "som tillgängliga", och de undantas från serviceavtalen och den begränsade garantin. AKS-förhandsversioner omfattas delvis av kundsupport på bästa sätt. Därför är dessa funktioner inte avsedda för produktionsanvändning. Mer information finns i följande supportartiklar:

• AKS supportpolicyer
• Vanliga frågor och svar om Azure Support

Förutsättningar

• Ett Azure-konto med en aktiv prenumeration. Skapa ett konto utan kostnad.
• Azure CLI. Logga in med kommandot az login .
• Docker och kubectl. Om du vill installera kubectl lokalt använder du az aks install-cli kommandot .
• Grundläggande förståelse för containrar och AKS. Kom igång genom att förbereda ett program för AKS.
• 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.

Inledande konfiguration

1. Om du använder Service Connector för första gången börjar du med att köra kommandot az provider register för att registrera resursprovidrar för Service Connector och Kubernetes Configuration.

   az provider register -n Microsoft.ServiceLinker
   

   az provider register -n Microsoft.KubernetesConfiguration
   

   Dricks

   Du kan kontrollera om dessa resursprovidrar redan har registrerats genom att köra kommandona az provider show -n "Microsoft.ServiceLinker" --query registrationState och az provider show -n "Microsoft.KubernetesConfiguration" --query registrationState.

2. Du kan också använda Azure CLI-kommandot för att hämta en lista över måltjänster som stöds för AKS-kluster.

   az aks connection list-support-types --output table
   

Skapa Azure-resurser

1. Skapa en resursgrupp med kommandot az group create .

   az group create \
       --name <resource-group-name> \
       --location <location>
   

2. Skapa ett AKS-kluster med kommandot az aks create . I följande exempel skapas ett AKS-kluster med en nod med hanterad identitet aktiverat.

   az aks create \
       --resource-group <resource-group-name> \
       --name <cluster-name> \
       --enable-managed-identity \
       --node-count 1
   

3. Anslut till klustret med kommandot az aks get-credentials .

   az aks get-credentials \
       --resource-group <resource-group-name> \
       --name <cluster-name>
   

4. Skapa ett Azure-nyckelvalv med kommandot az keyvault create .

   az keyvault create \
       --resource-group <resource-group-name> \  
       --name <key-vault-name> \
       --location <location>
   

5. Skapa en hemlighet i nyckelvalvet med kommandot az keyvault secret set .

   az keyvault secret set \
       --vault-name <key-vault-name> \
       --name <secret-name> \
       --value <secret-value>
   

Skapa en tjänstanslutning i AKS med Service Connector (förhandsversion)

Du kan skapa en tjänstanslutning till Azure Key Vault med hjälp av Azure Portal eller Azure CLI.

Azure-portalen

1. I Azure Portal navigerar du till aks-klusterresursen.

2. På tjänstmenyn går du till Inställningar och väljer Tjänstanslutning (förhandsversion)>Skapa.

3. På sidan Skapa anslutning konfigurerar du följande inställningar på fliken Grundläggande :

   • Kubernetes-namnområde: Välj standard.
   • Tjänsttyp: Välj Key Vault och markera kryssrutan för att aktivera Azure Key Vault CSI-providern.
   • Anslutningsnamn: Ange ett namn för anslutningen.
   • Prenumeration: Välj den prenumeration som innehåller nyckelvalvet.
   • Nyckelvalv: Välj det nyckelvalv som du skapade.
   • Klienttyp: Välj Ingen.

4. Välj Granska + skapa och välj sedan Skapa för att skapa anslutningen.

Azure CLI

• Skapa en anslutning till ditt nyckelvalv med hjälp av az aks connection create keyvault kommandot .

  az aks connection create keyvault \
      --connection <connection-name> \
      --resource-group <resource-group-of-cluster> \
      --name <cluster-name> \
      --target-resource-group <resource-group-of-key-vault> \
      --vault <key-vault-name> \
      --enable-csi \
      --client-type none
  
  

Testa anslutningen

Klona exempellagringsplatsen och distribuera manifestfiler

1. Klona exempellagringsplatsen med kommandot git clone .

   git clone https://github.com/Azure-Samples/serviceconnector-aks-samples.git
   

2. Ändra kataloger till Azure Key Vault CSI-providerexemplet.

   cd serviceconnector-aks-samples/azure-keyvault-csi-provider
   

3. secret_provider_class.yaml Ersätt följande platshållare i filen med din Azure Key Vault-information:

   • Ersätt <AZURE_KEYVAULT_NAME> med namnet på nyckelvalvet som du skapade och anslöt.
   • Ersätt <AZURE_KEYVAULT_TENANTID> med klientorganisations-ID:t för nyckelvalvet.
   • Ersätt <AZURE_KEYVAULT_CLIENTID> med identitetsklient-ID för azureKeyvaultSecretsProvider tillägget.
   • Ersätt <KEYVAULT_SECRET_NAME> med den nyckelvalvshemlighet som du skapade. Exempel: ExampleSecret

4. SecretProviderClass Distribuera CRD med kommandot kubectl apply .

   kubectl apply -f secret_provider_class.yaml
   

5. Pod Distribuera manifestfilen med kommandot kubectl apply .

   Kommandot skapar en podd med namnet sc-demo-keyvault-csi i standardnamnområdet för aks-klustret.

   kubectl apply -f pod.yaml
   

Verifiera anslutningen

1. Kontrollera att podden har skapats med kommandot kubectl get .

   kubectl get pod/sc-demo-keyvault-csi
   

   När podden har startats är det monterade innehållet på den volymsökväg som anges i din distributions-YAML tillgängligt.

2. Visa hemligheterna i hemlighetsarkivet med hjälp av kubectl exec kommandot .

   kubectl exec sc-demo-keyvault-csi -- ls /mnt/secrets-store/
   

3. Visa en hemlighet med kommandot kubectl exec .

   Det här exempelkommandot visar en testhemlighet med namnet ExampleSecret.

   kubectl exec sc-demo-keyvault-csi -- cat /mnt/secrets-store/ExampleSecret
   

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.
• Microsoft Entra-arbetsbelastnings-ID stöder både Windows- och Linux-kluster.

Å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). Den öppen källkod Microsoft Entra-poddhanterade identiteten (förhandsversion) i Azure Kubernetes Service har 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

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

2. Skapa en hanterad identitet med kommandot az identity create .

   Kommentar

   Det här steget förutsätter att du har ett befintligt AKS-kluster med arbetsbelastningsidentitet aktiverad. Om du inte har aktiverat den kan du läsa Aktivera arbetsbelastningsidentitet i ett befintligt AKS-kluster för att aktivera den.

   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)
   

3. 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änder key eller certificate skriver tilldelar Key Vault Certificate User du rollen för att ge behörigheter.
   • Om ditt nyckelvalv har angetts med --enable-rbac-authorization och du använder secret typ tilldelar Key Vault Secrets User du rollen.
   • Om nyckelvalvet inte har angetts med --enable-rbac-authorizationkan du använda az keyvault set-policy kommandot med parametern --key-permissions get, --certificate-permissions geteller --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
   

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

5. 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 och serviceAccountNamespace 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
   

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

7. Distribuera en SecretProviderClass med hjälp av kubectl 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ör objectNameuppdaterar 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 i objects avsnittet.

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

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

1. 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 identitetens clientId, som du ska använda i senare steg när du skapar en SecretProviderClass.

   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
   

2. 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änder key eller certificate skriver tilldelar Key Vault Certificate User du rollen.
   • Om ditt nyckelvalv har angetts med --enable-rbac-authorization och du använder secret typ tilldelar Key Vault Secrets User du rollen.
   • Om nyckelvalvet inte har angetts med --enable-rbac-authorizationkan du använda az keyvault set-policy kommandot med parametern --key-permissions get, --certificate-permissions geteller --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
   

3. Skapa en SecretProviderClass med hjälp av följande YAML. Se till att använda dina egna värden för userAssignedIdentityID, keyvaultName, tenantIdoch 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ör objectNamemå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 i objects avsnittet.

4. Använd på SecretProviderClass klustret med hjälp av kubectl apply kommandot .

   kubectl apply -f secretproviderclass.yaml
   

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

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

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

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