Verbinding maken uw Azure-id-provider naar het CSI-stuurprogramma van Azure Key Vault Secrets Store in Azure Kubernetes Service (AKS)

Artikel
03/10/2024

Het CSI-stuurprogramma (Secrets Store Container Storage Interface) in Azure Kubernetes Service (AKS) biedt verschillende methoden voor toegang op basis van identiteiten tot uw Azure Key Vault. In dit artikel worden deze methoden en aanbevolen procedures beschreven voor het gebruik van op rollen gebaseerd toegangsbeheer (RBAC) of OpenID Verbinding maken -beveiligingsmodellen (OIDC) voor toegang tot uw sleutelkluis en AKS-cluster.

U kunt een van de volgende toegangsmethoden gebruiken:

Microsoft Entra Workload-ID
Door de gebruiker toegewezen beheerde identiteit

Vereisten voor CSI-stuurprogramma

Voordat u begint, moet u de stappen in De Azure Key Vault-provider gebruiken voor het CSI-stuurprogramma Secrets Store in een AKS-cluster (Azure Kubernetes Service) voltooien om het CSI-stuurprogramma van Azure Key Vault Secrets Store in te schakelen in uw AKS-cluster.

Toegang met een Microsoft Entra Workload-ID

Een Microsoft Entra Workload-ID is een identiteit die een toepassing die op een pod wordt uitgevoerd, gebruikt om zichzelf te verifiëren bij andere Azure-services, zoals workloads in software. Het CSI-stuurprogramma secret store integreert met systeemeigen Kubernetes-mogelijkheden om te federeren met externe id-providers.

In dit beveiligingsmodel fungeert het AKS-cluster als tokenverlener. Microsoft Entra ID gebruikt vervolgens OIDC om openbare ondertekeningssleutels te detecteren en de echtheid van het serviceaccounttoken te verifiëren voordat het wordt uitgewisseld voor een Microsoft Entra-token. Als u een serviceaccounttoken wilt uitwisselen dat is geprojecteerd naar het volume voor een Microsoft Entra-token, hebt u de Azure Identity-clientbibliotheek nodig in de Azure SDK of de Microsoft Authentication Library (MSAL)

Notitie

Deze verificatiemethode vervangt de door Microsoft Entra beheerde identiteit (preview). De open source door Microsoft Entra beheerde identiteit (preview) in Azure Kubernetes Service is vanaf 10-24-2022 afgeschaft.
Microsoft Entra Workload-ID ondersteunt zowel Windows- als Linux-clusters.

Workloadidentiteit configureren

Stel uw abonnement in met behulp van de az account set opdracht.

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

Maak een beheerde identiteit met behulp van de az identity create opdracht.

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)

Maak een roltoewijzing die de identiteitsmachtiging van de workload verleent voor toegang tot de sleutelkluisgeheimen, toegangssleutels en certificaten met behulp van de az role assignment create opdracht.

export KEYVAULT_SCOPE=$(az keyvault show --name $KEYVAULT_NAME --query id -o tsv)

az role assignment create --role "Key Vault Administrator" --assignee $USER_ASSIGNED_CLIENT_ID --scope $KEYVAULT_SCOPE

Haal de URL van de AKS-cluster-OIDC Issuer op met behulp van de az aks show opdracht.

Notitie

In deze stap wordt ervan uitgegaan dat u een bestaand AKS-cluster hebt waarvoor de URL van de OIDC-verlener is ingeschakeld. Als u dit niet hebt ingeschakeld, raadpleegt u Een AKS-cluster bijwerken met OIDC Issuer om dit in te schakelen.
```
export AKS_OIDC_ISSUER="$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query "oidcIssuerProfile.issuerUrl" -o tsv)"
echo $AKS_OIDC_ISSUER
```

