Koneksi IdP Azure Anda ke Driver CSI Penyimpanan Rahasia Azure Key Vault di Azure Kubernetes Service (AKS)

Artikel
05/03/2024

Driver Secrets Store Container Storage Interface (CSI) di Azure Kubernetes Service (AKS) menyediakan berbagai metode akses berbasis identitas ke Azure Key Vault Anda. Artikel ini menguraikan metode dan praktik terbaik ini kapan harus menggunakan model keamanan kontrol akses berbasis Peran (RBAC) atau OpenID Koneksi (OIDC) untuk mengakses brankas kunci dan kluster AKS Anda.

Anda dapat menggunakan salah satu metode akses berikut:

ID Beban Kerja Microsoft Entra
Identitas terkelola yang ditetapkan pengguna

Prasyarat untuk Driver CSI

Sebelum memulai, pastikan Anda menyelesaikan langkah-langkah dalam Menggunakan penyedia Azure Key Vault untuk Driver Secrets Store CSI di kluster Azure Kubernetes Service (AKS) untuk mengaktifkan Driver CSI Penyimpanan Rahasia Azure Key Vault di kluster AKS Anda.

Akses dengan ID Beban Kerja Microsoft Entra

ID Beban Kerja Microsoft Entra adalah identitas yang digunakan aplikasi yang berjalan di pod untuk mengautentikasi dirinya terhadap layanan Azure lainnya, seperti beban kerja dalam perangkat lunak. Driver CSI Secret Store terintegrasi dengan kemampuan Kubernetes asli untuk bergabung dengan penyedia identitas eksternal.

Dalam model keamanan ini, kluster AKS bertindak sebagai penerbit token. Microsoft Entra ID kemudian menggunakan OIDC untuk menemukan kunci penandatanganan publik dan memverifikasi keaslian token akun layanan sebelum menukarnya dengan token Microsoft Entra. Agar beban kerja Anda menukar token akun layanan yang diproyeksikan ke volumenya untuk token Microsoft Entra, Anda memerlukan pustaka klien Azure Identity di Azure SDK atau Microsoft Authentication Library (MSAL)

Catatan

Metode autentikasi ini menggantikan identitas yang dikelola pod Microsoft Entra (pratinjau). Sumber terbuka identitas yang dikelola pod Microsoft Entra (pratinjau) di Azure Kubernetes Service telah tidak digunakan lagi pada 24/10/2022.
ID Beban Kerja Microsoft Entra mendukung kluster Windows dan Linux.

Mengonfigurasi identitas beban kerja

Atur az account set langganan Anda menggunakan perintah .

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

Buat identitas terkelola menggunakan az identity create perintah .

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)

Buat penetapan peran yang memberikan izin identitas beban kerja untuk mengakses rahasia brankas kunci, kunci akses, dan sertifikat menggunakan az role assignment create perintah .
Penting
- Jika brankas kunci Anda diatur dengan --enable-rbac-authorization dan Anda menggunakan key atau certificate mengetik, tetapkan Key Vault Certificate User peran untuk memberikan izin.
- Jika brankas kunci Anda diatur dengan --enable-rbac-authorization dan Anda menggunakan secret jenis, tetapkan Key Vault Secrets User peran .
- Jika brankas kunci Anda tidak diatur dengan --enable-rbac-authorization, Anda dapat menggunakan az keyvault set-policy perintah dengan --key-permissions getparameter , , --certificate-permissions getatau --secret-permissions get untuk membuat kebijakan brankas kunci untuk memberikan akses untuk kunci, sertifikat, atau rahasia. Contohnya:
```
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
```
Dapatkan URL Pengeluar Sertifikat OIDC kluster AKS menggunakan az aks show perintah .

Catatan

Langkah ini mengasumsikan Anda memiliki kluster AKS yang sudah ada dengan URL Penerbit OIDC diaktifkan. Jika Anda tidak mengaktifkannya, lihat Memperbarui kluster AKS dengan Pengeluar Sertifikat OIDC untuk mengaktifkannya.
```
export AKS_OIDC_ISSUER="$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query "oidcIssuerProfile.issuerUrl" -o tsv)"
echo $AKS_OIDC_ISSUER
```

