Azure kimlik sağlayıcınızı Azure Kubernetes Service'teki (AKS) Azure Key Vault Gizli Dizi deposu CSI Sürücüsüne Bağlan

Makale
05/03/2024

Azure Kubernetes Service (AKS) üzerindeki Gizli Dizi Deposu Kapsayıcı Depolama Arabirimi (CSI) Sürücüsü, Azure Key Vault'unuza kimlik tabanlı erişim için çeşitli yöntemler sağlar. Bu makalede, anahtar kasanıza ve AKS kümenize erişmek için Rol tabanlı erişim denetimi (RBAC) veya OpenID Bağlan (OIDC) güvenlik modellerinin ne zaman kullanılacağına yönelik bu yöntemler ve en iyi yöntemler özetlenmiştir.

Aşağıdaki erişim yöntemlerinden birini kullanabilirsiniz:

Microsoft Entra İş Yükü Kimliği
Kullanıcı tarafından atanan yönetilen kimlik

CSI Sürücüsü önkoşulları

Başlamadan önce, AKS kümenizde Azure Key Vault Gizli Dizi Deposu CSI Sürücüsünü etkinleştirmek üzere Azure Kubernetes Service (AKS) kümesinde Gizli Dizi Deposu CSI Sürücüsü için Azure Key Vault sağlayıcısını kullanma bölümünde yer alan adımları tamamladığınızdan emin olun.

Microsoft Entra İş Yükü Kimliği ile erişim

Microsoft Entra İş Yükü Kimliği, pod üzerinde çalışan bir uygulamanın yazılımdaki iş yükleri gibi diğer Azure hizmetlerinde kimlik doğrulaması yapmak için kullandığı bir kimliktir. Gizli Depolama CSI Sürücüsü, dış kimlik sağlayıcılarıyla federasyon sağlamak için yerel Kubernetes özellikleriyle tümleşir.

Bu güvenlik modelinde AKS kümesi belirteç veren işlevi görür. Microsoft Entra Id daha sonra genel imzalama anahtarlarını bulmak ve bir Microsoft Entra belirteci için takas etmeden önce hizmet hesabı belirtecinin orijinalliğini doğrulamak için OIDC kullanır. İş yükünüzün bir Microsoft Entra belirteci için birimine yansıtılan bir hizmet hesabı belirtecini değiştirmesi için, Azure SDK'daki Azure Identity istemci kitaplığına veya Microsoft Kimlik Doğrulama Kitaplığı'na (MSAL) ihtiyacınız vardır

Not

Bu kimlik doğrulama yöntemi, Microsoft Entra pod ile yönetilen kimliğin (önizleme) yerini alır. Azure Kubernetes Service'teki açık kaynak Microsoft Entra pod yönetilen kimliği (önizleme) 24.10.2022 itibarıyla kullanım dışı bırakılmıştır.
Microsoft Entra İş Yükü Kimliği hem Windows hem de Linux kümelerini destekler.

İş yükü kimliğini yapılandırma

komutunu kullanarak az account set aboneliğinizi ayarlayın.

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

komutunu kullanarak az identity create yönetilen kimlik oluşturun.

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)

komutunu kullanarak iş yükü kimliğine anahtar kasası gizli dizilerine, erişim anahtarlarına ve sertifikalara erişim izni veren bir rol ataması az role assignment create oluşturun.
Önemli
- Anahtar kasanız ile --enable-rbac-authorization ayarlandıysa ve kullanıyorsanız key veya certificate yazdıysanız, izinleri vermek için rolü atayın Key Vault Certificate User .
- Anahtar kasanız ile --enable-rbac-authorization ayarlandıysa ve tür kullanıyorsanız secret rolü atayın Key Vault Secrets User .
- Anahtar kasanız ile --enable-rbac-authorizationayarlı değilse komutunu , --certificate-permissions getveya parametresiyle --key-permissions getkullanarak az keyvault set-policy anahtarlar, sertifikalar veya --secret-permissions get gizli diziler için erişim vermek üzere bir anahtar kasası ilkesi oluşturabilirsiniz. Örneğin:
```
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
```
komutunu kullanarak AKS kümesi OIDC Veren URL'sini az aks show alın.

Not

