Megosztás a következőn keresztül:


Azure-identitásszolgáltató csatlakoztatása az Azure Key Vault titkos kulcstár CSI-illesztőprogramjához az Azure Kubernetes Service-ben (AKS)

Az Azure Kubernetes Service (AKS) Titkos tár tárolótároló-illesztője (CSI) illesztőprogramja különböző identitásalapú hozzáférést biztosít az Azure Key Vaulthoz. Ez a cikk ezeket a módszereket és ajánlott eljárásokat ismerteti, hogy mikor érdemes szerepköralapú hozzáférés-vezérlési (RBAC) vagy OpenID Connect (OIDC) biztonsági modelleket használni a kulcstartóhoz és az AKS-fürthöz való hozzáféréshez.

A következő hozzáférési módszerek egyikét használhatja:

  • Service Connector felügyelt identitással
  • Számítási feladat ID
  • Felhasználó által hozzárendelt felügyelt identitás

Megtudhatja, hogyan csatlakozhat az Azure Key Vaulthoz a Titkos kulcstár CSI-illesztőprogramjával egy Azure Kubernetes Service-fürtben a Service Connector használatával. Ebben a cikkben a következő feladatokat hajtja végre:

  • Hozzon létre egy AKS-fürtöt és egy Azure Key Vaultot.
  • Hozzon létre kapcsolatot az AKS-fürt és az Azure Key Vault és a Service Connector között.
  • Hozzon létre egy SecretProviderClass CRD-t és egy olyant Pod , amely a CSI-szolgáltatót használja a kapcsolat teszteléséhez.
  • Az erőforrások eltávolítása.

Fontos

Az AKS előzetes verziójú funkciói önkiszolgáló, opt-in alapon érhetők el. Az előzetes verziókat "ahogy van" és "rendelkezésre állóként" biztosítjuk, és a szolgáltatási szerződésekből és a korlátozott jótállásból kizárjuk őket. Az AKS előzetes verzióit részben az ügyfélszolgálat fedezi a legjobb munkamennyiség alapján. Ezért ezek a funkciók nem éles használatra vannak szánva. További információkért tekintse meg az alábbi támogatási cikkeket:

Előfeltételek

Kezdeti beállítás

  1. Ha először használja a Service Connectort, először futtassa az az provider register parancsot a Service Connector és a Kubernetes Configuration erőforrás-szolgáltatók regisztrálásához.

    az provider register -n Microsoft.ServiceLinker
    
    az provider register -n Microsoft.KubernetesConfiguration
    

    Tipp.

    A parancsok és a parancsok az provider show -n "Microsoft.ServiceLinker" --query registrationState az provider show -n "Microsoft.KubernetesConfiguration" --query registrationStatefuttatásával ellenőrizheti, hogy ezek az erőforrás-szolgáltatók már regisztrálva lettek-e.

  2. Ha szeretné, az Azure CLI-paranccsal lekérheti az AKS-fürt támogatott célszolgáltatásainak listáját.

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

Azure-erőforrások létrehozása

  1. Hozzon létre egy erőforráscsoportot a az group create paranccsal.

    az group create \
        --name <resource-group-name> \
        --location <location>
    
  2. Hozzon létre egy AKS-fürtöt a az aks create paranccsal. Az alábbi példa egy egycsomópontos AKS-fürtöt hoz létre, amelyen engedélyezve van a felügyelt identitás.

    az aks create \
        --resource-group <resource-group-name> \
        --name <cluster-name> \
        --enable-managed-identity \
        --node-count 1
    
  3. Csatlakozzon a fürthöz a az aks get-credentials parancs használatával.

    az aks get-credentials \
        --resource-group <resource-group-name> \
        --name <cluster-name>
    
  4. Hozzon létre egy Azure Key Vaultot a az keyvault create paranccsal.

    az keyvault create \
        --resource-group <resource-group-name> \  
        --name <key-vault-name> \
        --location <location>
    
  5. Hozzon létre egy titkos kulcsot a kulcstartóban a az keyvault secret set paranccsal.

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

