AKSのアクセスとID管理でまず押さえるべき結論は、「誰がkubectlできるか」だけでは不十分という点です。2026年4月23日に更新されたMicrosoft Learnの「Access and identity options for Azure Kubernetes Service（AKS）」では、AKSのID利用シナリオが5つに整理されています。認証、認可、kubeconfig取得などのAzure Resource Manager側の権限、クラスターがAzureリソースを操作するためのID、PodがAzureサービスへ接続するためのIDを分けて設計する必要があります。(Microsoft Learn)
特に今回の更新ポイントは、AKS resource authorization（Azure Resource Manager）が独立したシナリオとして前面に出たことです。つまり、Kubernetes RBACを細かく設定していても、「誰がAKSリソースからkubeconfigを取得できるか」をAzure RBACで管理していなければ、運用上の抜け穴になり得ます。IT管理者は権限棚卸しの観点を広げ、プロダクトオーナーは監査・運用責任の分界点を明確にする必要があります。(GitHub)
2026年4月更新ポイント：AKSのアクセスとID管理は「5つの問い」で考える
Microsoft公式ドキュメントでは、AKSのID利用を次の5つのシナリオに分けています。従来のように「認証と認可」だけで見るのではなく、人・Azure管理操作・クラスター・Podを別々に扱う構成です。(Microsoft Learn)
| シナリオ | 答えるべき問い | 実務で見るべき設定 |
|---|---|---|
| Kubernetes control-plane authentication | Kubernetes APIを呼び出しているのは誰か | Microsoft Entra ID、ローカルアカウント、外部IdP |
| Kubernetes control-plane authorization | 認証後に何を実行できるか | Kubernetes RBAC、Microsoft Entra ID authorization |
| AKS resource authorization | AKSリソース自体に対して誰がAzure操作できるか | Azure RBAC、kubeconfig取得権限 |
| Cluster identity | AKSクラスターがAzureリソースをどう操作するか | Control-plane identity、kubelet identity、アドオンID |
| Workload identity | PodがAzureサービスへどう認証するか | Microsoft Entra Workload ID、ServiceAccount連携 |
今回の整理で重要なのは、アクセス制御の対象がKubernetes APIだけではないという点です。kubectlの操作権限、AzureポータルやAzure CLIからのAKS管理操作、ロードバランサーやディスクを操作するクラスターID、Key VaultやStorageへアクセスするアプリケーションIDは、それぞれ別の設計対象です。
公式ドキュメントで何が変わったか
Microsoft Learnの公開履歴を見ると、2026年4月の更新では構成の見直しが大きなテーマです。GitHub上の履歴では、AKS resource authorizationがトップレベルのシナリオに昇格し、全体が「4つのシナリオ」から「5つのシナリオ」に広がったことが示されています。(GitHub)
| 更新ポイント | 影響を受ける読者 | 実務上の意味 |
|---|---|---|
| AKS resource authorizationが独立したシナリオになった | IT管理者、セキュリティ担当 | kubeconfig取得やAKSリソース操作をAzure RBACで棚卸しする必要がある |
| 認証と認可の概念ドキュメントが分割された | AKS運用者、設計者 | 「ログインできる」と「操作できる」を分けて説明しやすくなった |
| Microsoft Entra ID authorizationの手順ドキュメントが再構成された | マルチクラスター運用チーム | 標準KubernetesリソースとCRD向けABAC条件の考え方を分けて設計しやすくなった |
| AKS service permissions referenceが独立ページ化された | インフラ担当、Platform Engineeringチーム | カスタムVNet、ディスク、Private DNSなどで必要なAzure権限を参照しやすくなった |
認証・認可の概念ページは、Kubernetes APIへの認証を扱うページと、認証後の操作許可を扱うページに分割されています。これは、Entra IDでログインできる状態と、Kubernetes上でPodやDeploymentを操作できる状態を混同しないために重要です。(GitHub)
また、AKS service permissions referenceでは、クラスター作成時のID、実行時のクラスターID、追加のクラスターID権限、ノードアクセスに必要な権限が参照情報として整理されています。カスタムネットワークやPrivate DNS、Azure Diskを使う環境では、ここを確認せずに設計すると、作成時やスケール時に権限不足で詰まりやすくなります。(GitHub)
Kubernetes control-plane authentication：まず「誰がAPIに入れるか」を決める
Kubernetes control-plane authenticationは、Kubernetes APIサーバーへアクセスするユーザーやサービスプリンシパルの身元を確認する仕組みです。Microsoft公式ドキュメントでは、AKSの認証方法としてMicrosoft Entra ID、ローカルアカウント、OIDC準拠の外部IDプロバイダーが整理されています。特にMicrosoft Entra IDは推奨パスとして説明されています。(Microsoft Learn)
実務では、まず次の方針にすると判断しやすくなります。
| 要件 | 推奨される考え方 |
|---|---|
| 社内ユーザーがkubectlを使う | Microsoft Entra IDで認証し、ユーザーやグループを中央管理する |
| MFAや条件付きアクセスを適用したい | Microsoft Entra IDを前提にする |
| OktaやGoogle Workspaceなど別IdPが必須 | 外部IDプロバイダー連携を検討する。ただしプレビューや制約を確認する |
| 緊急時用の管理者アクセスを残したい | ローカルアカウントではなく、PIMやBreak-glassアカウント設計で代替できるか検討する |
注意したいのは、ローカルアカウントです。AKSではローカルアカウントが有効な状態だと、Microsoft Entra IDの監査や条件付きアクセスを通らない管理者アクセスが残る可能性があります。Microsoftのローカルアカウント管理ドキュメントでも、--adminアクセスが監査しづらいバックドアになり得る点が説明されています。(Microsoft Learn)
既存クラスターでローカルアカウントを無効化する場合は、次のようなコマンドで設定できます。
az aks update \
--resource-group <resource-group> \
--name <cluster-name> \
--disable-local-accounts既存クラスターで過去にローカルアカウントが使われていた場合は、証明書ローテーションの必要性も確認してください。公式ドキュメントでは、既存クラスターでローカルアカウントを無効化した後、過去にアクセスされた証明書を失効させるために証明書ローテーションが必要になるケースが説明されています。(Microsoft Learn)
Kubernetes control-plane authorization：「ログイン後に何ができるか」を決める
認証で「誰か」が分かった後は、authorizationで「何を許可するか」を決めます。AKSでは、Kubernetes RBACとMicrosoft Entra ID authorizationの2つのモデルを利用できます。公式ドキュメントでは、両方を同じクラスターで使える一方、既定の考え方としてMicrosoft Entra ID authorizationを推奨し、細かなクラスター内権限にはKubernetes RBACを使う方針が示されています。(Microsoft Learn)
| 比較軸 | Kubernetes RBAC | Microsoft Entra ID authorization |
|---|---|---|
| 権限の置き場所 | クラスター内のRole、ClusterRole、RoleBinding | Azureロール割り当て |
| 向いている用途 | Namespace単位の細かい権限、GitOps管理 | 複数クラスターの中央統制 |
| 管理スコープ | 基本的にクラスター単位 | リソース、リソースグループ、サブスクリプション、管理グループ |
| 監査 | Kubernetes側の監査ログ | Azure Activity Log |
| 条件付きアクセスやPIM | 直接は適用しにくい | Microsoft Entra IDの仕組みを活用しやすい |
| CRDの制御 | Kubernetes RBACで個別定義 | ABAC条件でAPI groupやkindを絞れる |
マルチクラスター運用では、Microsoft Entra ID authorizationの利点が大きくなります。Azureロール割り当てをリソースグループやサブスクリプションのスコープで設定すれば、現在のクラスターだけでなく、将来同じスコープに作成されるAKSにも効く可能性があります。便利な一方で、スコープを広くしすぎると意図せず権限が広がるため、最小権限の原則で設計する必要があります。(Microsoft Learn)
CRDを多用している環境では、ABAC条件も確認しましょう。Microsoft Entra ID authorizationでは、カスタムリソースのAPI groupやkindを条件としてアクセスを絞る考え方が示されています。Gatekeeper、Kyverno、Argo CD、Crossplaneなどを利用する環境では、CRDの読み取り権限が過剰になっていないかを点検する価値があります。(Microsoft Learn)
AKS resource authorization：kubeconfig取得権限を見落とさない
今回の更新で最も実務インパクトが大きいのが、AKS resource authorizationです。これはKubernetes API内の権限ではなく、Azure Resource Manager上のAKSリソースに対する操作権限です。代表例が、az aks get-credentialsでkubeconfigを取得できるかどうかです。(Microsoft Learn)
kubeconfigは、kubectlがAKSクラスターへ接続するための設定ファイルです。Microsoft公式ドキュメントでは、Azure RBACを使って、誰がAKSクラスターのkubeconfigを取得できるかを制御できると説明されています。(Microsoft Learn)
特に注意すべきロールは次の2つです。
| Azureロール | できること | 注意点 |
|---|---|---|
| Azure Kubernetes Service Cluster User Role | clusterUser用のkubeconfigを取得できる | Entra ID統合クラスターではログイン後の権限に従う |
| Azure Kubernetes Service Cluster Admin Role | clusterAdmin用のkubeconfigを取得できる | 管理者権限につながるため、付与対象を厳しく制限する |
Microsoft公式ドキュメントでは、Microsoft Entra IDを使うクラスターの場合、Cluster User Roleのユーザーはログイン後にEntra IDのユーザーやグループ設定に基づいてアクセスします。一方、Cluster Admin Roleは管理者アクセスになります。また、Microsoft Entra IDを使わないクラスターでは、Cluster User RoleがCluster Admin Roleと同じ効果を持つと説明されています。(Microsoft Learn)
この点は、監査でよく抜けます。Kubernetes RBACだけを見て「開発者はnamespace Aしか操作できない」と判断していても、Azure側でCluster Admin Roleが付与されていれば、別経路で強い権限を持つ可能性があります。AKSの権限棚卸しでは、KubernetesのRoleBindingだけでなく、Azureロール割り当ても必ず確認してください。
確認の第一歩は、AKSリソーススコープでのロール割り当ての棚卸しです。
AKS_ID=$(az aks show \
--resource-group <resource-group> \
--name <cluster-name> \
--query id -o tsv)
az role assignment list \
--scope "$AKS_ID" \
--include-inherited \
-o table見るべきポイントは、個人ユーザーに直接付与されていないか、退職者や異動者が含まれるグループに付与されていないか、リソースグループやサブスクリプションから意図せず継承されていないかです。
Cluster identity：AKSクラスター自身のAzure権限を最小化する
Cluster identityは、AKSクラスターがAzureリソースを操作するためのIDです。たとえば、ロードバランサーの作成、ディスクのアタッチ、Azure Container Registryからのイメージ取得などで使われます。公式ドキュメントでは、control-plane identity、kubelet identity、アドオンや拡張機能のIDが主なIDとして説明されています。(Microsoft Learn)
AKSでは、システム割り当てマネージドIDとユーザー割り当てマネージドIDを利用できます。公式ドキュメントでは、AKSクラスターはMicrosoft Entraからトークンを取得するためにマネージドIDを使い、そのIDにAzure RBACロールを割り当ててAzureリソースへの権限を付与すると説明されています。(Microsoft Learn)
| IDの種類 | 特徴 | 向いているケース |
|---|---|---|
| システム割り当てマネージドID | AKSリソースとライフサイクルが連動する | 標準的なクラスター、単独利用の環境 |
| ユーザー割り当てマネージドID | 独立したAzureリソースとして作成する | 事前に権限付与したい環境、複数リソースでIDを共有したい環境 |
| kubelet identity | ノード上のkubeletがAzureサービスへ認証する | ACRからのイメージpullなど |
| アドオン、拡張機能のID | アドオンごとに使われる場合がある | 監視、Ingress、セキュリティ拡張など |
注意点は、マネージドIDのスコープを広くしすぎないことです。公式ドキュメントでも、Azure RBACロールを割り当てる際は、必要最小限のスコープに制限することがベストプラクティスとして示されています。(Microsoft Learn)
また、既存クラスターでIDの種類を変更する場合、制御プレーンのコンポーネントが新しいIDへ切り替わるまで時間がかかることがあります。公式ドキュメントでは、古いIDのトークンが期限切れになるまで旧IDが使われ続け、切り替えに数時間かかる可能性があると説明されています。(Microsoft Learn)
Workload identity：PodからAzureサービスへ安全に接続する
Workload identityは、Pod内のアプリケーションがKey Vault、Storage、Microsoft GraphなどのMicrosoft Entraで保護されたAzureサービスへアクセスするための仕組みです。Microsoft Entra Workload IDは、KubernetesのServiceAccountトークンとOIDCフェデレーションを使い、PodがAzureリソースへ安全に認証できるようにします。(Microsoft Learn)
従来のように、アプリケーションのクライアントシークレットや接続文字列をKubernetes Secretに保存する設計は、漏えい時の影響が大きくなります。Workload IDを使うと、Podに関連付けたServiceAccountを通じてMicrosoft Entra IDへフェデレーションし、Azure SDKやMSALからトークンを取得できます。公式ドキュメントでも、Azure Identity client librariesやMSALを使ってAzureリソースへアクセスできると説明されています。(Microsoft Learn)
実務での使い分けは次のとおりです。
| やりたいこと | 使う仕組み |
|---|---|
| AKSクラスターがロードバランサーやディスクを操作する | Cluster identity、managed identity |
| ノードがACRからイメージをpullする | kubelet identity |
| アプリケーションPodがKey Vaultからシークレットを読む | Microsoft Entra Workload ID |
| PodがStorageやCosmos DBへアクセスする | Microsoft Entra Workload ID |
| 人間がkubectlで操作する | Microsoft Entra ID認証と認可 |
特に覚えておきたいのは、managed identityとWorkload IDは同じものではないという点です。managed identityはAKSクラスターやAzureリソース側のID管理であり、Workload IDはPodで動くアプリケーションの認証に使う設計です。公式ドキュメントでも、システム割り当て・ユーザー割り当てマネージドIDとWorkload identityは別の用途であると説明されています。(Microsoft Learn)
また、新規ワークロードでMicrosoft Entra pod-managed identityを使うのは避けるべきです。公式のAccess and identityページでは、非推奨のMicrosoft Entra pod-managed identityを新規ワークロードで使わないよう明記されています。(Microsoft Learn)
実務での設計パターン
AKSのアクセスとID管理は、最初から完璧に作り込むよりも、責任範囲ごとに段階的に固めると失敗しにくくなります。
小規模チームのAKS
小規模な開発チームでは、まずMicrosoft Entra IDで人の認証を統一し、ローカルアカウントを無効化することを優先します。開発者にはCluster Admin Roleを直接付与せず、必要なnamespaceに限定したKubernetes RBACまたはMicrosoft Entra ID authorizationのロールを割り当てます。
この段階でのゴールは、退職・異動・一時的な権限昇格をEntra ID側で管理できる状態にすることです。個人ユーザーへの直接ロール付与を減らし、Entra IDグループを単位にすると、棚卸しが容易になります。
複数クラスターを運用する組織
複数のAKSクラスターを持つ組織では、Microsoft Entra ID authorizationを中心に設計すると、クラスターごとのRoleBinding管理を減らせます。公式ドキュメントでは、Azureロール割り当てをリソースグループ、サブスクリプション、管理グループのスコープで設定でき、複数クラスターを統制しやすいことが説明されています。(Microsoft Learn)
ただし、スコープが広いロールは強力です。リソースグループ単位で付与した権限が、将来作成されるAKSにも適用される可能性があります。Platform Engineeringチームは、環境ごとにリソースグループを分け、開発・検証・本番で継承範囲を明確にするべきです。
GitOpsを使うチーム
Argo CDやFluxなどでGitOpsを使っている場合、namespace単位のKubernetes RBACをマニフェストとして管理する方法も有効です。アプリケーションのDeployment、Service、ConfigMapと同じリポジトリでRoleやRoleBindingを管理できるため、変更レビューがしやすくなります。
一方で、Kubernetes RBACは基本的にクラスター単位です。複数クラスターに同じ権限を適用するには、各クラスターへマニフェストを配布する必要があります。人のアクセス管理を中央化したい場合は、Microsoft Entra ID authorizationと組み合わせる設計を検討してください。(Microsoft Learn)
失敗しやすいポイントと対策
認証と認可を混同する
「Entra IDでログインできる」は「Podを作成できる」と同じではありません。認証は誰かを確認する仕組みで、認可は何を許可するかを決める仕組みです。障害対応時に「ログインはできるが操作できない」という問い合わせが起きる場合、この切り分けができていないことが多いです。
対策として、設計書や運用手順では「認証方式」「Kubernetes APIの認可方式」「Azure RBACのkubeconfig取得権限」を別項目にしてください。
kubeconfig取得権限を棚卸ししていない
AKSでは、Kubernetes内の権限だけでなく、Azure側でkubeconfigを取得できる人を管理する必要があります。特にCluster Admin Roleは強い権限につながるため、恒久的に付与する対象を最小化してください。(Microsoft Learn)
対策として、四半期ごとにAzureロール割り当てを確認し、個人ユーザーへの直接付与、退職者が含まれるグループ、広すぎるサブスクリプションスコープの付与を見直します。
ローカルアカウントを本番に残している
ローカルアカウントは、Entra IDの監査や条件付きアクセスを回避する経路になり得ます。Microsoft公式ドキュメントでも、本番環境ではローカルアカウントを無効化することが推奨されています。(Microsoft Learn)
対策として、新規クラスター作成時からローカルアカウントを無効化し、既存クラスターでは無効化後の証明書ローテーション要否まで確認します。
クラスターIDとPodのIDを混同する
ロードバランサー作成やAzure Disk操作に使うIDと、アプリケーションPodがKey VaultへアクセスするIDは別です。ここを混同すると、Podに不要な広い権限を与えたり、逆にクラスター操作に必要な権限が不足したりします。
対策として、権限設計表を「クラスターが使うID」と「アプリケーションが使うID」に分けます。アプリケーションのAzureアクセスはWorkload IDを基本にし、クラスター運用の権限はmanaged identityで最小化します。
非推奨のPod Managed Identityを新規採用する
新規ワークロードでMicrosoft Entra pod-managed identityを選ぶのは避けるべきです。公式ドキュメントでは、新しいワークロードでは非推奨のMicrosoft Entra pod-managed identityを使わないよう明記されています。(Microsoft Learn)
対策として、新規アプリケーションはMicrosoft Entra Workload IDを前提にし、既存環境では移行計画を立てます。ServiceAccountとAzure側のID対応、フェデレーション資格情報、SDKの対応バージョンを確認してください。
2026年4月時点のAKS権限チェックリスト
AKSをすでに運用している場合は、次の順番で確認すると効率的です。
| チェック項目 | 確認内容 | 優先度 |
|---|---|---|
| Microsoft Entra ID認証 | 人間のkubectlアクセスがEntra IDに統一されているか | 高 |
| ローカルアカウント | 本番クラスターで無効化されているか | 高 |
| kubeconfig取得権限 | Cluster Admin RoleやCluster User Roleの付与対象が妥当か | 高 |
| Kubernetes API認可 | Kubernetes RBACとMicrosoft Entra ID authorizationの役割分担が明確か | 高 |
| Azure RBACスコープ | リソースグループやサブスクリプション単位の広すぎる付与がないか | 高 |
| Cluster identity | ロードバランサー、ディスク、ACRなどに必要最小限の権限だけがあるか | 中 |
| Workload ID | PodがKey VaultやStorageへシークレットレスで接続できているか | 中 |
| CRDアクセス | ABAC条件やKubernetes RBACでCRD権限を絞れているか | 中 |
| 監査ログ | Azure Activity Log、Kubernetes監査ログ、Entra IDサインインログを追えるか | 中 |
| 移行対象 | pod-managed identityや過剰なKubernetes Secret利用が残っていないか | 中 |
このチェックリストは、セキュリティ担当だけのものではありません。プロダクトオーナーにとっても、誰が本番環境へアクセスできるか、障害時に誰が復旧操作できるか、監査で説明できるかを把握するための基礎になります。
次に取るべき行動
AKSのアクセスとID管理は、1つの設定で完結しません。2026年4月の公式ドキュメント更新は、AKSのID設計を「5つの問い」で分けて考えるべきだというメッセージとして受け取るのが実務的です。
まずは、自社のAKSについて次の3つを確認してください。
- 誰がAKSリソースからkubeconfigを取得できるか
- 誰がKubernetes APIで何を操作できるか
- クラスターとPodがAzureサービスへアクセスする際、どのIDを使っているか
この3点を棚卸しできれば、ローカルアカウントの残存、過剰なCluster Admin Role、広すぎるAzure RBACスコープ、アプリケーションシークレットの埋め込みといった典型的なリスクを見つけやすくなります。AKSを安全に運用する第一歩は、権限を増やすことではなく、どの境界で、誰に、何を許可しているかを説明できる状態にすることです。
コメント