Bu adımda, OIDC Veren URL'si etkinleştirilmiş bir AKS kümeniz olduğu varsayılır. Etkinleştirmediyseniz, etkinleştirmek için bkz . AKS kümesini OIDC Veren ile güncelleştirme.
```
export AKS_OIDC_ISSUER="$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query "oidcIssuerProfile.issuerUrl" -o tsv)"
echo $AKS_OIDC_ISSUER
```

Microsoft Entra uygulaması, hizmet hesabı veren ve konu arasında bir federasyon kimliği kimlik bilgisi oluşturun. Aşağıdaki komutları kullanarak Microsoft Entra uygulamasının nesne kimliğini alın. ve serviceAccountNamespace değerlerini serviceAccountName Kubernetes hizmet hesabı adı ve ad alanıyla güncelleştirdiğinden emin olun.

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

komutunu kullanarak az identity federated-credential create yönetilen kimlik, hizmet hesabı veren ve konu arasında federasyon kimliği kimlik bilgilerini oluşturun.

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}

komutunu ve aşağıdaki YAML betiğini kullanarak kubectl apply bir SecretProviderClass dağıtın.

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

Not

yerine objectNamekullanırsanız objectAlias YAML betiğini hesaba eklemek için güncelleştirin.

Not

öğesinin SecretProviderClass düzgün çalışması için Azure Key Vault'unuzu bölümde bunlara başvurmadan önce gizli diziler, anahtarlar veya sertifikalarla doldurmayı objects unutmayın.

komutunu ve aşağıdaki YAML betiğini kullanarak kubectl apply örnek bir pod dağıtın.

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

Yönetilen kimlikle erişim

Microsoft Entra Yönetilen Kimliği, bir yöneticinin diğer Azure hizmetlerinde kimlik doğrulaması yapmak için kullandığı bir kimliktir. Yönetilen kimlik, dış kimlik sağlayıcılarıyla federasyon yapmak için RBAC kullanır.

Bu güvenlik modelinde, yönetilen rolü paylaşan ekip üyelerine veya kiracılara kümenizin kaynaklarına erişim vekleyebilirsiniz. Rol, anahtar kasasına ve diğer kimlik bilgilerine erişmek için kapsam için denetlendi. AKS Kümenizde Gizli Dizi Deposu CSI Sürücüsü için Azure Key Vault sağlayıcısını etkinleştirdiğinizde bir kullanıcı kimliği oluşturmuştur.

Yönetilen kimliği yapılandırma

komutunu ve eklenti tarafından oluşturulan kullanıcı tarafından atanan yönetilen kimliği kullanarak az aks show anahtar kasanıza erişin. Ayrıca, bir oluştururken SecretProviderClasssonraki adımlarda kullanacağınız kimliğin clientIddeğerini de almanız gerekir.

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

Alternatif olarak, aşağıdaki komutları kullanarak yeni bir yönetilen kimlik oluşturabilir ve bunu sanal makine (VM) ölçek kümenize veya kullanılabilirlik kümenizdeki her vm örneğine atayabilirsiniz.

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

komutunu kullanarak anahtar kasası gizli dizilerine, erişim anahtarlarına ve sertifikalara erişim izni veren bir rol ataması az role assignment create oluşturun.
Önemli
- Anahtar kasanız ile --enable-rbac-authorization ayarlandıysa ve kullanıyorsanız key veya certificate yazdıysanız rolü atayın Key Vault Certificate User .
- Anahtar kasanız ile --enable-rbac-authorization ayarlandıysa ve tür kullanıyorsanız secret rolü atayın Key Vault Secrets User .
- Anahtar kasanız ile --enable-rbac-authorizationayarlı değilse komutunu , --certificate-permissions getveya parametresiyle --key-permissions getkullanarak az keyvault set-policy anahtarlar, sertifikalar veya --secret-permissions get gizli diziler için erişim vermek üzere bir anahtar kasası ilkesi oluşturabilirsiniz. Örneğin:
```
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
```

Aşağıdaki YAML'yi kullanarak bir SecretProviderClass oluşturun. Anahtar kasanızdan alınacak , keyvaultName, tenantIdve nesneleri için userAssignedIdentityIDkendi değerlerinizi kullandığınızdan emin olun.

# 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

Not