Szolgáltatáskapcsolat létrehozása az AKS-ben a Service Connector használatával (előzetes verzió)

Szolgáltatáskapcsolatot hozhat létre az Azure Key Vaulttal az Azure Portal vagy az Azure CLI használatával.

  1. Az Azure Portalon keresse meg az AKS-fürterőforrást.

  2. A szolgáltatásmenü Beállítások területén válassza a Szolgáltatásösszekötő (előzetes verzió)>Létrehozás lehetőséget.

  3. A Kapcsolat létrehozása lapon konfigurálja a következő beállításokat az Alapszintű beállítások lapon:

    • Kubernetes-névtér: Válassza ki az alapértelmezett értéket.
    • Szolgáltatás típusa: Válassza a Key Vaultot, és jelölje be a jelölőnégyzetet az Azure Key Vault CSI-szolgáltató engedélyezéséhez.
    • Kapcsolat neve: Adja meg a kapcsolat nevét.
    • Előfizetés: Válassza ki a kulcstartót tartalmazó előfizetést.
    • Key Vault: Válassza ki a létrehozott kulcstartót.
    • Ügyfél típusa: Válassza a Nincs lehetőséget.
  4. Válassza a Véleményezés + létrehozás, majd a Létrehozás lehetőséget a kapcsolat létrehozásához.

A kapcsolat tesztelése

A mintaadattár klónozása és jegyzékfájlok üzembe helyezése

  1. Klónozza a mintaadattárat a git clone paranccsal.

    git clone https://github.com/Azure-Samples/serviceconnector-aks-samples.git
    
  2. Módosítsa a címtárakat az Azure Key Vault CSI-szolgáltatói mintájára.

    cd serviceconnector-aks-samples/azure-keyvault-csi-provider
    
  3. A fájlban secret_provider_class.yaml cserélje le a következő helyőrzőket az Azure Key Vault adataira:

    • Cserélje le <AZURE_KEYVAULT_NAME> a létrehozott és csatlakoztatott kulcstartó nevére.
    • Cserélje le <AZURE_KEYVAULT_TENANTID> a kulcstartó bérlőazonosítójára.
    • Cserélje le <AZURE_KEYVAULT_CLIENTID> a azureKeyvaultSecretsProvider bővítmény identitásügyfél-azonosítójára.
    • Cserélje le <KEYVAULT_SECRET_NAME> a létrehozott kulcstartó titkos kódjára. Például: ExampleSecret.
  4. Telepítse a SecretProviderClass CRD-t a kubectl apply paranccsal.

    kubectl apply -f secret_provider_class.yaml
    
  5. Helyezze üzembe a Pod jegyzékfájlt a kubectl apply paranccsal.

    A parancs létrehoz egy podot sc-demo-keyvault-csi az AKS-fürt alapértelmezett névterében.

    kubectl apply -f pod.yaml
    

A kapcsolat ellenőrzése

  1. Ellenőrizze, hogy a pod sikeresen létrejött-e a kubectl get paranccsal.

    kubectl get pod/sc-demo-keyvault-csi
    

    A pod elindítása után a csatlakoztatott tartalom az üzembe helyezési YAML-ben megadott kötetútvonalon érhető el.

  2. A parancs használatával kubectl exec megjelenítheti a titkos kulcstárban tárolt titkos kulcsokat.

    kubectl exec sc-demo-keyvault-csi -- ls /mnt/secrets-store/
    
  3. A parancs használatával kubectl exec megjeleníthet egy titkos kulcsot.

    Ez a példaparancs egy teszttitkot mutat be ExampleSecret.

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

A CSI-illesztőprogram előfeltételei

Hozzáférés Microsoft Entra Számítási feladat ID

A Microsoft Entra Számítási feladat ID egy olyan identitás, amelyet egy podon futó alkalmazás más Azure-szolgáltatásokon, például a szoftverbeli számítási feladatokon való hitelesítésre használ. A Titkos tár CSI-illesztőprogramja integrálható a natív Kubernetes-képességekkel a külső identitásszolgáltatókkal való összevonáshoz.

