ID バインディングは、Azure Kubernetes Service (AKS) のプレビュー機能であり、既存の ワークロード ID 機能を 拡張して、ユーザー割り当てマネージド ID (UAMI) でのフェデレーション ID 資格情報 (FIC) に関するスケール制限に対処します。
AKS のワークロード ID では、1 つの UAMI に 20 個を超える FIC を含めることはできません。 大規模な Kubernetes プラットフォームのデプロイは、20 を超えるクラスターにまたがる場合があります (各クラスターには一意の発行者があります)、または同じ UAMI へのマッピングを必要とする多数の <namespace, service-account> の組み合わせがあり、FIC クォータが使い果たされます。
ID バインディングは、複数の AKS クラスターが UAMI ごとに 1 つの FIC を使用して同じ UAMI を共有できるようにすることで、この制限に対処します。 このアプローチにより、スケーラビリティが大幅に向上し、Microsoft Entra 認証を必要とする大規模な AKS 環境の操作が簡略化されます。
Important
AKS のプレビュー機能は、セルフサービスのオプトイン単位で利用できます。 プレビューは、"現状有姿のまま" および "利用可能な限度" で提供され、サービス レベル アグリーメントおよび限定保証から除外されるものとします。 AKS プレビューは、ベストエフォート ベースでカスタマー サポートによって部分的にカバーされます。 そのため、これらの機能は運用環境での使用を目的としていません。 詳細については、次のサポート記事を参照してください。
ID バインディングとは
ID バインディングは、 1 つの UAMI と、その ID で Microsoft Entra 認証を必要とするワークロードを持つ 1 つの AKS クラスターの間のリソース マッピングです。
たとえば、クラスターMI-1、AKS-cluster-1、AKS-cluster-2で実行されているワークロードに必要な UAMI、AKS-cluster-3があるとします。 次の各クラスターに MI-1 をマップする 3 つの ID バインディングを作成できます。
-
ID バインディングの
IB-AMI-1をAKS-cluster-1にマッピングします。 -
ID バインディングの
IB-BMI-1をAKS-cluster-2にマッピングします。 -
ID バインディングの
IB-CMI-1をAKS-cluster-3にマッピングします。
複数のクラスターで同じ UAMI が必要な場合でも、UAMI ごとに 1 つの フェデレーション ID 資格情報のみが作成され、以前の 20 の FIC 制限に対処します。 ID バインディングを作成すると、AKS は、その UAMI の 1 つの FIC を自動的に作成 (または再利用) します。 次の図は、以前のワークロード ID モデルと新しい ID バインディング モデルの違いを示しています。
ID バインディングを作成し、UAMI がクラスターに対して承認されたら、そのマネージド ID を Microsoft Entra トークン取得に使用することを許可される名前空間とサービス アカウント (細かくまたはまとめて) を指定する ClusterRole オブジェクトと ClusterRoleBinding オブジェクトを定義する必要があります。
Azure ID クライアント ライブラリで ID バインディングを使用する
アプリケーション ワークロードで ID バインディングを使用するには、次の手順に従います。
- 最低限必要な Azure ID パッケージを使用していることを確認します。
-
WorkloadIdentityCredentialを使用して、この機能を選択します。 この機能は、ManagedIdentityCredentialまたはDefaultAzureCredentialではサポートされていません。
次の表は、パッケージの最小バージョンと、サポートされている各言語の ID バインディングを有効にする方法の概要を示しています。
| Language | パッケージ | 最小バージョン | 有効にする方法 |
|---|---|---|---|
| .NET |
Azure.Identity または Azure。Core |
v1.18.0-beta.3 のみ または v1.55.0 以降 |
WorkloadIdentityCredential ID バインディング モードは既定で無効になっています。
WorkloadIdentityCredentialOptions.IsAzureProxyEnabled を true に設定します。 |
| Go | azidentity | v1.14.0-beta.3 以降 |
WorkloadIdentityCredentialOptions.EnableAzureProxy を true に設定します。 |
| Java | azure-identity | v1.19.0-beta.2 以降 |
enableAzureProxy() で WorkloadIdentityCredentialBuilder を呼び出します。 |
| JavaScript | @azure/identity | 4.14.0-beta.2 以降 |
enableAzureProxy で true を WorkloadIdentityCredentialOptions に設定します。 |
| Python | azure-identity | 1.26.0b2 以降 |
enable_azure_proxy=True で WorkloadIdentityCredential を設定します。 |
注
.NET では、ID バインディングのサポートは Azure.Identity v1.18.0-beta.3、または代替として Azure.Core v1.55.0 以降でのみ利用可能です。 現在、この機能を含むAzure.Identityの他のバージョンはありません。
よく寄せられる質問 (FAQ)
同じ UAMI を使用するクラスター間で ID の同一性 (名前空間とサービス アカウントの同一性) が必要ですか?
No. ID バインディングでは、名前空間/サービス アカウントの同一性は必要ありません。 ロールベースのアクセス制御 (RBAC) を使用してマネージド ID を使用できる各クラスター内の名前空間とサービス アカウントを明示的に承認するのは、クラスター オペレーターの責任です。
同じ UAMI に対して複数の ID バインディングを作成できますか?
Yes. AKS によってその UAMI に対して保持される OIDC 発行者 URL は、同じマネージド ID を参照しているすべての ID バインディングで同じです。
ID バインディングを作成するには、どのようなアクセス許可が必要ですか?
必要な Azure Resource Manager (ARM) アクセス許可:
Microsoft.ContainerService/managedClusters/identityBindings/*Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials/*
注
ID バインディングを作成すると、AKS によって FIC が自動的に作成されます。 呼び出し元に FIC リソースを作成するアクセス許可がない場合、ID バインディングの作成は失敗します。
必要な Kubernetes アクセス許可:
-
ClusterRoleオブジェクトとClusterRoleBindingオブジェクト (クラスター管理者または同等のオブジェクト) を作成する機能。
UAMI のすべての ID バインディングを削除した後、自動作成された FIC はどうなりますか?
現在、UAMI を参照する最後の ID バインディングが削除されても、FIC の自動 GC は行われません。 オペレーターは、残りの依存関係を中断しないように、その UAMI のすべての ID バインディングが削除されたことを確認した後にのみ、FIC を手動でクリーンアップする必要があります。
ID バインディングには、どのようなネットワークの前提条件がありますか?
以前は、ワークロード ID は、サービス アカウント トークンを Microsoft Entra アクセス トークンと交換できるように、 login.microsoftonline.com へのエグレスを必要としました。 ID バインディングを使用すると、トークン交換要求は、AKS によって動作するクラスター固有の ID バインディング プロキシを経由してルーティングされます。 トークン交換のために login.microsoftonline.com への直接エグレスは必要ありません。
ID バインディングにはどのような制限がありますか?
API サーバー仮想ネットワーク統合を使用して構成されたクラスターでは、ID バインディングはまだサポートされていません。