yerine objectNamekullanıyorsanız objectAlias YAML betiğini güncelleştirdiğinizden emin olun.

Not

SecretProviderClass komutunu kullanarak kubectl apply kümenize uygulayın.
```
kubectl apply -f secretproviderclass.yaml
```

Aşağıdaki YAML'yi kullanarak bir pod oluşturun.

# 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"

komutunu kullanarak podu kubectl apply kümenize uygulayın.
```
kubectl apply -f pod.yaml
```

Key Vault gizli dizilerini doğrulama

Pod başlatıldıktan sonra, dağıtım YAML'nizde belirtilen birim yolundaki bağlı içerik kullanılabilir. Gizli dizilerinizi doğrulamak ve bir test gizli dizisi yazdırmak için aşağıdaki komutları kullanın.

Aşağıdaki komutu kullanarak gizli dizi deposunda tutulan gizli dizileri gösterin.
```
kubectl exec busybox-secrets-store-inline-user-msi -- ls /mnt/secrets-store/
```
Aşağıdaki komutu kullanarak depoda bir gizli dizi görüntüleyin. Bu örnek komut, test gizli dizisini ExampleSecretgösterir.
```
kubectl exec busybox-secrets-store-inline-user-msi -- cat /mnt/secrets-store/ExampleSecret
```

Sertifikaları ve anahtarları alma

Azure Key Vault tasarımı anahtarlar, gizli diziler ve sertifikalar arasında keskin ayrımlar yapar. Key Vault hizmetinin sertifika özellikleri, anahtar ve gizli dizi özelliklerinden yararlanacak şekilde tasarlanmıştır. Anahtar kasası sertifikası oluşturduğunuzda, aynı ada sahip adreslenebilir bir anahtar ve gizli dizi oluşturur. Bu anahtar kimlik doğrulama işlemlerine izin verir ve gizli dizi, sertifika değerinin gizli dizi olarak alınmasına izin verir.

Anahtar kasası sertifikası genel x509 sertifika meta verilerini de içerir. Anahtar kasası, sertifikanızın hem genel hem de özel bileşenlerini bir gizli dizide depolar. içindeki öğesini belirterek objectTypeSecretProviderClassher bir bileşeni elde edebilirsiniz. Aşağıdaki tabloda hangi nesnelerin sertifikanızla ilişkili çeşitli kaynaklarla eşlendiği gösterilmektedir:

Object	Dönüş değeri	Sertifika zincirinin tamamını döndürür
`key`	Gizlilik Artırılmış Posta (PEM) biçimindeki ortak anahtar.	Yok
`cert`	PEM biçimindeki sertifika.	Hayır
`secret`	PEM biçimindeki özel anahtar ve sertifika.	Yes

Mevcut kümelerde eklentiyi devre dışı bırakma

Not

Eklentiyi devre dışı bırakmadan önce, kullanımda olmadığındanSecretProviderClass emin olun. Eklenti mevcutken SecretProviderClass devre dışı bırakılmaya çalışılıyorsa hata oluşur.

Eklenti ile komutunu kullanarak az aks disable-addons mevcut bir kümede Gizli Dizi Deposu CSI Sürücüsü için Azure Key Vault sağlayıcısını azure-keyvault-secrets-provider devre dışı bırakın.
```
az aks disable-addons --addons azure-keyvault-secrets-provider -g myResourceGroup -n myAKSCluster
```

Not

Eklentiyi devre dışı bırakdığınızda, mevcut iş yüklerinde herhangi bir sorun olmamalıdır veya bağlı gizli dizilerde güncelleştirmeler görünmelidir. Pod yeniden başlatılırsa veya ölçeği artırma olayının bir parçası olarak yeni bir pod oluşturulursa, sürücü artık çalışmadığından pod başlatılamaz.

Sonraki adımlar

Bu makalede, Azure Key Vault'unuza erişmek için bir kimlik oluşturmayı ve sağlamayı öğrendiniz. Ek yapılandırma seçenekleri yapılandırmak veya sorun giderme gerçekleştirmek istiyorsanız, sonraki makaleye geçin.

AKS'de Gizli Dizi Deposu CSI Sürücüsü ile Azure Key Vault sağlayıcısı için yapılandırma seçenekleri ve sorun giderme kaynakları