AKS上のアプリケーションからAzure Key Vault、Microsoft Graph、Storageなどへアクセスする場合、いま最初に検討すべき認証方式は Microsoft Entra Workload ID です。従来のようにアプリケーション資格情報や長期シークレットをPodに持たせるのではなく、KubernetesのServiceAccountとMicrosoft Entra IDをOIDCでフェデレーションし、Pod単位でAzureリソースへ安全にアクセスできます。Microsoft Learnの「Use Microsoft Entra Workload ID with Azure Kubernetes Service (AKS)」では、Workload IDの前提条件、制限、サービスアカウントの注釈、Podラベル、移行方針が整理されています。(Microsoft Learn)
2026年4月時点で重要なのは、「Workload IDを単なるAKSの追加機能として有効化する」のではなく、AKSのID設計、Azure RBAC、サービスアカウント運用、監査証跡をセットで見直すことです。特にセキュリティ管理者、IDチーム、コンプライアンス担当者は、どのPodが、どのIDで、どのAzureリソースへ、どの権限でアクセスするのかを明確にする必要があります。
2026年4月の更新ポイントは「AKSのIDシナリオを分けて考える」こと
Microsoft Learnでは、AKSのIDを5つのシナリオに分けて説明しています。2026年4月23日に更新されたAKSのアクセスとIDに関する公式ドキュメントでは、Workload identityは「PodからAzureサービスへ認証する」シナリオとして明確に位置付けられています。これは、Kubernetes APIへ誰がアクセスするか、AKSクラスター自体がAzure上でどう振る舞うか、といった別のID設計とは分けて考えるべき領域です。(Microsoft Learn)
混同しやすいのは、次の3つです。
| 領域 | 主な目的 | Workload IDとの関係 |
|---|---|---|
| Kubernetes APIの認証・認可 | 管理者やCI/CDがKubernetes APIへアクセスする | 別領域。Microsoft Entra ID統合やKubernetes RBACで設計する |
| AKSクラスターID | AKSがロードバランサー、ディスク、ACRなどを扱う | 別領域。クラスターのマネージドIDで設計する |
| Workload identity | PodがKey Vault、Storage、Graphなどへアクセスする | 本記事の対象。PodとAzureリソースの認証を扱う |
つまり、Microsoft Entra Workload ID AKSの導入で解決できるのは、Pod内アプリケーションのAzureリソース認証です。クラスター管理者権限の整理や、kubectl利用者の認可まで自動的に解決する機能ではありません。
Microsoft Entra Workload ID on AKSの仕組み
Microsoft Entra Workload IDは、AKSクラスターをトークン発行者として扱い、KubernetesのServiceAccountトークンをMicrosoft Entra ID側で検証できるようにします。Microsoft Entra IDはOIDCのディスカバリードキュメントと公開署名キーを使ってトークンの正当性を確認し、Azure Identity client libraryまたはMSALを通じてMicrosoft Entraトークンへ交換します。(Microsoft Learn)
認証の流れを実務向けに言い換えると、次のようになります。
| ステップ | 何が起きるか | 管理上の確認ポイント |
|---|---|---|
| 1 | AKSでOIDC issuerとWorkload IDを有効化する | クラスターごとにOIDC issuer URLを把握する |
| 2 | Kubernetes ServiceAccountを作成する | namespace、ServiceAccount名、用途を台帳化する |
| 3 | ユーザー割り当てマネージドIDを作成する | 所有者、環境、権限範囲を明確にする |
| 4 | フェデレーションID資格情報を作成する | issuer、subject、audienceが正確に一致しているか確認する |
| 5 | Podに必須ラベルとServiceAccountを設定する | Webhookによる環境変数とトークンボリューム注入を確認する |
| 6 | Azure RBACで対象リソースへの権限を付与する | Key VaultやStorageなどリソース単位で最小権限にする |
ここで大切なのは、Workload IDは「Azureリソースへアクセスするための本人確認」を成立させる仕組みであり、実際にKey Vaultのシークレットを読めるかどうかはAzure RBACなどの権限設定で決まる点です。認証と認可を分けてレビューしないと、「トークンは取れるがリソースにアクセスできない」「逆に広すぎる権限を与えてしまう」といった失敗が起きます。
前提条件と制限事項で必ず確認すべき点
Microsoft Learnでは、AKSでMicrosoft Entra Workload IDを使う前提としてAKS 1.22以降、Azure CLI 2.47.0以降が示されています。また、フェデレーションID資格情報はマネージドIDごとに最大20個、仮想ノードアドオンは非対応、フェデレーションID資格情報の反映には数秒かかるとされています。(Microsoft Learn)
| 確認項目 | 実務での見方 |
|---|---|
| AKSバージョン | 古いクラスターではWorkload IDを前提にした設計ができない可能性がある |
| Azure CLI | IaCや運用端末のCLIバージョンが古いと手順でつまずく |
| フェデレーションID資格情報の上限 | 1つのマネージドIDを多くのServiceAccountで使い回す設計は早めに限界を迎える |
| 反映遅延 | 作成直後の疎通テスト失敗を恒久障害と誤判定しない |
| 仮想ノード | 対象ワークロードでVirtual Nodesを使っている場合は設計を見直す |
多国籍・多リージョン環境では、リージョン制約も確認が必要です。フェデレーションID資格情報の制限ページでは、ユーザー割り当てマネージドIDに対するフェデレーションID資格情報の作成がサポートされないリージョンが示されており、該当する場合はサポート済みリージョンに作成したマネージドIDを使う設計が必要になります。(Microsoft Learn)
最短で理解する設定手順
新規または既存のAKSクラスターでは、OIDC issuerとMicrosoft Entra Workload IDを有効化します。公式手順では、新規クラスター作成時に --enable-oidc-issuer と --enable-workload-identity を指定し、既存クラスターでは az aks update で同じ機能を有効化する流れが示されています。(Microsoft Learn)
az aks update \
--resource-group "<resource-group>" \
--name "<cluster-name>" \
--enable-oidc-issuer \
--enable-workload-identity次に、ユーザー割り当てマネージドIDを作成し、そのクライアントIDをKubernetes ServiceAccountに注釈として設定します。
apiVersion: v1
kind: ServiceAccount
metadata:
name: workload-identity-sa
namespace: app-prod
annotations:
azure.workload.identity/client-id: "<managed-identity-client-id>"その後、AKSのOIDC issuer、ServiceAccountのsubject、audienceを使ってフェデレーションID資格情報を作成します。公式手順では、audienceに api://AzureADTokenExchange を指定する例が示されています。(Microsoft Learn)
az identity federated-credential create \
--name "<federated-credential-name>" \
--identity-name "<managed-identity-name>" \
--resource-group "<resource-group>" \
--issuer "<aks-oidc-issuer-url>" \
--subject "system:serviceaccount:app-prod:workload-identity-sa" \
--audience "api://AzureADTokenExchange"最後に、Workload IDを使うPodへ必須ラベルを付けます。azure.workload.identity/use: "true" が付いたPodだけが、mutating admission webhookによる環境変数と投影ServiceAccountトークンボリュームの注入対象になります。(Microsoft Learn)
apiVersion: apps/v1
kind: Deployment
metadata:
name: sample-app
namespace: app-prod
spec:
template:
metadata:
labels:
azure.workload.identity/use: "true"
spec:
serviceAccountName: workload-identity-sa
containers:
- name: app
image: "<your-image>"ServiceAccount設計は「権限の境界」として扱う
Microsoft Entra Workload IDでは、ServiceAccountとMicrosoft Entra側のオブジェクトの関係として、1対1、多対1、1対多のマッピングがサポートされています。ServiceAccountの注釈を更新した場合、変更を有効にするにはPodの再起動が必要です。(Microsoft Learn)
設計時の判断基準は次のとおりです。
| 設計 | 向いているケース | 注意点 |
|---|---|---|
| 1 ServiceAccount : 1 マネージドID | 本番環境、機密データ、監査対象システム | 管理対象は増えるが、追跡と最小権限に強い |
| 複数ServiceAccount : 1 マネージドID | 同じ権限でよい同一アプリ群 | どのPodが使ったかの切り分けが難しくなる |
| 1 ServiceAccount : 複数ID | 例外的に複数のAzureリソース権限を切り替える場合 | 注釈変更や運用ミスのリスクが高い |
セキュリティを優先するなら、本番環境では「アプリケーション単位」または「機能単位」でユーザー割り当てマネージドIDを分けるのが現実的です。たとえば、注文APIがKey Vaultのシークレットを読むIDと、バックオフィスバッチがStorageへ書き込むIDを同じにしない設計です。
Azure Identity SDKの確認は移行前に必須
アプリケーション側では、Azure Identity client libraryの DefaultAzureCredential、ChainedTokenCredential、または WorkloadIdentityCredential を使えます。Microsoft Learnでは、各言語のAzure Identity client libraryについて最小パッケージバージョンが示されています。(Microsoft Learn)
| 言語 | ライブラリ | 最小バージョン |
|---|---|---|
| .NET | Azure.Identity | 1.9.0 |
| C++ | azure-identity-cpp | 1.6.0 |
| Go | azidentity | 1.3.0 |
| Java | azure-identity | 1.9.0 |
| Node.js | @azure/identity | 3.2.0 |
| Python | azure-identity | 1.13.0 |
既存アプリがすでに DefaultAzureCredential を使っている場合、移行の難易度は下がります。一方、古いSDKやIMDS前提の実装に強く依存している場合は、アプリ改修、移行サイドカー、一時的な併用のどれを選ぶかを事前に決める必要があります。
既存のpod-managed identityから移行する場合の考え方
既存AKSでpod-managed identityを使っている場合、Microsoft Learnは現在のAzure Identity SDKバージョンに応じて、最新SDKでの並行移行、Linuxコンテナー向けの移行サイドカー、SDK書き換えの3つのパスを示しています。移行サイドカーはIMDSトランザクションをOIDCへプロキシする一時策であり、長期運用を前提にするものではありません。(Microsoft Learn)
| 現在の状態 | 推奨される進め方 |
|---|---|
| 最新のAzure Identity SDKを利用中 | Workload IDを並行展開し、認証確認後にpod-managed identityを削除する |
| 古いSDKかつLinuxコンテナー | 移行サイドカーで一時的に動かし、SDK更新計画を立てる |
| 古いSDKで長期運用が必要 | アプリケーションを最新SDKへ更新してから移行する |
| Windowsコンテナー | 移行サイドカーではなく、SDK更新を前提に計画する |
移行で失敗しやすいのは、ID基盤チームがフェデレーション信頼だけを作り、アプリチームがPod再起動やSDK対応を後回しにするケースです。移行計画には、フェデレーションID資格情報の作成、Podラベル追加、ServiceAccount差し替え、Azure RBAC付与、ログ確認、旧pod-managed identity削除までを1つの変更作業として含めるべきです。
コンプライアンス担当者が見るべき証跡
Workload IDの導入後、監査で問われるのは「シークレットを使っていないか」だけではありません。むしろ重要なのは、アクセス権の根拠と変更履歴です。
| 監査観点 | 確認するもの |
|---|---|
| IDの所有者 | ユーザー割り当てマネージドIDの命名、タグ、管理責任者 |
| ワークロードとの紐付け | namespace、ServiceAccount、subjectの一覧 |
| 権限の妥当性 | Key Vault Secrets Userなど、対象リソース単位のAzure RBAC |
| 変更管理 | フェデレーションID資格情報、ServiceAccount注釈、Deployment変更の履歴 |
| 動作確認 | Podログ、Key Vaultや対象サービス側のアクセスログ、失敗時の再試行ログ |
| 例外管理 | 一時的な移行サイドカー、共有ID、広いスコープのロール割り当て |
Microsoft Entra Workload IDは、ワークロードIDの保護、シークレット管理の削減、条件付きアクセスポリシーやID保護などの活用と組み合わせて考えるべき領域です。Microsoft Entraの公式ドキュメントでも、ワークロードIDは人間のIDとは異なる非人間IDとして扱われ、保護対象として重要性が高まっていると説明されています。(Microsoft Learn)
よくある失敗と回避策
Podラベルを付け忘れる
azure.workload.identity/use: "true" がないPodはWebhookによる注入対象になりません。ServiceAccountの注釈だけを設定しても、アプリケーションが期待どおりにトークンを取得できない可能性があります。Deploymentテンプレート側にラベルが入っているかを確認してください。
subjectの文字列を間違える
フェデレーションID資格情報では、issuerとsubjectの組み合わせがトークン交換の重要な照合条件です。subjectは通常、次の形式になります。
system:serviceaccount:<namespace>:<service-account-name>namespaceやServiceAccount名を変更した場合、フェデレーションID資格情報も見直す必要があります。subjectの設定ミスは作成時に気づきにくく、実際のトークン交換時に失敗として表面化します。(Microsoft Learn)
RBAC反映待ちを障害と誤判定する
公式手順では、フェデレーションID資格情報の反映に数秒かかる可能性があり、Azure RBACのロール割り当ては反映に最大10分かかる場合があるとされています。構築直後の疎通確認では、短時間の待機と再試行を前提にしてください。(Microsoft Learn)
マネージドIDを共有しすぎる
1つのマネージドIDを多くのServiceAccountで共有すると、フェデレーションID資格情報の上限、権限の肥大化、監査時の説明困難という問題が出ます。共有してよいのは、同じ環境、同じアプリケーション境界、同じ権限で問題ない場合に限定するのが安全です。
移行サイドカーを恒久運用する
移行サイドカーは、古いSDKをすぐに更新できない場合の一時策です。長期的には、Azure Identity SDKを更新し、アプリケーションがWorkload IDを直接利用できる状態へ移行するほうが、運用・監査・障害解析の面で安定します。
導入前チェックリスト
Workload IDをAKSに導入する前に、次の項目を確認してください。
| チェック項目 | 完了条件 |
|---|---|
| 対象ワークロードの棚卸し | AzureリソースへアクセスするPodを一覧化している |
| 認証方式の方針 | シークレット、pod-managed identity、Workload IDのどれを使うか決めている |
| SDK確認 | 対象アプリのAzure Identity SDKが対応バージョン以上である |
| ID設計 | ServiceAccountとマネージドIDの対応表がある |
| 権限設計 | Azure RBACをリソース単位・最小権限で設計している |
| IaC管理 | AKS設定、ServiceAccount、フェデレーションID資格情報、RBACをコード化している |
| 検証手順 | Pod Ready、環境変数、トークン取得、対象リソースアクセスを確認できる |
| 監査証跡 | 変更履歴、承認、アクセスログの保存方法が決まっている |
まとめ: 次にやるべきこと
Azure Kubernetes ServiceでMicrosoft Entra Workload IDを使う価値は、Podに長期シークレットを持たせず、KubernetesのServiceAccountとMicrosoft Entra IDを結び付けてAzureリソースへアクセスできる点にあります。ただし、導入の成否は「機能をオンにしたか」ではなく、ServiceAccount設計、フェデレーションID資格情報、Azure RBAC、SDK対応、監査証跡まで一貫して設計できているかで決まります。
まずは本番導入前に、1つのnamespace、1つのServiceAccount、1つのユーザー割り当てマネージドID、1つのKey Vaultを使った最小構成で検証してください。そのうえで、アプリケーションごとのID分離、権限範囲、移行対象、監査ログを整理すると、セキュリティ管理者、IDチーム、コンプライアンス担当者が合意しやすい導入計画になります。
コメント