Azure Kubernetes Service (AKS) の Azure Key Vault Secrets Store CSI Driver に Azure ID プロバイダーを接続する

[アーティクル]
10/15/2024

Azure Kubernetes Service (AKS) 上の Secrets Store Container Storage Interface (CSI) Driver には、Azure Key Vault に ID ベースでアクセスするためのさまざまな方法が用意されています。この記事では、ロールベースのアクセス制御 (RBAC) または OpenID Connect (OIDC) セキュリティモデルを使用してキーコンテナーと AKS クラスターにアクセスする場合のこれらの方法とベストプラクティスについて説明します。

次のいずれかのアクセス方法を使用できます。

マネージド ID を持つサービスコネクタ
ワークロード ID
ユーザー割り当てマネージド ID

サービスコネクタを使用して、Azure Kubernetes Service (AKS) クラスター内のシークレットストア CSI ドライバーを使用して Azure Key Vault に接続する方法を学習します。この記事では、次のタスクを完了します。

AKS クラスターと Azure Key Vault を作成します。
Service Connector を使用した AKS クラスターと Azure Key Vault の間の接続を作成します。
SecretProviderClass CRD と、CSI プロバイダーを使用する Pod を作成して接続をテストする。
リソースをクリーンアップする。

重要

AKS のプレビュー機能は、セルフサービスのオプトイン単位で利用できます。プレビューは、"現状有姿" および "利用可能な限度" で提供され、サービスレベルアグリーメントおよび限定保証から除外されるものとします。 AKS プレビューは、ベストエフォートベースでカスタマーサポートによって部分的にカバーされます。そのため、これらの機能は、運用環境での使用を意図していません。詳細については、次のサポート記事を参照してください。

前提条件

アクティブなサブスクリプションが含まれる Azure アカウント。無料でアカウントを作成できます。
Azure CLI。 az login コマンドを使用してサインインします。
Docker と kubectl。 kubectl をローカルにインストールするには、az aks install-cli コマンドを使用します。
コンテナーと AKS の基本的な理解。 AKS 用のアプリケーションの準備で概要を確認してください。
開始する前に、必ず「Azure Kubernetes Service (AKS) クラスターで Secrets Store CSI Driver 用 Azure Key Vault プロバイダーを使う」の手順を完了して、AKS クラスターで Azure Key Vault Secrets Store CSI Driver を有効にしてください。

初期セットアップ

サービスコネクタを初めて使用する場合は、まず、コマンド az provider register を実行して、サービスコネクタおよび Kubernetes Configuration リソースプロバイダーを登録します。
```
az provider register -n Microsoft.ServiceLinker
```
```
az provider register -n Microsoft.KubernetesConfiguration
```
ヒント

コマンド az provider show -n "Microsoft.ServiceLinker" --query registrationState と az provider show -n "Microsoft.KubernetesConfiguration" --query registrationState を実行することで、これらのリソースプロバイダーが既に登録されているかどうかを確認できます。
必要に応じて、Azure CLI コマンドを使用して、AKS クラスターでサポートされているターゲットサービスの一覧を取得します。
```
az aks connection list-support-types --output table
```

Azure リソースを作成する

az group create コマンドを使用して、リソースグループを作成します。
```
az group create \
    --name <resource-group-name> \
    --location <location>
```
az aks create コマンドを使用して、AKS クラスターを作成します。次の例では、マネージド ID が有効になっている単一ノードの AKS クラスターを作成します。
```
az aks create \
    --resource-group <resource-group-name> \
    --name <cluster-name> \
    --enable-managed-identity \
    --node-count 1
```

az aks get-credentials コマンドを使用してクラスターに接続します。

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

az keyvault create コマンドを使って、Azure キーコンテナーを作成します。

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

az keyvault secret set コマンドを使用して、キーコンテナー内にシークレットを作成します。
```
az keyvault secret set \
    --vault-name <key-vault-name> \
    --name <secret-name> \
    --value <secret-value>
```

