Anslut din Azure-identitetsprovider till Azure Key Vault Secrets Store CSI-drivrutinen i Azure Kubernetes Service (AKS)

Artikel
05/03/2024

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 rbac-säkerhetsmodeller (Rollbaserad åtkomstkontroll) eller OpenID Anslut (OIDC) för åtkomst till nyckelvalvet och AKS-klustret.

Du kan använda någon av följande åtkomstmetoder:

Microsoft Entra-arbetsbelastnings-ID
Användartilldelad hanterad identitet

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

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 -g $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ä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
```
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 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

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

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

az aks show -g <resource-group> -n <cluster-name> --query addonProfiles.azureKeyvaultSecretsProvider.identity.objectId -o tsv
az aks show -g <resource-group> -n <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 -g <resource-group> -n <identity-name>
az vmss identity assign -g <resource-group> -n <agent-pool-vmss> --identities <identity-resource-id>
az vm identity assign -g <resource-group> -n <agent-pool-vm> --identities <identity-resource-id>

az identity show -g <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ä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 -g <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
```

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.

Använd på SecretProviderClass klustret med hjälp av kubectl 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 ingetSecretProviderClass 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 -g myResourceGroup -n 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. Om du vill konfigurera extra konfigurationsalternativ eller utföra felsökning fortsätter du till nästa artikel.

Konfigurationsalternativ och felsökning av resurser för Azure Key Vault-provider med CSI-drivrutin för Secrets Store i AKS

Anslut din Azure-identitetsprovider till Azure Key Vault Secrets Store CSI-drivrutinen i Azure Kubernetes Service (AKS)

Förutsättningar för CSI-drivrutin

Åtkomst med ett Microsoft Entra-arbetsbelastnings-ID

Konfigurera arbetsbelastningsidentitet

Åtkomst med hanterad identitet

Konfigurera hanterad identitet

Verifiera Key Vault-hemligheter

Hämta certifikat och nycklar

Inaktivera tillägget i befintliga kluster

Nästa steg

Ytterligare resurser