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 olyantPod
, 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
- Egy Azure-fiók, aktív előfizetéssel. Fiók ingyenes létrehozása.
- Az Azure CLI. Jelentkezzen be a
az login
paranccsal. - Docker és kubectl. A kubectl helyi telepítéséhez használja a
az aks install-cli
parancsot. - A tárolók és az AKS alapszintű ismerete. Első lépésként készítse elő az alkalmazást az AKS-hez.
- Mielőtt hozzákezdene, győződjön meg arról, hogy befejezi az Azure Key Vault-szolgáltató a Titkos kulcstár CSI-illesztőprogramjának Azure Kubernetes Service-fürtön (AKS) való használatát az Azure Key Vault Titkos kulcstár CSI-illesztőprogramjának engedélyezéséhez az AKS-fürtben.
Kezdeti beállítás
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 registrationState
futtatásával ellenőrizheti, hogy ezek az erőforrás-szolgáltatók már regisztrálva lettek-e.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
Hozzon létre egy erőforráscsoportot a
az group create
paranccsal.az group create \ --name <resource-group-name> \ --location <location>
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
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>
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>
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.
Az Azure Portalon keresse meg az AKS-fürterőforrást.
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.
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.
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
Klónozza a mintaadattárat a
git clone
paranccsal.git clone https://github.com/Azure-Samples/serviceconnector-aks-samples.git
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
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>
aazureKeyvaultSecretsProvider
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
.
- Cserélje le
Telepítse a
SecretProviderClass
CRD-t akubectl apply
paranccsal.kubectl apply -f secret_provider_class.yaml
Helyezze üzembe a
Pod
jegyzékfájlt akubectl 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
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.
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/
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
- Mielőtt hozzákezdene, győződjön meg arról, hogy befejezi az Azure Key Vault-szolgáltató a Titkos kulcstár CSI-illesztőprogramjának Azure Kubernetes Service-fürtön (AKS) való használatát az Azure Key Vault Titkos kulcstár CSI-illesztőprogramjának engedélyezéséhez az AKS-fürtben.
- Microsoft Entra Számítási feladat ID windowsos és linuxos fürtöket is támogat.
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
Á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
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)
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áljakey
vagycertificate
írja be, rendelje hozzá a szerepkört azKey Vault Certificate User
engedélyek megadása érdekében. - Ha a kulcstartó be van állítva
--enable-rbac-authorization
, és ön típust használsecret
, rendelje hozzá a szerepkörtKey Vault Secrets User
. - Ha a kulcstartó nincs beállítva
--enable-rbac-authorization
, aaz keyvault set-policy
paranccsal a ,--certificate-permissions get
vagy--secret-permissions get
paraméterrel--key-permissions get
lé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
- Ha a kulcstartó be van állítva
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
Ö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 ésserviceAccountNamespace
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
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}
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
objectName
haszná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ásobjects
előtt mindenképpen töltse fel az Azure Key Vaultot titkos kulcsokkal, kulcsokkal vagy tanúsítványokkal.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
- Mielőtt hozzákezdene, győződjön meg arról, hogy befejezi az Azure Key Vault-szolgáltató a Titkos kulcstár CSI-illesztőprogramjának Azure Kubernetes Service-fürtön (AKS) való használatát az Azure Key Vault Titkos kulcstár CSI-illesztőprogramjának engedélyezéséhez az AKS-fürtben.
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
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ásokatclientId
is, amelyeket a későbbi lépésekben fog használni egySecretProviderClass
.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
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áljakey
vagycertificate
írja be, rendelje hozzá a szerepkörtKey Vault Certificate User
. - Ha a kulcstartó be van állítva
--enable-rbac-authorization
, és ön típust használsecret
, rendelje hozzá a szerepkörtKey Vault Secrets User
. - Ha a kulcstartó nincs beállítva
--enable-rbac-authorization
, aaz keyvault set-policy
paranccsal a ,--certificate-permissions get
vagy--secret-permissions get
paraméterrel--key-permissions get
lé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
- Ha a kulcstartó be van állítva
Hozzon létre egy
SecretProviderClass
elemet a következő YAML használatával. Ügyeljen arra, hogy a kulcstartóból lekérendő objektumokhozuserAssignedIdentityID
keyvaultName
tenantId
sajá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
objectName
használjaobjectAlias
, frissítse a YAML-szkriptet.Feljegyzés
A megfelelő működés érdekében
SecretProviderClass
a szakaszban való hivatkozásobjects
előtt mindenképpen töltse fel az Azure Key Vaultot titkos kulcsokkal, kulcsokkal vagy tanúsítványokkal.Alkalmazza a
SecretProviderClass
fürtöt akubectl apply
parancs használatával.kubectl apply -f secretproviderclass.yaml
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"
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.
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/
Egy titkos kód megjelenítése az áruházban az alábbi paranccsal. Ez a példaparancs a teszttitkot
ExampleSecret
mutatja 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.
Azure Kubernetes Service