Service Connector を使用して AKS でサービス接続を作成する (プレビュー)

Azure portal または Azure CLI を使用して、Azure Key Vault へのサービス接続を作成できます。

Azure Portal
Azure CLI

Azure portal で、ご使用の AKS クラスターリソースに移動します。
サービスメニューの [設定] で、[サービスコネクタ (プレビュー)]>[作成] を選択します。
[接続の作成] ページで、[基本] タブ内の以下の設定を構成します。
- [Kubernetes 名前空間]: [既定] を選択します。
- サービスの種類: [Key Vault] を選択してチェックボックスを選択して Azure Key Vault CSI プロバイダーを有効にします。
- 接続名: 接続の名前を入力します。
- サブスクリプション: キーコンテナーを含むサブスクリプションを選択します。
- キーコンテナー: 作成したキーコンテナーを選択します。
- クライアントの種類: [None] を選択します。
[確認と作成] を選択した後、[作成] を選択して接続を作成します。

az aks connection create keyvault コマンドを使用してキーコンテナーへの接続を作成します。

az aks connection create keyvault \
    --connection <connection-name> \
    --resource-group <resource-group-of-cluster> \
    --name <cluster-name> \
    --target-resource-group <resource-group-of-key-vault> \
    --vault <key-vault-name> \
    --enable-csi \
    --client-type none

接続をテストする

サンプルリポジトリをクローンし、マニフェストファイルをデプロイする

git clone コマンドを使用してサンプルリポジトリをクローンします。
```
git clone https://github.com/Azure-Samples/serviceconnector-aks-samples.git
```
ディレクトリを Azure Key Vault CSI プロバイダーサンプルに変更します。
```
cd serviceconnector-aks-samples/azure-keyvault-csi-provider
```
secret_provider_class.yaml ファイルで、以下のプレースホルダーを Azure Key Vault の情報に置き換えます。
- <AZURE_KEYVAULT_NAME> を作成して接続したキーコンテナーの名前に置き換えます。
- <AZURE_KEYVAULT_TENANTID> をキーコンテナーのテナント ID に置き換えます。
- <AZURE_KEYVAULT_CLIENTID> を使用する azureKeyvaultSecretsProvider アドオンの ID クライアント ID に置き換えます。
- <KEYVAULT_SECRET_NAME> を作成したキーコンテナーシークレットに置き換えます。たとえば、ExampleSecret のようにします。
kubectl apply コマンドを使用して、SecretProviderClass CRD をデプロイします。
```
kubectl apply -f secret_provider_class.yaml
```
kubectl apply コマンドを使用して、Pod マニフェストファイルをデプロイします。

コマンドでは、AKS クラスターの既定の名前空間に sc-demo-keyvault-csi という名前のポッドが作成されます。
```
kubectl apply -f pod.yaml
```

接続を確認する

kubectl get コマンドを使用して、ポッドが正常に作成されたことを確認します。
```
kubectl get pod/sc-demo-keyvault-csi
```
ポッドが起動すると、デプロイ YAML で指定されたボリュームパスにマウントされたコンテンツが使用できるようになります。
kubectl exec コマンドを使用して、シークレットストア内に保持されているシークレットを表示します。
```
kubectl exec sc-demo-keyvault-csi -- ls /mnt/secrets-store/
```
kubectl exec コマンドを使用してシークレットを表示します。

このコマンド例は ExampleSecret という名前のテストシークレットを表示します。
```
kubectl exec sc-demo-keyvault-csi -- cat /mnt/secrets-store/ExampleSecret
```

CSI ドライバーの前提条件

開始する前に、必ず「Azure Kubernetes Service (AKS) クラスターで Secrets Store CSI Driver 用 Azure Key Vault プロバイダーを使う」の手順を完了して、AKS クラスターで Azure Key Vault Secrets Store CSI Driver を有効にしてください。
Microsoft Entra ワークロード ID は、Windows と Linux クラスターの両方をサポートします。

