Azure Kubernetes Service (AKS) で ID バインディングを設定する (プレビュー)

1 つのフェデレーション ID 資格情報 (FIC) を使用しながら、複数のクラスター間でユーザー割り当てマネージド ID (UAMI) をマップするように、Azure Kubernetes Service (AKS) クラスターに ID バインディングを設定します。このセットアップは、FIC の制限に達することなく、ワークロードに対して Microsoft Entra 認証をスケーリングするのに役立ちます。

[前提条件]

ID バインディングの概念を確認して、ID バインディングのしくみを理解します。
Azure CLI バージョン 2.73.0 以降。バージョンを確認するには、 az version コマンドを使用します。 Azure CLI をインストールまたは更新するには、「 Azure CLI のインストール」を参照してください。
Azure CLI aks-preview拡張機能バージョン18.0.0b26以降がインストールされています。
サブスクリプションに対して有効になっているIdentityBindingPreview機能フラグ。
ID とクラスタースコープに対する Azure アクセス許可が必要です。 Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials/write と Microsoft.ContainerService/managedClusters/write。
ClusterRoleとClusterRoleBindingリソースを作成するには、Kubernetes クラスター管理者 (またはそれと同等の) アクセス許可が必要です。

`aks-preview`拡張機能をインストールまたは更新する

aks-previewまたは az extension add コマンドを使用して、Azure CLI az extension update 拡張機能を最新バージョンにインストールまたは更新します。
```
# Install the aks-preview extension
az extension add --name aks-preview

# Update to the latest version if already installed
az extension update --name aks-preview
```

`IdentityBindingPreview`機能フラグを有効にする

IdentityBindingPreview コマンドを使用して、Azure サブスクリプションにaz feature register機能フラグを登録します。
```
az feature register --namespace Microsoft.ContainerService --name IdentityBindingPreview
```
機能の登録が完了するまでに最大 15 分かかる場合があります。
az feature show コマンドを使用して、機能の登録が完了するまで待ちます。
```
az feature show --namespace Microsoft.ContainerService --name IdentityBindingPreview
```
機能が Registeredとして表示されたら、 az provider register コマンドを使用してプロバイダーの登録を更新します。
```
az provider register --namespace Microsoft.ContainerService
```

制限事項

ID バインディングは、 API サーバー VNet 統合を使用して構成されたクラスターではまだサポートされていません。

テストリソースを作成する

az group create コマンドを使用して、Azure リソースグループを作成します。

export RESOURCE_GROUP="ib-test"
export LOCATION="westus2"

az group create --name $RESOURCE_GROUP --location $LOCATION

az aks createフラグと--enable-workload-identity フラグを使用して、--enable-oidc-issuer コマンドを使用して、ワークロード ID と OIDC 発行者を有効にした AKS クラスターを作成します。
```
export CLUSTER_NAME="ib-test-cluster"

az aks create --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --location $LOCATION --no-ssh-key --enable-workload-identity --enable-oidc-issuer
```
az identity create コマンドを使用して、ユーザー割り当てマネージド ID (UAMI) を作成します。
```
export MI_NAME="ib-test-mi"
az identity create --resource-group $RESOURCE_GROUP --name $MI_NAME
```

ワークロード ID Webhook のバージョンを確認する

ID バインディングには、ワークロード ID Webhook のプレビューバージョンが必要です。次の kubectl get pods コマンドを使用して、インストールされている webhook のバージョンを確認します。
```
kubectl -n kube-system get pods -l azure-workload-identity.io/system=true -o yaml | grep v1.6.0
```
出力には、正しいバージョンがインストールされていることを確認するイメージタグに v1.6.0-alpha.1 が表示されます。

UAMI ID を取得する

UAMI のリソース ID、プリンシパル ID、クライアント ID、テナント ID を取得し、次の az identity show コマンドを使用して環境変数として設定します。

export MI_RESOURCE_ID=$(az identity show --resource-group $RESOURCE_GROUP --name $MI_NAME --query id --output tsv)
export MI_PRINCIPAL_ID=$(az identity show --resource-group $RESOURCE_GROUP --name $MI_NAME --query principalId --output tsv)
export MI_CLIENT_ID=$(az identity show --resource-group $RESOURCE_GROUP --name $MI_NAME --query clientId --output tsv)
export MI_TENANT_ID=$(az identity show --resource-group $RESOURCE_GROUP --name $MI_NAME --query tenantId --output tsv)

ID バインディングを作成する

az aks identity-binding create コマンドを使用して、ID バインディングを使用して UAMI を AKS クラスターにマップします。
```
az aks identity-binding create --resource-group $RESOURCE_GROUP --cluster-name $CLUSTER_NAME --name "${MI_NAME}-ib" --managed-identity-resource-id $MI_RESOURCE_ID
```
注