Ebben a biztonsági modellben az AKS-fürt jogkivonat-kiállítóként működik. A Microsoft Entra ID ezután az OIDC használatával felderíti a nyilvános aláíró kulcsokat, és ellenőrzi a szolgáltatásfiók jogkivonatának hitelességét, mielőtt kicseréli azt egy Microsoft Entra-jogkivonatra. Ahhoz, hogy a számítási feladat egy Microsoft Entra-jogkivonatra előrejelzett szolgáltatásfiók-jogkivonatot cseréljen, szüksége lesz az Azure Identity ügyfélkódtárára az Azure SDK-ban vagy a Microsoft Authentication Libraryben (MSAL)

Feljegyzés

  • Ez a hitelesítési módszer felváltja a Microsoft Entra pod által felügyelt identitást (előzetes verzió). Az Azure Kubernetes Service nyílt forráskód Microsoft Entra pod által felügyelt identitása (előzetes verzió) 2022. 10. 24-én elavult.
  • Microsoft Entra Számítási feladat ID Windows- és Linux-fürtöket is támogat.

Számítási feladat identitásának konfigurálása

  1. Állítsa be az előfizetést a az account set paranccsal.

    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. Felügyelt identitás létrehozása a az identity create paranccsal.

    Feljegyzés

    Ez a lépés feltételezi, hogy rendelkezik egy meglévő AKS-fürttel, amelyen engedélyezve van a számítási feladatok identitása. Ha nincs engedélyezve, a tevékenységprofil-identitás engedélyezése meglévő AKS-fürtön című témakörben olvashat.

    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. Hozzon létre egy szerepkör-hozzárendelést, amely engedélyt ad a számítási feladat identitásának a kulcstartó titkos kulcsainak, hozzáférési kulcsainak és tanúsítványainak a az role assignment create parancs használatával való elérésére.

    Fontos

    • Ha a kulcstartó be van állítva --enable-rbac-authorization , és ön használja key vagy certificate írja be, rendelje hozzá a szerepkört az Key Vault Certificate User engedélyek megadása érdekében.
    • Ha a kulcstartó be van állítva --enable-rbac-authorization , és ön típust használ secret , rendelje hozzá a szerepkört Key Vault Secrets User .
    • Ha a kulcstartó nincs beállítva--enable-rbac-authorization, a az keyvault set-policy paranccsal a , --certificate-permissions getvagy --secret-permissions get paraméterrel --key-permissions getlétrehozhat egy kulcstartó-szabályzatot, amely hozzáférést biztosít a kulcsokhoz, tanúsítványokhoz vagy titkos kulcsokhoz. Példa:
    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. Kérje le az AKS-fürt OIDC-kiállítójának URL-címét a az aks show paranccsal.

    Feljegyzés

    Ez a lépés feltételezi, hogy rendelkezik egy meglévő AKS-fürttel, amelyen engedélyezve van az OIDC-kiállító URL-címe. Ha nincs engedélyezve, az engedélyezéséhez tekintse meg az AKS-fürt OIDC-kiállítóval való frissítését.

    export AKS_OIDC_ISSUER="$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query "oidcIssuerProfile.issuerUrl" -o tsv)"
    echo $AKS_OIDC_ISSUER
    
  5. Összevont identitás-hitelesítő adatok létrehozása a Microsoft Entra-alkalmazás, a szolgáltatásfiók-kiállító és a tulajdonos között. Kérje le a Microsoft Entra-alkalmazás objektumazonosítóját az alábbi parancsokkal. Mindenképpen frissítse a serviceAccountName Kubernetes-szolgáltatásfiók nevét és serviceAccountNamespace névterét.

    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. Hozza létre az összevont identitás hitelesítő adatait a felügyelt identitás, a szolgáltatásfiók kiállítója és a tulajdonos között a az identity federated-credential create parancs használatával.

    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. Helyezzen üzembe egy SecretProviderClass kubectl apply parancsot és a következő YAML-szkriptet.

    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
    

    Feljegyzés

    Ha ahelyett objectNamehasználjaobjectAlias, frissítse a YAML-szkriptet, hogy elszámoljon vele.

    Feljegyzés

    A megfelelő működés érdekében SecretProviderClass a szakaszban való hivatkozás objects előtt mindenképpen töltse fel az Azure Key Vaultot titkos kulcsokkal, kulcsokkal vagy tanúsítványokkal.

  8. Helyezzen üzembe egy minta podot a kubectl apply parancs és a következő YAML-szkript használatával.

    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
    