Microsoft Entra ワークロード ID を使用してアクセスする

Microsoft Entra ワークロード ID は、ポッドで実行されているアプリケーションが、ソフトウェアのワークロードなどの他の Azure サービスに対してそれ自体を認証するために使用する ID です。 Secret Store CSI Driver は、外部 ID プロバイダーとのフェデレーションのために、ネイティブの Kubernetes 機能と統合されます。

このセキュリティモデルでは、AKS クラスターはトークン発行者として機能します。その後、Microsoft Entra ID で OIDC を使って公開署名キーが検出され、サービスアカウントトークンの信頼性が検証されてから、それと Microsoft Entra トークンが交換されます。ワークロードがボリュームに投影されたサービスアカウントトークンを Microsoft Entra トークンと交換するには、Azure SDK または Microsoft Authentication Library (MSAL) の Azure ID クライアントライブラリが必要です

Note

この認証方法は、Microsoft Entra のポッドマネージド ID (プレビュー) に代わるものです。 Azure Kubernetes Service のオープンソースの Microsoft Entra ポッドマネージド ID (プレビュー) は、2022 年 10 月 24 日の時点で非推奨となりました。
Microsoft Entra ワークロード ID は、Windows と Linux クラスターの両方をサポートします。

ワークロード ID を構成する

az account set コマンドを使用してサブスクリプションを設定します。

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

az identity create コマンドを使用して、マネージド ID を作成します。

Note

この手順では、ワークロード ID が有効になっている既存の AKS クラスターがあることを前提としています。まだ有効になっていない場合は、既存の AKS クラスターでワークロード ID を有効にする方法に従って有効にしてください。
```
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)
```
az role assignment createコマンドを使用して、キーコンテナーのシークレット、アクセスキー、証明書にアクセスするための権限をワークロード ID に付与するロールの割り当てを作成します。
重要
- キーコンテナーが --enable-rbac-authorization で設定されていて、key または certificate の種類を使用している場合は、Key Vault Certificate User ロールを割り当ててアクセス許可を付与します。
- キーコンテナーが --enable-rbac-authorization で設定されていて、secret の種類を使用している場合は、Key Vault Secrets User ロールを割り当てます。
- キーコンテナーが --enable-rbac-authorization で設定されていない場合は、az keyvault set-policy コマンドを --key-permissions get、--certificate-permissions get、または --secret-permissions get パラメーターと共に使用して、キー、証明書、またはシークレットへのアクセスを許可するキーコンテナーポリシーを作成できます。次に例を示します。
```
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
```
az aks show コマンドを使用して、AKS クラスターの OIDC 発行者 URL を取得します。

Note

この手順では、OIDC 発行者 URL が有効な既存の AKS クラスターがあることを前提としています。有効にしていない場合は、「OIDC Issuer を備えた AKS クラスターを更新する」を参照して有効にしてください。
```
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 アプリケーション、サービスアカウントの発行者、およびサブジェクトの間に、フェデレーション ID 資格情報を確立してください。次のコマンドを使って、Microsoft Entra アプリケーションのオブジェクト ID を取得します。必ず、serviceAccountName と serviceAccountNamespace の値を Kubernetes のサービスアカウント名とその名前空間で更新してください。
```
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
```

az identity federated-credential create コマンドを使用して、マネージド ID、サービスアカウント発行者、およびサブジェクト間のフェデレーション ID 資格情報を作成します。

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}

kubectl apply コマンドと次の YAML スクリプトを使用して SecretProviderClass をデプロイします。

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

Note

objectAlias の代わりに objectName を使用する場合は、それを考慮するように YAML スクリプトを更新してください。

Note

SecretProviderClass が正しく機能するには、objects セクションで参照する前に、必ず Azure Key Vault にシークレット、キー、または証明書を設定します。

kubectl apply コマンドと次の YAML スクリプトを使用してサンプルポッドをデプロイします。

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

CSI ドライバーの前提条件

開始する前に、必ず「Azure Kubernetes Service (AKS) クラスターで Secrets Store CSI Driver 用 Azure Key Vault プロバイダーを使う」の手順を完了して、AKS クラスターで Azure Key Vault Secrets Store CSI Driver を有効にしてください。

マネージド ID を使用したデプロイ

Microsoft Entra マネージド ID は、管理者が他の Azure サービスに対して自身を認証するために使用する ID です。マネージド ID は、RBAC を使用して外部 ID プロバイダーとフェデレーションします。

このセキュリティモデルでは、マネージドロールを共有するチームメンバーまたはテナントに、クラスターのリソースへのアクセス権を与えることができます。ロールは、キーコンテナーやその他の資格情報にアクセスするためのスコープが確認されます。 AKS クラスターで Secrets Store CSI Driver に対して Azure Key Vault プロバイダーを有効にすると、ユーザー ID が作成されます。

マネージド ID を構成する

az aks show コマンドと、アドオンによって作成されたユーザー割り当てマネージド ID を使用して、キーコンテナーにアクセスしてください。 ID の clientId も取得する必要があります。これは、後の手順で 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

または、次のコマンドを使用して、新しいマネージド ID を作成し、仮想マシン (VM) スケールセットまたは可用性セット内の各 VM インスタンスに割り当てることができます。

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

az role assignment create コマンドを使用して、キーコンテナーのシークレット、アクセスキー、証明書にアクセスするための権限をワークロード ID に付与するロールの割り当てを作成します。
重要
- キーコンテナーが --enable-rbac-authorization で設定されていて、key または certificate の種類を使用している場合は、Key Vault Certificate User ロールを割り当てます。
- キーコンテナーが --enable-rbac-authorization で設定されていて、secret の種類を使用している場合は、Key Vault Secrets User ロールを割り当てます。
- キーコンテナーが --enable-rbac-authorization で設定されていない場合は、az keyvault set-policy コマンドを --key-permissions get、--certificate-permissions get、または --secret-permissions get パラメーターと共に使用して、キー、証明書、またはシークレットへのアクセスを許可するキーコンテナーポリシーを作成できます。次に例を示します。
```
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
```

次の YAML を使用して SecretProviderClass を作成します。 userAssignedIdentityID、keyvaultName、tenantId、およびキーコンテナーから取得するオブジェクトには、独自の値を使用するようにしてください。

# 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

注意

objectName の代わりに objectAlias を使う場合は、必ず YAML スクリプトを更新してください。

Note

SecretProviderClass が正しく機能するには、objects セクションで参照する前に、必ず Azure Key Vault にシークレット、キー、または証明書を設定します。

kubectl apply コマンドを使用して SecretProviderClass をクラスターに適用します。
```
kubectl apply -f secretproviderclass.yaml
```

次の 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"

kubectl apply コマンドを使用してポッドをクラスターに適用します。
```
kubectl apply -f pod.yaml
```

Key Vault シークレットを検証する

ポッドが起動すると、デプロイ YAML で指定されたボリュームパスにマウントされたコンテンツが使用できるようになります。次のコマンドを使って、シークレットを検証し、テストシークレットを表示します。

次のコマンドを使用して、シークレットストアに保持されているシークレットを表示します。
```
kubectl exec busybox-secrets-store-inline-user-msi -- ls /mnt/secrets-store/
```
次のコマンドを使用して、ストアにシークレットを表示します。このコマンド例は、テストシークレット ExampleSecret を示しています。
```
kubectl exec busybox-secrets-store-inline-user-msi -- cat /mnt/secrets-store/ExampleSecret
```

証明書とキーの取得

Azure Key Vault の設計では、キー、シークレット、証明書が明確に区別されます。 Key Vault サービスの証明書機能は、キーとシークレットの機能を利用して設計されます。 Key Vault 証明書が作成されると、アドレス指定可能なキーとシークレットが同じ名前で作成されます。このキーを使用すると認証操作が可能になり、シークレットでは証明書の値をシークレットとして取得できます。

Key Vault 証明書には、公開 x509 証明書メタデータも含まれます。 Azure Key Vault によって証明書の公開と非公開の両方の部分がシークレットに格納されます。 SecretProviderClass で objectType を指定することで、個々のコンポーネントを取得できます。次の表は、証明書に関連付けられているさまざまなリソースにマップされるオブジェクトを示しています。

Object	戻り値	証明書チェーン全体を返します
`key`	Privacy Enhanced Mail (PEM) 形式の公開キー。	該当なし
`cert`	PEM 形式の証明書。	いいえ
`secret`	PEM 形式の秘密キーと証明書。	はい

既存のクラスターでアドオンを無効にする

Note

アドオンを無効にする前に、使用中の SecretProviderClass が "ない" ことを確認してください。 SecretProviderClass が存在している間にアドオンを無効にしようとすると、エラーが発生します。

azure-keyvault-secrets-provider アドオンを指定して az aks disable-addons コマンドを使い、既存のクラスターで Secrets Store CSI Driver 用 Azure Key Vault プロバイダー機能を無効にします。
```
az aks disable-addons --addons azure-keyvault-secrets-provider --resource-group myResourceGroup --name myAKSCluster
```

Note

アドオンを無効にする場合、既存のワークロードに問題がないこと、またはマウントされたシークレットに更新プログラムが表示されることが必要です。ポッドが再起動するか、スケールアップイベントの一部として新しいポッドが作成された場合、ドライバーが実行されなくなるため、ポッドの起動に失敗します。

次のステップ

この記事では、Azure キーコンテナーにアクセスするための ID を作成して提供する方法について説明しました。サービスコネクタ統合は、AKS ワークロードと Azure バッキングサービスの接続構成を簡素化するのに役立ちます。認証とネットワーク構成を安全に処理し、ベストプラクティスに従って Azure サービスに接続することができます。詳しくは、「AKS クラスターでシークレットストア CSI ドライバーのために Azure Key Vault プロバイダーを使用する」と「サービスコネクタの概要」を参照してください。

追加の構成オプションを構成する場合や、トラブルシューティングを実行する場合については、AKS のシークレットストア CSI ドライバー用の Azure Key Vault プロバイダーの構成オプションとトラブルシューティングリソースに関する記事を参照してください。

次の方法で共有

Azure Kubernetes Service (AKS) の Azure Key Vault Secrets Store CSI Driver に Azure ID プロバイダーを接続する

前提条件

初期セットアップ

Azure リソースを作成する

Service Connector を使用して AKS でサービス接続を作成する (プレビュー)

接続をテストする

サンプルリポジトリをクローンし、マニフェストファイルをデプロイする

接続を確認する

CSI ドライバーの前提条件

Microsoft Entra ワークロード ID を使用してアクセスする

ワークロード ID を構成する

CSI ドライバーの前提条件

マネージド ID を使用したデプロイ

マネージド ID を構成する

Key Vault シークレットを検証する

証明書とキーの取得

既存のクラスターでアドオンを無効にする

次のステップ

その他のリソース

次の方法で共有

Azure Kubernetes Service (AKS) の Azure Key Vault Secrets Store CSI Driver に Azure ID プロバイダーを接続する

前提条件

初期セットアップ

Azure リソースを作成する

Service Connector を使用して AKS でサービス接続を作成する (プレビュー)

接続をテストする

サンプル リポジトリをクローンし、マニフェスト ファイルをデプロイする

接続を確認する

CSI ドライバーの前提条件

Microsoft Entra ワークロード ID を使用してアクセスする

ワークロード ID を構成する

CSI ドライバーの前提条件

マネージド ID を使用したデプロイ

マネージド ID を構成する

Key Vault シークレットを検証する

証明書とキーの取得

既存のクラスターでアドオンを無効にする

次のステップ

その他のリソース

サンプルリポジトリをクローンし、マニフェストファイルをデプロイする