Stel een federatieve identiteitsreferentie in tussen de Microsoft Entra-toepassing, de uitgever van het serviceaccount en het onderwerp. Haal de object-id van de Microsoft Entra-toepassing op met behulp van de volgende opdrachten. Zorg ervoor dat u de waarden voor serviceAccountName en serviceAccountNamespace met de naam van het Kubernetes-serviceaccount en de bijbehorende naamruimte bijwerkt.

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

Maak de federatieve identiteitsreferentie tussen de beheerde identiteit, de verlener van het serviceaccount en het onderwerp met behulp van de az identity federated-credential create opdracht.

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}

Implementeer een SecretProviderClass met behulp van de kubectl apply opdracht en het volgende YAML-script.

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

Notitie

Als u in plaats van objectName, werkt u objectAlias het YAML-script bij om er rekening mee te houden.

Notitie

SecretProviderClass Zorg ervoor dat u uw Azure Key Vault vult met geheimen, sleutels of certificaten voordat u ernaar verwijst in de objects sectie om de functies goed te laten functioneren.

Implementeer een voorbeeldpod met behulp van de kubectl apply opdracht en het volgende YAML-script.

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

Toegang met beheerde identiteit

Een door Microsoft Entra beheerde id is een identiteit die een beheerder gebruikt om zichzelf te verifiëren bij andere Azure-services. De beheerde identiteit maakt gebruik van RBAC om te federeren met externe id-providers.

In dit beveiligingsmodel kunt u toegang verlenen tot de resources van uw cluster aan teamleden of tenants die een beheerde rol delen. De rol wordt gecontroleerd op het bereik voor toegang tot de sleutelkluis en andere referenties. Wanneer u de Azure Key Vault-provider hebt ingeschakeld voor het CSI-stuurprogramma Secrets Store in uw AKS-cluster, is er een gebruikersidentiteit gemaakt.

Beheerde identiteit configureren

Open uw sleutelkluis met behulp van de az aks show opdracht en de door de gebruiker toegewezen beheerde identiteit die door de invoegtoepassing is gemaakt. U moet ook de identiteiten clientIdophalen, die u in latere stappen gaat gebruiken bij het maken van een 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

U kunt ook een nieuwe beheerde identiteit maken en deze toewijzen aan uw virtuele-machineschaalset (VM) of aan elk VM-exemplaar in uw beschikbaarheidsset met behulp van de volgende opdrachten.

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

Maak een roltoewijzing die de identiteitsmachtiging toegang verleent tot de sleutelkluisgeheimen, toegangssleutels en certificaten met behulp van de az role assignment create opdracht.

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)

az role assignment create --role "Key Vault Administrator" --assignee $IDENTITY_OBJECT_ID --scope $KEYVAULT_SCOPE

Maak een SecretProviderClass met behulp van de volgende YAML. Zorg ervoor dat u uw eigen waarden gebruikt voor userAssignedIdentityID, keyvaultNameen tenantIdde objecten die u uit uw sleutelkluis wilt ophalen.

# 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

Notitie

Als u objectAlias in plaats van objectName, zorg ervoor dat u het YAML-script bijwerkt.

Notitie

SecretProviderClass Zorg ervoor dat u uw Azure Key Vault vult met geheimen, sleutels of certificaten voordat u ernaar verwijst in de objects sectie om de functies goed te laten functioneren.

Pas het SecretProviderClass cluster toe met behulp van de kubectl apply opdracht.
```
kubectl apply -f secretproviderclass.yaml
```

Maak een pod met behulp van de volgende 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"

Pas de pod toe op uw cluster met behulp van de kubectl apply opdracht.
```
kubectl apply -f pod.yaml
```

Key Vault-geheimen valideren

Nadat de pod is gestart, is de gekoppelde inhoud op het volumepad dat is opgegeven in uw YAML-implementatie beschikbaar. Gebruik de volgende opdrachten om uw geheimen te valideren en een testgeheim af te drukken.