A CSI-illesztőprogram előfeltételei

Hozzáférés felügyelt identitással

A Microsoft Entra felügyelt azonosítója olyan identitás, amelyet a rendszergazda más Azure-szolgáltatásokon való hitelesítéshez használ. A felügyelt identitás RBAC-t használ a külső identitásszolgáltatókkal való összevonáshoz.

Ebben a biztonsági modellben hozzáférést adhat a fürt erőforrásaihoz a felügyelt szerepkörrel rendelkező csapattagoknak vagy bérlőknek. A rendszer ellenőrzi a szerepkör hatókörét a kulcsvaulthoz és más hitelesítő adatokhoz való hozzáféréshez. Amikor engedélyezte az Azure Key Vault-szolgáltatót a Titkos kulcstár CSI-illesztőprogramjához az AKS-fürtön, létrehozott egy felhasználói identitást.

Felügyelt identitás konfigurálása

  1. A kulcstartó elérése a az aks show bővítmény által létrehozott parancs és a felhasználó által hozzárendelt felügyelt identitás használatával. Le kell kérnie az identitásokat clientIdis, amelyeket a későbbi lépésekben fog használni egy 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
    

    Másik lehetőségként létrehozhat egy új felügyelt identitást, és hozzárendelheti azt a virtuálisgép-méretezési csoporthoz vagy a rendelkezésre állási csoport egyes virtuálisgép-példányaihoz az alábbi parancsokkal.

    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. Hozzon létre egy szerepkör-hozzárendelést, amely engedélyezi az identitás számára a kulcstartó titkos kulcsainak, hozzáférési kulcsainak és tanúsítványainak elérését a az role assignment create parancs használatával.

    Fontos

    • Ha a kulcstartó be van állítva --enable-rbac-authorization , és ön használja key vagy certificate írja be, rendelje hozzá a szerepkört Key Vault Certificate User .
    • Ha a kulcstartó be van állítva --enable-rbac-authorization , és ön típust használ secret , rendelje hozzá a szerepkört Key Vault Secrets User .
    • Ha a kulcstartó nincs beállítva--enable-rbac-authorization, a az keyvault set-policy paranccsal a , --certificate-permissions getvagy --secret-permissions get paraméterrel --key-permissions getlétrehozhat egy kulcstartó-szabályzatot, amely hozzáférést biztosít a kulcsokhoz, tanúsítványokhoz vagy titkos kulcsokhoz. Példa:
    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. Hozzon létre egy SecretProviderClass elemet a következő YAML használatával. Ügyeljen arra, hogy a kulcstartóból lekérendő objektumokhoz userAssignedIdentityIDkeyvaultNametenantIdsaját értékeket használjon.

    # 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
    

    Feljegyzés

    Ha ahelyett objectNamehasználjaobjectAlias, frissítse a YAML-szkriptet.

    Feljegyzés

    A megfelelő működés érdekében SecretProviderClass a szakaszban való hivatkozás objects előtt mindenképpen töltse fel az Azure Key Vaultot titkos kulcsokkal, kulcsokkal vagy tanúsítványokkal.

  4. Alkalmazza a SecretProviderClass fürtöt a kubectl apply parancs használatával.

    kubectl apply -f secretproviderclass.yaml
    
  5. Hozzon létre egy podot a következő YAML használatával.

    # 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. Alkalmazza a podot a fürtre a kubectl apply parancs használatával.

    kubectl apply -f pod.yaml
    

Key Vault titkos kulcsok ellenőrzése