Buat kredensial identitas gabungan antara aplikasi Microsoft Entra, penerbit akun layanan, dan subjek. Dapatkan ID objek aplikasi Microsoft Entra menggunakan perintah berikut. Pastikan untuk memperbarui nilai untuk serviceAccountName dan serviceAccountNamespace dengan nama akun layanan Kubernetes dan namespace layanannya.

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

Buat kredensial identitas gabungan antara identitas terkelola, penerbit akun layanan, dan subjek menggunakan az identity federated-credential create perintah .

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}

SecretProviderClass Sebarkan kubectl apply menggunakan perintah dan skrip YAML berikut.

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

Catatan

Jika Anda menggunakan objectAlias alih-alih objectName, perbarui skrip YAML untuk memperhitungkannya.

Catatan

Agar SecretProviderClass berfungsi dengan baik, pastikan untuk mengisi Azure Key Vault Anda dengan rahasia, kunci, atau sertifikat sebelum mereferensikannya di bagian .objects

Sebarkan pod sampel menggunakan kubectl apply perintah dan skrip YAML berikut.

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

Akses dengan identitas terkelola

ID Terkelola Microsoft Entra adalah identitas yang digunakan administrator untuk mengautentikasi diri mereka sendiri terhadap layanan Azure lainnya. Identitas terkelola menggunakan RBAC untuk bergabung dengan penyedia identitas eksternal.

Dalam model keamanan ini, Anda dapat memberikan akses ke sumber daya kluster Anda kepada anggota tim atau penyewa yang berbagi peran terkelola. Peran diperiksa cakupannya untuk mengakses keyvault dan kredensial lainnya. Saat Anda mengaktifkan penyedia Azure Key Vault untuk Secrets Store CSI Driver di Kluster AKS Anda, ia membuat identitas pengguna.

Mengonfigurasikan identitas terkelola

Akses brankas kunci Anda menggunakan az aks show perintah dan identitas terkelola yang ditetapkan pengguna yang dibuat oleh add-on. Anda juga harus mengambil identitas clientId, yang akan Anda gunakan di langkah-langkah selanjutnya saat membuat 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

Atau, Anda dapat membuat identitas terkelola baru dan menetapkannya ke set skala komputer virtual (VM) Anda atau ke setiap instans VM dalam set ketersediaan Anda menggunakan perintah berikut.

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

Buat penetapan peran yang memberikan izin identitas untuk mengakses rahasia brankas kunci, kunci akses, dan sertifikat menggunakan az role assignment create perintah .
Penting
- Jika brankas kunci Anda diatur dengan --enable-rbac-authorization dan Anda menggunakan key atau certificate mengetik, tetapkan peran.Key Vault Certificate User
- Jika brankas kunci Anda diatur dengan --enable-rbac-authorization dan Anda menggunakan secret jenis, tetapkan Key Vault Secrets User peran .
- Jika brankas kunci Anda tidak diatur dengan --enable-rbac-authorization, Anda dapat menggunakan az keyvault set-policy perintah dengan --key-permissions getparameter , , --certificate-permissions getatau --secret-permissions get untuk membuat kebijakan brankas kunci untuk memberikan akses untuk kunci, sertifikat, atau rahasia. Contohnya:
```
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
```

SecretProviderClass Buat menggunakan YAML berikut. Pastikan untuk menggunakan nilai Anda sendiri untuk userAssignedIdentityID, , keyvaultNametenantId, dan objek yang akan diambil dari brankas kunci Anda.

# 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

Catatan

Jika Anda menggunakan objectAlias alih-alih objectName, pastikan untuk memperbarui skrip YAML.

Catatan

Agar SecretProviderClass berfungsi dengan baik, pastikan untuk mengisi Azure Key Vault Anda dengan rahasia, kunci, atau sertifikat sebelum mereferensikannya di bagian .objects

Terapkan ke SecretProviderClass kluster Anda menggunakan kubectl apply perintah .
```
kubectl apply -f secretproviderclass.yaml
```

Buat pod menggunakan YAML berikut.

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

Terapkan pod ke kluster Anda menggunakan kubectl apply perintah .
```
kubectl apply -f pod.yaml
```