Geef geheimen weer die zijn opgeslagen in het geheimenarchief met behulp van de volgende opdracht.
```
kubectl exec busybox-secrets-store-inline-user-msi -- ls /mnt/secrets-store/
```
Geef een geheim weer in de store met behulp van de volgende opdracht. Met deze voorbeeldopdracht wordt het testgeheim ExampleSecretweergegeven.
```
kubectl exec busybox-secrets-store-inline-user-msi -- cat /mnt/secrets-store/ExampleSecret
```

Certificaten en sleutels verkrijgen

Het ontwerp van Azure Key Vault maakt scherp onderscheid tussen sleutels, geheimen en certificaten. De certificaatfuncties van de Key Vault-service zijn ontworpen om gebruik te maken van de belangrijkste en geheime mogelijkheden. Wanneer u een sleutelkluiscertificaat maakt, wordt er een adresseerbare sleutel en geheim met dezelfde naam gemaakt. Deze sleutel staat verificatiebewerkingen toe en het geheim staat het ophalen van de certificaatwaarde toe als geheim.

Een sleutelkluiscertificaat bevat ook openbare x509-certificaatmetagegevens. De sleutelkluis slaat zowel de openbare als de persoonlijke onderdelen van uw certificaat op in een geheim. U kunt elk afzonderlijk onderdeel verkrijgen door het objectType in SecretProviderClasste specificeren. In de volgende tabel ziet u welke objecten zijn toegewezen aan de verschillende resources die aan uw certificaat zijn gekoppeld:

Object	Retourwaarde	Retourneert de volledige certificaatketen
`key`	De openbare sleutel, in PEM-indeling (Privacy Enhanced Mail).	N.v.t.
`cert`	Het certificaat, in PEM-indeling.	Nee
`secret`	De persoonlijke sleutel en het certificaat, in PEM-indeling.	Ja

De invoegtoepassing op bestaande clusters uitschakelen

Notitie

Voordat u de invoegtoepassing uitschakelt, moet u ervoor zorgen dat de invoegtoepassing nietSecretProviderClass wordt gebruikt. Als u de invoegtoepassing probeert uit te schakelen terwijl er een SecretProviderClass bestaat, treedt er een fout op.

Schakel de Azure Key Vault-provider voor het stuurprogramma Secrets Store CSI uit in een bestaand cluster met behulp van de az aks disable-addons opdracht met de azure-keyvault-secrets-provider invoegtoepassing.
```
az aks disable-addons --addons azure-keyvault-secrets-provider -g myResourceGroup -n myAKSCluster
```

Notitie

Wanneer u de invoegtoepassing uitschakelt, moeten bestaande workloads geen problemen hebben of updates in de gekoppelde geheimen zien. Als de pod opnieuw wordt opgestart of als onderdeel van de opschaalgebeurtenis een nieuwe pod wordt gemaakt, kan de pod niet worden gestart omdat het stuurprogramma niet meer wordt uitgevoerd.

Volgende stappen

In dit artikel hebt u geleerd hoe u een identiteit kunt maken en opgeven voor toegang tot uw Azure Key Vault. Als u extra configuratieopties wilt configureren of probleemoplossing wilt uitvoeren, gaat u verder met het volgende artikel.

Configuratieopties en probleemoplossingsbronnen voor De Azure Key Vault-provider met het stuurprogramma Secrets Store CSI in AKS

Verbinding maken uw Azure-id-provider naar het CSI-stuurprogramma van Azure Key Vault Secrets Store in Azure Kubernetes Service (AKS)

Vereisten voor CSI-stuurprogramma

Toegang met een Microsoft Entra Workload-ID

Workloadidentiteit configureren

Toegang met beheerde identiteit

Beheerde identiteit configureren

Key Vault-geheimen valideren

Certificaten en sleutels verkrijgen

De invoegtoepassing op bestaande clusters uitschakelen

Volgende stappen

Aanvullende resources