A pod elindítása után a csatlakoztatott tartalom az üzembe helyezési YAML-ben megadott kötetútvonalon érhető el. Az alábbi parancsokkal ellenőrizheti a titkos kulcsokat, és kinyomtathat egy teszttitkot.

  1. A titkos kulcstárban tárolt titkos kulcsok megjelenítése az alábbi paranccsal.

    kubectl exec busybox-secrets-store-inline-user-msi -- ls /mnt/secrets-store/
    
  2. Egy titkos kód megjelenítése az áruházban az alábbi paranccsal. Ez a példaparancs a teszttitkot ExampleSecretmutatja be.

    kubectl exec busybox-secrets-store-inline-user-msi -- cat /mnt/secrets-store/ExampleSecret
    

Tanúsítványok és kulcsok beszerzése

Az Azure Key Vault kialakítása éles különbségeket tesz a kulcsok, titkos kódok és tanúsítványok között. A Key Vault szolgáltatás tanúsítványfunkciói úgy vannak kialakítva, hogy kihasználják a kulcs- és titkos kulcsok képességeit. Kulcstartó-tanúsítvány létrehozásakor az azonos nevű címezhető kulcsot és titkos kulcsot hozza létre. Ez a kulcs lehetővé teszi a hitelesítési műveleteket, a titkos kód pedig lehetővé teszi a tanúsítvány értékének titkos kulcsként való lekérését.

A key vault-tanúsítvány nyilvános x509-tanúsítvány metaadatokat is tartalmaz. A kulcstartó titkosan tárolja a tanúsítvány nyilvános és privát összetevőit is. Az egyes összetevők beszerzéséhez adja meg a objectType következőt SecretProviderClass: Az alábbi táblázat azt mutatja be, hogy mely objektumok képeznek le a tanúsítványhoz társított különböző erőforrásokhoz:

Objektum Visszaadott érték Teljes tanúsítványláncot ad vissza
key A nyilvános kulcs adatvédelmi továbbfejlesztett levelek (PEM) formátumban. n/a
cert A tanúsítvány PEM formátumban. Nem
secret A titkos kulcs és a tanúsítvány PEM formátumban. Igen

Meglévő fürtök bővítményének letiltása

Feljegyzés

Mielőtt letiltja a bővítményt, győződjön meg arról, hogy nincs SecretProviderClass használatban. Ha letiltja a bővítményt, ha létezik, SecretProviderClass hiba jelenik meg.

  • Tiltsa le az Azure Key Vault-szolgáltató Titkos kulcstár CSI-illesztőprogram funkciójának letiltását egy meglévő fürtben a az aks disable-addons azure-keyvault-secrets-provider bővítményt tartalmazó paranccsal.

    az aks disable-addons --addons azure-keyvault-secrets-provider --resource-group myResourceGroup --name myAKSCluster
    

Feljegyzés

Ha letiltja a bővítményt, a meglévő számítási feladatoknak nem lehetnek problémáik, és nem láthatnak frissítéseket a csatlakoztatott titkos kódokban. Ha a pod újraindul, vagy egy új pod jön létre a vertikális felskálázási esemény részeként, a pod nem indul el, mert az illesztőprogram már nem fut.

Következő lépések

Ebben a cikkben megtanulta, hogyan hozhat létre és adhat meg identitást az Azure Key Vault eléréséhez. A Service Connector integrációja leegyszerűsíti az AKS-számítási feladatok és az Azure-háttérszolgáltatások kapcsolatkonfigurációját. Biztonságosan kezeli a hitelesítést és a hálózati konfigurációkat, és követi az Azure-szolgáltatásokhoz való csatlakozás ajánlott eljárásait. További információ : Az Azure Key Vault-szolgáltató használata a Secrets Store CSI-illesztőprogramhoz egy AKS-fürtben és a Service Connector bemutatása.

Ha további konfigurációs beállításokat szeretne konfigurálni, vagy hibaelhárítást szeretne végezni, tekintse meg az Azure Key Vault-szolgáltató konfigurációs beállításait és hibaelhárítási erőforrásait az AKS Titkos tár CSI-illesztőprogramjával.