Verbinding maken uw Azure-id-provider naar het CSI-stuurprogramma van Azure Key Vault Secrets Store in Azure Kubernetes Service (AKS)
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:
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.Belangrijk
- Als uw sleutelkluis is ingesteld en
--enable-rbac-authorization
u gebruiktkey
ofcertificate
typt, wijst u deKey Vault Certificate User
rol toe om machtigingen te verlenen. - Als uw sleutelkluis is ingesteld met
--enable-rbac-authorization
en u het type gebruiktsecret
, wijst u deKey Vault Secrets User
rol toe. - Als uw sleutelkluis niet is ingesteld met
--enable-rbac-authorization
, kunt u deaz keyvault set-policy
opdracht gebruiken met de--key-permissions get
,--certificate-permissions get
of--secret-permissions get
parameter om een sleutelkluisbeleid te maken om toegang te verlenen tot sleutels, certificaten of geheimen. Voorbeeld:
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
- Als uw sleutelkluis is ingesteld en
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
enserviceAccountNamespace
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 dekubectl 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 uobjectAlias
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 deobjects
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 identiteitenclientId
ophalen, die u in latere stappen gaat gebruiken bij het maken van eenSecretProviderClass
.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 identiteit machtigt voor toegang tot de sleutelkluisgeheimen, toegangssleutels en certificaten met behulp van de
az role assignment create
opdracht.Belangrijk
- Als uw sleutelkluis is ingesteld met
--enable-rbac-authorization
en u gebruiktkey
ofcertificate
typt, wijst u deKey Vault Certificate User
rol toe. - Als uw sleutelkluis is ingesteld met
--enable-rbac-authorization
en u het type gebruiktsecret
, wijst u deKey Vault Secrets User
rol toe. - Als uw sleutelkluis niet is ingesteld met
--enable-rbac-authorization
, kunt u deaz keyvault set-policy
opdracht gebruiken met de--key-permissions get
,--certificate-permissions get
of--secret-permissions get
parameter om een sleutelkluisbeleid te maken om toegang te verlenen tot sleutels, certificaten of geheimen. Voorbeeld:
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
- Als uw sleutelkluis is ingesteld met
Maak een
SecretProviderClass
met behulp van de volgende YAML. Zorg ervoor dat u uw eigen waarden gebruikt vooruserAssignedIdentityID
,keyvaultName
entenantId
de 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 vanobjectName
, 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 deobjects
sectie om de functies goed te laten functioneren.Pas het
SecretProviderClass
cluster toe met behulp van dekubectl 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
ExampleSecret
weergegeven.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 SecretProviderClass
te 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 deazure-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.