Memvalidasi rahasia Key Vault

Setelah pod dimulai, tersedia konten yang dipasang pada jalur volume yang ditentukan dalam penyebaran YAML Anda. Gunakan perintah berikut untuk memvalidasi rahasia Anda dan mencetak rahasia pengujian.

Tampilkan rahasia yang disimpan di penyimpanan rahasia menggunakan perintah berikut.
```
kubectl exec busybox-secrets-store-inline-user-msi -- ls /mnt/secrets-store/
```
Tampilkan rahasia di penyimpanan menggunakan perintah berikut. Contoh perintah ini menunjukkan rahasia ExampleSecretpengujian .
```
kubectl exec busybox-secrets-store-inline-user-msi -- cat /mnt/secrets-store/ExampleSecret
```

Mendapatkan sertifikat dan kunci

Desain Azure Key Vault membuat perbedaan tajam antara kunci, rahasia, dan sertifikat. Fitur sertifikat layanan Key Vault dirancang untuk memanfaatkan kemampuan kunci dan rahasia. Saat Anda membuat sertifikat brankas kunci, sertifikat tersebut membuat kunci dan rahasia yang dapat diatasi dengan nama yang sama. Kunci ini memungkinkan operasi autentikasi, dan rahasia memungkinkan pengambilan nilai sertifikat sebagai rahasia.

Sertifikat brankas kunci juga berisi metadata sertifikat x509 publik. Gudang kunci menyimpan komponen publik dan privat dari sertifikat Anda secara rahasia. Anda dapat memperoleh setiap komponen individu dengan menentukan objectType di SecretProviderClass. Tabel berikut menunjukkan objek mana yang dipetakan ke berbagai sumber daya yang terkait dengan sertifikat Anda:

Objek	Nilai hasil	Mengembalikan seluruh rantai sertifikat
`key`	Kunci publik, dalam format Email yang Ditingkatkan Privasi (PEM).	T/A
`cert`	Sertifikat, dalam format PEM.	No
`secret`	Kunci privat dan sertifikat, dalam format PEM.	Ya

Menonaktifkan addon pada kluster yang ada

Catatan

Sebelum Anda menonaktifkan add-on, pastikan tidak ada yang SecretProviderClass digunakan. Mencoba menonaktifkan add-on saat SecretProviderClass ada menghasilkan kesalahan.

Nonaktifkan penyedia Azure Key Vault untuk kemampuan Driver Secrets Store CSI di kluster yang ada menggunakan az aks disable-addons perintah dengan azure-keyvault-secrets-provider add-on.
```
az aks disable-addons --addons azure-keyvault-secrets-provider --resource-group myResourceGroup --name myAKSCluster
```

Catatan

Saat Anda menonaktifkan add-on, beban kerja yang ada seharusnya tidak memiliki masalah atau melihat pembaruan apa pun dalam rahasia yang dipasang. Jika pod dimulai ulang atau pod baru dibuat sebagai bagian dari peristiwa peningkatan skala, pod gagal dimulai karena driver tidak lagi berjalan.

Langkah berikutnya

Dalam artikel ini, Anda mempelajari cara membuat dan memberikan identitas untuk mengakses Azure Key Vault Anda. Jika Anda ingin mengonfigurasi opsi konfigurasi tambahan atau melakukan pemecahan masalah, lanjutkan ke artikel berikutnya.

Opsi konfigurasi dan sumber daya pemecahan masalah untuk penyedia Azure Key Vault dengan Secrets Store CSI Driver di AKS

Share via

Koneksi IdP Azure Anda ke Driver CSI Penyimpanan Rahasia Azure Key Vault di Azure Kubernetes Service (AKS)

Prasyarat untuk Driver CSI

Akses dengan ID Beban Kerja Microsoft Entra

Mengonfigurasi identitas beban kerja

Akses dengan identitas terkelola

Mengonfigurasikan identitas terkelola

Memvalidasi rahasia Key Vault

Mendapatkan sertifikat dan kunci

Menonaktifkan addon pada kluster yang ada

Langkah berikutnya

Sumber Daya Tambahan: