Share via

Uw Azure-id-provider verbinden met het CSI-stuurprogramma van Azure Key Vault Secrets Store in Azure Kubernetes Service (AKS)

  • Artikel

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 OIDC-beveiligingsmodellen (OpenID Connect) voor toegang tot uw sleutelkluis en AKS-cluster.

U kunt een van de volgende toegangsmethoden gebruiken:

  • Serviceconnector met Workload-ID
  • Workload-ID
  • Door de gebruiker toegewezen beheerde identiteit

Leer hoe u verbinding maakt met Azure Key Vault met het stuurprogramma Secrets Store CSI in een AKS-cluster (Azure Kubernetes Service) met behulp van Service Connector. In dit artikel voert u de volgende taken uit:

  • Maak een AKS-cluster en een Azure Key Vault.
  • Maak een verbinding tussen het AKS-cluster en de Azure Key Vault met Service Connector.
  • Maak een SecretProviderClass CRD en een Pod provider die de CSI-provider gebruikt om de verbinding te testen.
  • Schoon resources op.

Belangrijk

AKS preview-functies zijn beschikbaar op selfservice, opt-in basis. Previews worden geleverd 'zoals is' en 'als beschikbaar' en ze worden uitgesloten van de serviceovereenkomsten en beperkte garantie. AKS-previews worden gedeeltelijk gedekt door klantondersteuning op basis van best effort. Daarom zijn deze functies niet bedoeld voor productiegebruik. Zie de volgende ondersteuningsartikelen voor meer informatie:

Vereisten

Azure-resources maken

  1. Maak een resourcegroep met behulp van de az group create opdracht.

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

  2. Maak een AKS-cluster met behulp van de az aks create opdracht. In het volgende voorbeeld wordt een AKS-cluster met één knooppunt gemaakt waarvoor beheerde identiteit is ingeschakeld.

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

  3. Maak verbinding met het cluster met behulp van de az aks get-credentials opdracht.

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

  4. Maak een Azure-sleutelkluis met behulp van de az keyvault create opdracht.

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

  5. Maak een geheim in de sleutelkluis met behulp van de az keyvault secret set opdracht.

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

Een serviceverbinding maken in AKS met Service Connector (preview)

U kunt een serviceverbinding maken met Azure Key Vault met behulp van Azure Portal of Azure CLI.

  1. Navigeer in Azure Portal naar uw AKS-clusterresource.

  2. Selecteer serviceconnector (preview)>maken in het servicemenu onder Instellingen.

  3. Configureer op de pagina Verbinding maken de volgende instellingen op het tabblad Basisbeginselen :

    • Kubernetes-naamruimte: selecteer de standaardwaarde.
    • Servicetype: Selecteer Key Vault en schakel het selectievakje in om de CSI-provider van Azure Key Vault in te schakelen.
    • Verbindingsnaam: Voer een naam in voor de verbinding.
    • Abonnement: selecteer het abonnement dat de sleutelkluis bevat.
    • Sleutelkluis: selecteer de sleutelkluis die u hebt gemaakt.
    • Clienttype: Selecteer Geen.

  4. Selecteer Beoordelen en maken en selecteer vervolgens Maken om de verbinding te maken.

Test de verbinding

De voorbeeldopslagplaats klonen en manifestbestanden implementeren

  1. Kloon de voorbeeldopslagplaats met behulp van de git clone opdracht.

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

  2. Wijzig mappen in het voorbeeld van de CSI-provider van Azure Key Vault.

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

  3. Vervang in het secret_provider_class.yaml bestand de volgende tijdelijke aanduidingen door uw Azure Key Vault-gegevens:

    • Vervang door <AZURE_KEYVAULT_NAME> de naam van de sleutelkluis die u hebt gemaakt en verbonden.
    • Vervang door <AZURE_KEYVAULT_TENANTID> de tenant-id van de sleutelkluis.
    • Vervang door <AZURE_KEYVAULT_CLIENTID> de id-client-id van de azureKeyvaultSecretsProvider invoegtoepassing.
    • Vervang door <KEYVAULT_SECRET_NAME> het sleutelkluisgeheim dat u hebt gemaakt. Bijvoorbeeld: ExampleSecret.

  4. Implementeer de SecretProviderClass CRD met behulp van de kubectl apply opdracht.

    kubectl apply -f secret_provider_class.yaml

  5. Implementeer het Pod manifestbestand met behulp van de kubectl apply opdracht.

    Met de opdracht maakt u een pod met de naam in sc-demo-keyvault-csi de standaardnaamruimte van uw AKS-cluster.

    kubectl apply -f pod.yaml

De verbinding controleren

  1. Controleer of de pod is gemaakt met behulp van de kubectl get opdracht.

    kubectl get pod/sc-demo-keyvault-csi

    Nadat de pod is gestart, is de gekoppelde inhoud op het volumepad dat is opgegeven in uw YAML-implementatie beschikbaar.

  2. Geef de geheimen weer die zijn opgeslagen in het geheimenarchief met behulp van de kubectl exec opdracht.

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

  3. Een geheim weergeven met behulp van de kubectl exec opdracht.

    In deze voorbeeldopdracht ziet u een testgeheim met de naam ExampleSecret.

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

Vereisten voor CSI-stuurprogramma

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

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

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

    Notitie

    In deze stap wordt ervan uitgegaan dat u een bestaand AKS-cluster hebt waarvoor de workloadidentiteit is ingeschakeld. Als u deze niet hebt ingeschakeld, raadpleegt u Workload-identiteit inschakelen op een bestaand AKS-cluster om dit in te schakelen.

    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. 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 gebruikt key of certificate typt, wijst u de Key Vault Certificate User rol toe om machtigingen te verlenen.
    • Als uw sleutelkluis is ingesteld met --enable-rbac-authorization en u het type gebruikt secret , wijst u de Key Vault Secrets User rol toe.
    • Als uw sleutelkluis niet is ingesteld met --enable-rbac-authorization, kunt u de az keyvault set-policy opdracht gebruiken met de --key-permissions get, --certificate-permissions getof --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

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

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

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

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

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

Vereisten voor CSI-stuurprogramma

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

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

    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 --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. 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 gebruikt key of certificate typt, wijst u de Key Vault Certificate User rol toe.
    • Als uw sleutelkluis is ingesteld met --enable-rbac-authorization en u het type gebruikt secret , wijst u de Key Vault Secrets User rol toe.
    • Als uw sleutelkluis niet is ingesteld met --enable-rbac-authorization, kunt u de az keyvault set-policy opdracht gebruiken met de --key-permissions get, --certificate-permissions getof --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 --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. 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.

  4. Pas het SecretProviderClass cluster toe met behulp van de kubectl apply opdracht.

    kubectl apply -f secretproviderclass.yaml

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

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

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

  2. 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 niet SecretProviderClass 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 --resource-group myResourceGroup --name 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. De serviceconnectorintegratie vereenvoudigt de verbindingsconfiguratie voor AKS-workloads en Azure-backingservices. Het verwerkt verificatie- en netwerkconfiguraties veilig en volgt aanbevolen procedures voor het maken van verbinding met Azure-services. Zie De Azure Key Vault-provider voor het CSI-stuurprogramma Secrets Store gebruiken in een AKS-cluster en de inleiding tot de Service Connector voor meer informatie.

Als u extra configuratieopties wilt configureren of problemen wilt oplossen, raadpleegt u Configuratieopties en probleemoplossingsbronnen voor de Azure Key Vault-provider met het stuurprogramma Secrets Store CSI in AKS.