ID バインディングを作成すると、AKS は UAMI の下に aks-identity-binding という名前のフェデレーション ID 資格情報 (FIC) を自動的に作成します。この資格情報は AKS によって管理されます。 ID バインディングが使用されている間は、変更または削除しないでください。 ID バインディング用に作成された FIC は、同じ UAMI を参照するすべての ID バインディング間で共有されます。

UAMI の OIDC 発行者 URL を取得する

az aks identity-binding show コマンドを使用して ID バインディングを調べることで、UAMI に関連付けられている OIDC 発行者 URL を取得します。

az aks identity-binding show --resource-group $RESOURCE_GROUP --cluster-name $CLUSTER_NAME --name "${MI_NAME}-ib"

要約された出力例:

{
  "oidcIssuer": {
    "oidcIssuerUrl": "https://ib.oic.prod-aks.azure.com/<MI-tenant-id>/<MI-client-id>"
  }
}

AKS クラスターに接続する

az aks get-credentials コマンドを使用して AKS クラスターの資格情報を取得し、別の kubeconfig ファイルに保存します。
```
az aks get-credentials --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME -a -f "${CLUSTER_NAME}.kubeconfig"
```
新しい kubeconfig ファイルを指す KUBECONFIG 環境変数を設定します。
```
export KUBECONFIG="$(pwd)/${CLUSTER_NAME}.kubeconfig"
```

名前空間とサービスアカウントを承認する

次の kubectl apply コマンドを使用して、次のマニフェストを適用して、ID バインディングを使用してマネージド ID を使用するアクセス許可を特定のサブジェクトに付与するようにロールベースのアクセス制御 (RBAC) を構成します。

注

次の例では、demo名前空間のdemo サービスアカウントを明示的に参照しています。特定のサービスアカウントを明示的に参照することは 1 つのオプションですが、 subjectsでサービスアカウントのコレクションを参照することもできます。詳細については、Kubernetes ドキュメントのサブジェクトの参照を参照してください。
```
kubectl apply -f - <<EOF
apiVersion: v1
kind: Namespace
metadata:
  name: demo
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: demo
  namespace: demo
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: use-mi-${MI_CLIENT_ID}
rules:
  - verbs: ["use-managed-identity"]
    apiGroups: ["cid.wi.aks.azure.com"]
    resources: ["${MI_CLIENT_ID}"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: use-mi-${MI_CLIENT_ID}
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: use-mi-${MI_CLIENT_ID}
subjects:
  - kind: ServiceAccount
    name: demo
    namespace: demo
EOF
```

Azure RBAC 承認と消去保護を使用してキーボールトを作成する

az keyvault create コマンドと --enable-purge-protection フラグ、--enable-rbac-authorization フラグを使用して、消去保護と Azure RBAC 認可を有効にした Key Vault を作成します。消去保護と Azure RBAC 承認の両方で構成されている場合は、既存のキーコンテナーを使用することもできます。
```
export KEY_VAULT_NAME="ib-test"

az keyvault create \
    --name $KEY_VAULT_NAME \
    --resource-group $RESOURCE_GROUP \
    --location $LOCATION \
    --enable-purge-protection \
    --enable-rbac-authorization
```

キーボールトのリソース ID と URL を取得する

az keyvault show コマンドを使用してキーコンテナーのリソース ID を取得し、環境変数として設定します。

export KEY_VAULT_RESOURCE_ID=$(az keyvault show --resource-group $RESOURCE_GROUP \
    --name $KEY_VAULT_NAME \
    --query id \
    --output tsv)

az keyvault show コマンドを使用してキーコンテナーの URL を取得し、環境変数として設定します。

export KEYVAULT_URL="$(az keyvault show \
    --resource-group $RESOURCE_GROUP \
    --name $KEY_VAULT_NAME \
    --query properties.vaultUri \
    --output tsv)"

Key Vault のアクセスを設定し、シークレットを作成する

次の手順では、ポッドから Azure Key Vault のシークレット、キー、または証明書にアクセスする方法を示します。このセクションの例では、ワークロード ID のキーコンテナー内のシークレットへのアクセスを構成しますが、同様の手順を実行してキーまたは証明書へのアクセスを構成できます。

次の例は、Azure RBAC アクセス許可モデルを使用して、ポッドにキーコンテナーへのアクセスを許可する方法を示しています。 Azure Key Vault の Azure RBAC アクセス許可モデルの詳細については、「Azure RBAC を使用して Azure Key Vault にアクセスするためのアクセス許可をアプリケーションに付与する」を参照してください。

az ad signed-in-user show コマンドを使用してサインインしているユーザーのオブジェクト ID を取得し、環境変数として設定します。
```
export CALLER_OBJECT_ID=$(az ad signed-in-user show --query id --output tsv)
```
コマンドを使用して、キーコンテナーに対する Azure RBAC az role assignment create ロールを自分に割り当てます。
```
az role assignment create --assignee $CALLER_OBJECT_ID \
    --role "Key Vault Secrets Officer" \
    --scope $KEY_VAULT_RESOURCE_ID
```

az keyvault secret set コマンドを使用して、Key Vault でシークレットを作成します。

export KEY_VAULT_SECRET_NAME="my-secret"

az keyvault secret set \
    --vault-name $KEY_VAULT_NAME \
    --name $KEY_VAULT_SECRET_NAME \
    --value "Hello\!"

コマンドを使用して、az role assignment create ロールを割り当てます。

az role assignment create \
    --assignee-object-id $MI_PRINCIPAL_ID \
    --role "Key Vault Secrets User" \
    --scope $KEY_VAULT_RESOURCE_ID \
    --assignee-principal-type ServicePrincipal

サービスアカウントに注釈を付ける

kubectl annotate コマンドを使用して、マネージド ID テナント ID でサービスアカウントに注釈を付けます。
```
kubectl annotate sa demo -n demo azure.workload.identity/tenant-id=$MI_TENANT_ID
```
kubectl annotate コマンドを使用して、マネージド ID クライアント ID でサービスアカウントに注釈を付けます。
```
kubectl annotate sa demo -n demo azure.workload.identity/client-id=$MI_CLIENT_ID
```

サンプルアプリケーションをデプロイする

次の kubectl apply コマンドを使用して、ID バインディングを使用して Azure Key Vault にアクセスするためのマネージド ID のアクセストークンを取得するサンプルポッドをデプロイします。

kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: demo
  namespace: demo
  labels:
    azure.workload.identity/use: "true"
  annotations:
    azure.workload.identity/use-identity-binding: "true"
spec:
  serviceAccount: demo
  containers:
    - name: azure-sdk
      # source code: https://github.com/Azure/azure-workload-identity/blob/feature/custom-token-endpoint/examples/identitybinding-msal-go/main.go
      image: ghcr.io/bahe-msft/azure-workload-identity/identitybinding-msal-go:latest-linux-amd64
      env:
        - name: KEYVAULT_URL
          value: ${KEYVAULT_URL}
        - name: SECRET_NAME
          value: ${KEY_VAULT_SECRET_NAME}
  restartPolicy: Never
EOF

サンプルアプリケーションからキーコンテナーへのアクセスを確認する

kubectl describe pod コマンドを使用して、ポッドについて説明し、環境変数と投影されたトークンボリュームマウントが存在することを確認します。
```
kubectl describe pod demo -n demo
```
予想される出力には、 AZURE_CLIENT_ID、 AZURE_TENANT_ID、 AZURE_FEDERATED_TOKEN_FILE、 AZURE_AUTHORITY_HOST、 AZURE_KUBERNETES_TOKEN_PROXYの値が含まれている必要があります。 AZURE_KUBERNETES_SNI_NAME および AZURE_KUBERNETES_CA_FILE。
kubectl logs コマンドを使用して、ポッドがトークンを取得してリソースにアクセスできることを確認します。
```
kubectl logs demo -n demo
```
成功した場合、出力は次の例のようになります。
```
I1107 20:03:42.865180       1 main.go:77] "successfully got secret" secret="Hello!"
```

複数のクラスター間で ID バインディングをスケーリングする

ID バインディングを使用すると、1 つの FIC を使用しながら、複数の AKS クラスターを同じ UAMI にマッピングできます。複数のクラスター間で ID バインディングをスケーリングするには、「 ID バインディングの作成」の手順を繰り返して、同じ UAMI にマップする追加クラスターごとにサンプルアプリケーションからキーコンテナーへのアクセスを確認します (クラスターごとに新しい ID バインディングを作成します)。

リソースをクリーンアップする

この記事で作成したリソースが不要になった場合は、クリーンアップして将来のコストが発生しないようにすることができます。

kubectl delete pod コマンドを使用してポッドを削除します。
```
kubectl delete pod demo -n demo
```
kubectl delete ns コマンドを使用して名前空間を削除します。
```
kubectl delete ns demo
```
az group delete コマンドを使用して、リソースグループとすべての関連リソースを削除します。
```
az group delete --name $RESOURCE_GROUP --yes --no-wait
```

ID バインディングの概念

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-01-28

Azure Kubernetes Service (AKS) で ID バインディングを設定する (プレビュー)

[前提条件]

aks-preview拡張機能をインストールまたは更新する

IdentityBindingPreview機能フラグを有効にする