AKS Kubernetes APIのMicrosoft Entra ID認可ガイダンス更新｜影響範囲と管理者対応

2026年7月7日前後に確認されたAzure Kubernetes Service（AKS）のMicrosoft Entra ID認可ガイダンス更新について、「すぐにパッチ適用が必要なのか」「既存クラスターの権限が変わるのか」と不安に感じる管理者もいるでしょう。

結論として、今回確認されたのはKubernetes APIの認可方法を整理した公式ドキュメントの更新です。公式ページとGitHub上の更新日は2026年7月6日で、主な変更はAKS Automaticへの適用明記と、AKS Standardとの設定差の整理です。少なくとも公開された情報には、脆弱性の告知、既存ロールの強制変更、利用者側の設定を自動変更する記載はありません。(Microsoft Learn)

ただし、文書更新を契機に確認すべき重要なポイントがあります。特に優先したいのは、上位スコープから継承された過剰なロール、ローカル管理者資格情報、RBAC Writer以上の権限、監査ログの未設定です。

AKSのMicrosoft Entra ID認可ガイダンスで何が更新されたのか

Microsoft Learnの「Kubernetes APIにMicrosoft Entra ID認可を使用する」ページは、AKS AutomaticとAKS Standardの両方を対象とする内容に整理されました。

GitHubの差分を見ると、2026年7月6日の更新ではAKS Automaticに関する説明が追加され、クラスターのモードごとにAzure RBAC for Kubernetes Authorizationの扱いが明確化されています。CRDをAzure ABAC条件で制限する説明は、それ以前の2026年4月時点ですでに追加されており、7月更新で突然導入された機能ではありません。(GitHub)

確認された内容	管理者への影響
AKS Automaticを適用対象として明記	Azure RBACによるKubernetes認可は事前構成済み
AKS Standardとの違いを整理	Standardでは`--enable-azure-rbac`による有効化が必要
組み込みリソースの認可方法を明記	AKS用のAzure組み込みロールをクラスターまたは名前空間に割り当てる
CRDの認可方法を明記	カスタムロールとAzure ABAC条件でAPIグループや種類を制限できる
前提条件を整理	Microsoft Entra統合、同一テナント、対応CLIなどを確認する
ロール反映時間を明記	新しい割り当ての反映には最大5分かかる場合がある

AKS AutomaticではAzure RBACによるKubernetes認可が既定で有効です。AKS Standardでは任意設定であり、クラスターごとに有効・無効が異なる可能性があります。(Microsoft Learn)

Microsoft Entra ID認可が保護する対象

AKSにおけるMicrosoft Entra ID認可は、認証済みのユーザーやアプリケーションが、Kubernetes APIに対して何を実行できるかを判定する仕組みです。

リクエストがKubernetes APIサーバーに届くと、AKSの認可WebhookがAzure上のロール割り当てとABAC条件を評価し、許可または拒否を返します。(Microsoft Learn)

保護対象になるもの

主な保護対象は次のとおりです。

Pod、Deployment、Service、ConfigMapなどの標準Kubernetesリソース
SecretやServiceAccountなどの機密性が高いリソース
Role、RoleBindingなどの権限管理リソース
Operatorや拡張機能が追加するカスタムリソース
クラスター全体または特定の名前空間に対する操作
Microsoft Entraのユーザー、グループ、サービスプリンシパルからのAPI操作

標準リソースは、AKS向けのAzure組み込みロールまたはカスタムロールで制御します。CRDについては、Azure ABAC条件を使ってAPIグループと種類を絞り込む方法が案内されています。(Microsoft Learn)

この認可だけでは保護できないもの

Microsoft Entra IDによるKubernetes API認可を有効にしても、AKSに関するすべてのアクセスが自動的に保護されるわけではありません。

対象	別途必要な管理
kubeconfigの取得	Azure Resource Manager側のAzure RBAC
`--admin`による管理者資格情報	ローカルアカウントの無効化
AKSリソース自体の作成・更新・削除	Azure管理プレーンのロール
PodからKey Vaultなどへのアクセス	Microsoft Entra Workload ID
Kubernetes APIエンドポイントへのネットワーク到達	API Server VNet統合、Private Cluster、許可IP範囲など
クラスター内ServiceAccountの権限	Kubernetes RBAC

特に注意したいのが、Kubernetes API用の「Azure Kubernetes Service RBAC Cluster Admin」と、kubeconfig取得用の「Azure Kubernetes Service Cluster Admin Role」は、名前が似ていますが別のロールである点です。

後者はlistClusterAdminCredential/actionを許可し、クラスター管理者用のkubeconfigを取得できるAzure管理プレーン側のロールです。(Microsoft Learn)

対応が必要かを判断する基準

今回の文書更新だけを理由に、すべてのAKSクラスターで緊急作業を行う必要はありません。次の表を使って対応要否を判断してください。

現在の状態	対応判断
AKSを利用していない	対応不要
AKS Automaticを利用している	有効化作業は不要。ロール割り当てと迂回経路を確認
AKS StandardでAzure RBACが有効	過剰な権限、継承ロール、監査設定を確認
AKS StandardでAzure RBACが無効	Microsoft Entra ID認可への移行要否を計画的に検討
サブスクリプションやリソースグループ単位でAKSロールを付与している	優先的な棚卸しが必要
RBAC Writer、Admin、Cluster Adminを広範囲に付与している	権限縮小を優先
ローカルアカウントが有効	本番環境では無効化を優先
CRDへのワイルドカード権限がある	CRD単位の制限方法を検討
AKS監査ログを保存していない	診断設定を優先的に追加

Microsoft Entra ID認可では、リソースグループ、サブスクリプション、管理グループなどの上位スコープにロールを付与できます。リソースグループに付与したロールは、そこに存在する現在および将来のAKSクラスターへ継承されるため、意図しない権限拡大に注意が必要です。(Microsoft Learn)

管理者が最初に確認すべき設定

Microsoft Entra統合とAzure RBACの状態を確認する

次のコマンドで、対象クラスターの主要な認証・認可設定を確認できます。

az aks show \
  --resource-group <resource-group> \
  --name <cluster-name> \
  --query "{managedEntra:aadProfile.managed,azureRbac:aadProfile.enableAzureRbac,tenantId:aadProfile.tenantId,disableLocalAccounts:disableLocalAccounts}" \
  --output yaml

確認するポイントは次のとおりです。

項目	確認内容
`managedEntra`	マネージドMicrosoft Entra統合が有効か
`azureRbac`	Azure RBACによるKubernetes認可が有効か
`tenantId`	AKSを含むサブスクリプションと同じテナントか
`disableLocalAccounts`	ローカルアカウントが無効化されているか

AKS AutomaticではAzure RBACが事前構成されるため、--enable-azure-rbacを実行する必要はありません。AKS Standardでは、既存クラスターに対して次のコマンドで有効化できます。(Microsoft Learn)

az aks update \
  --resource-group <resource-group> \
  --name <cluster-name> \
  --enable-azure-rbac

既存のKubernetes RBACやCI/CDのアクセス設計がある場合は、いきなり本番クラスターで変更せず、代表的なユーザー、サービスプリンシパル、ServiceAccountについて許可・拒否テストを実施してください。

クラスターと上位スコープのロールを棚卸しする

まずAKSリソースIDを取得します。

AKS_ID=$(az aks show \
  --resource-group <resource-group> \
  --name <cluster-name> \
  --query id \
  --output tsv)

続いて、クラスターに直接付与されたロールと、上位スコープから継承されたロールを一覧表示します。

az role assignment list \
  --scope "$AKS_ID" \
  --include-inherited \
  --all \
  --query "[].{Principal:principalName,Type:principalType,Role:roleDefinitionName,Scope:scope}" \
  --output table

最低限、次の点を確認します。

個人ユーザーへ恒久的に管理権限を与えていないか
退職者や異動者のアカウントが残っていないか
利用していないサービスプリンシパルが残っていないか
リソースグループやサブスクリプションから過剰な権限が継承されていないか
Cluster Adminが日常作業用アカウントに割り当てられていないか
Readerで足りる利用者にWriterを割り当てていないか

名前空間スコープの割り当ても確認する

ReaderやWriterは、特定の名前空間だけを対象として割り当てられます。

az role assignment list \
  --scope "$AKS_ID/namespaces/<namespace-name>" \
  --include-inherited \
  --all \
  --output table

Microsoftの公式情報では、名前空間スコープのロール割り当てはAzureポータル上で確認しにくい場合があるため、Azure CLIによる確認が案内されています。クラスター単位のIAM画面だけを確認して棚卸しを終えないようにしてください。(Microsoft Learn)

AKS組み込みロールの選び方

AKSの組み込みロールは、名前だけで判断すると過剰な権限を付与しやすいため、実際に操作できるリソースまで確認する必要があります。

ロール	主な権限	実務上の注意点
Azure Kubernetes Service RBAC Reader	多くのリソースを読み取り	Secret、Role、RoleBindingは参照できない
Azure Kubernetes Service RBAC Writer	多くのリソースを読み書き	Secret参照と任意のServiceAccountでのPod実行が可能
Azure Kubernetes Service RBAC Admin	名前空間内の管理	RoleとRoleBindingの作成が可能
Azure Kubernetes Service RBAC Cluster Admin	全リソースの全操作	緊急時や限定された管理者向け

特にWriterは、単なる「開発者向けの書き込み権限」と考えない方が安全です。

WriterはSecretを参照できるほか、名前空間内の任意のServiceAccountとしてPodを実行できます。そのため、強い権限を持つServiceAccountが存在すると、結果的にそのServiceAccountと同等のAPIアクセスを取得できる可能性があります。(Microsoft Learn)

Writerを割り当てる前に、次の項目を確認してください。

名前空間内のServiceAccountに付与されたRoleBinding
Secretに保存されている外部サービスの資格情報
特権コンテナーやhostPathを使用できるPod設定
他の名前空間やクラスター全体へアクセスできるServiceAccount
CI/CD用トークンや証明書の保存場所

代表ユーザーで実効権限をテストする

ロール割り当て後は、各利用者の実際の認証コンテキストで確認します。

kubectl auth can-i get pods -n <namespace>
kubectl auth can-i get secrets -n <namespace>
kubectl auth can-i create deployments -n <namespace>
kubectl auth can-i create rolebindings.rbac.authorization.k8s.io -n <namespace>

Azureロールの割り当ては、認可サーバーへ反映されるまで最大5分かかる場合があります。変更直後に拒否されても、設定ミスと即断せず、反映時間を考慮して再確認してください。(Microsoft Learn)

CRDへのアクセスはABAC条件で絞り込める

Operator、サービスメッシュ、ポリシー管理製品などを導入したAKSクラスターでは、多数のCRDが登録されます。

CRDを一括して読み取れる権限を付与すると、次のような情報まで閲覧される可能性があります。

Secret Store CSI Driverの設定
Istioの認可ポリシー
GatekeeperやKyvernoのポリシー
証明書管理の設定
外部サービス接続情報を含むOperatorのリソース

Azure ABAC条件では、次の属性を利用して、アクセス可能なCRDをAPIグループと種類で制限できます。

Microsoft.ContainerService/managedClusters/customResources:group
Microsoft.ContainerService/managedClusters/customResources:kind

例えば、secrets-store.csi.x-k8s.ioグループのsecretproviderclassesだけを許可し、security.istio.ioグループのリソースを拒否する、といった制御が可能です。(Microsoft Learn)

ただし、AKSのCRD向けABAC条件は公式ページでプレビューとして扱われています。プレビュー機能はSLAや保証の対象外となる場合があり、Microsoftは本番利用を目的としない旨を案内しています。まず検証環境で動作、制限事項、監査ログの出力を確認してください。(Microsoft Learn)

本番環境ですぐにCRD単位の制限が必要で、プレビュー機能を採用できない場合は、KubernetesのRoleとRoleBindingを使った制御も選択肢です。

ローカルアカウントと管理者kubeconfigを優先的に確認する

Microsoft Entra ID認可を整備しても、ローカル管理者資格情報が利用可能なままでは、認可設計を迂回される可能性があります。

AKSではローカルアカウントが既定で有効になり得ます。Microsoftは、Microsoft Entra統合やRBACを有効にしていても、--adminアクセスが監査しにくい迂回経路として残ると説明しています。(Microsoft Learn)

本番クラスターでは、業務上必要な例外を確認したうえで、ローカルアカウントの無効化を検討します。

az aks update \
  --resource-group <resource-group> \
  --name <cluster-name> \
  --disable-local-accounts

既存クラスターで過去にローカル管理者資格情報が取得されていた場合、無効化だけでは取得済み証明書が直ちに失効しない可能性があります。Microsoftの手順では、ローカルアカウントを無効化した後にクラスター証明書をローテーションする必要があるとされています。(Microsoft Learn)

併せて、次のAzure管理プレーン側ロールも確認してください。

Azure Kubernetes Service Cluster Admin Role
Azure Kubernetes Service Cluster User Role

Cluster Admin Roleは管理者用kubeconfigを取得できるため、Kubernetes API側のRBAC Cluster Adminと同様に、限定された管理者だけへ付与する必要があります。(Microsoft Learn)

監査と検知への影響

今回のガイダンス更新によって、監査ログが自動的に有効になるわけではありません。

確認すべきログは、大きく次の2種類です。

確認したい事象	使用するログ
Azureロール割り当ての追加・削除	Azure Activity Log
Kubernetes APIへの操作	AKSコントロールプレーン監査ログ
認可拒否、403エラー	AKSAudit
作成・変更・削除操作	AKSAuditAdmin
Microsoft Entraへのサインイン	Microsoft Entraサインインログ

Microsoft Entra ID認可のロール変更はAzure Activity Logに記録されます。一方、Kubernetes APIへの実際の操作を確認するには、AKSの診断設定で監査ログをLog Analyticsなどへ送信する必要があります。(Microsoft Learn)

AKSAuditとAKSAuditAdminの違い

リソース固有モードを利用すると、主に次のテーブルへログが保存されます。

AKSAudit：getやlistを含むKubernetes API監査ログ
AKSAuditAdmin：getやlistを除いた変更系の監査ログ
AKSControlPlane：APIサーバーなどのコントロールプレーンログ

Microsoftは、クエリしやすさとコスト最適化の観点から、リソース固有モードを推奨しています。(Microsoft Learn)

CRDのABAC条件で読み取りを制限する場合は、AKSAuditAdminだけでは不十分です。拒否されたgetやlistを検知したい場合は、これらの操作を含むAKSAuditが必要になります。

ただし、kube-auditはログ量と費用が大きくなりやすいため、保存期間、Basic Logs、アーカイブ、対象クラスターを設計したうえで有効化してください。(Microsoft Learn)

403 Forbiddenを検出するKQL例

次のクエリでは、Kubernetes APIで拒否された操作を抽出できます。

AKSAudit
| extend UserName = tostring(User.username),
         StatusCode = toint(ResponseStatus.code),
         Message = tostring(ResponseStatus.message)
| where StatusCode == 403
| project TimeGenerated,
          UserName,
          SourceIps,
          Verb,
          RequestUri,
          StatusCode,
          Message,
          UserAgent
| order by TimeGenerated desc

CRDだけに絞り込む場合は、RequestUriにAPIグループを追加します。

AKSAudit
| extend UserName = tostring(User.username),
         StatusCode = toint(ResponseStatus.code),
         Message = tostring(ResponseStatus.message)
| where StatusCode == 403
| where RequestUri has "/apis/"
| project TimeGenerated,
          UserName,
          SourceIps,
          Verb,
          RequestUri,
          Message
| order by TimeGenerated desc

AKSAuditには、認証済みユーザー、操作、対象オブジェクト、送信元IP、レスポンスコード、User-Agentなど、Kubernetes API操作の追跡に必要な情報が含まれます。(Microsoft Learn)

変更系操作を確認するKQL例

作成、更新、削除などの操作を中心に確認する場合は、AKSAuditAdminを利用します。

AKSAuditAdmin
| extend UserName = tostring(User.username),
         StatusCode = toint(ResponseStatus.code),
         Resource = tostring(ObjectRef.resource),
         Namespace = tostring(ObjectRef.namespace),
         ObjectName = tostring(ObjectRef.name)
| project TimeGenerated,
          UserName,
          SourceIps,
          Verb,
          Resource,
          Namespace,
          ObjectName,
          StatusCode,
          UserAgent
| order by TimeGenerated desc

Azureロール変更を確認するKQL例

Azure Activity LogをLog Analyticsへ送信している場合は、ロール割り当ての変更を検索できます。

AzureActivity
| where OperationNameValue has "MICROSOFT.AUTHORIZATION/ROLEASSIGNMENTS"
| project TimeGenerated,
          Caller,
          OperationNameValue,
          ActivityStatusValue,
          ResourceId,
          Properties
| order by TimeGenerated desc

特に、Cluster Admin、RBAC Cluster Admin、RBAC Writerの追加や、リソースグループ・サブスクリプション単位の割り当てをアラート対象にすると効果的です。

優先すべき対応

対応の優先順位は、クラスターの規模よりも「認可を迂回できるか」「上位権限へ昇格できるか」で判断します。

優先度	対応
最優先	ローカル管理者資格情報とCluster Admin Roleの利用者を確認する
最優先	RBAC Cluster Adminの上位スコープ割り当てを確認する
最優先	Writer利用者とServiceAccountの権限関係を確認する
高	リソースグループ、サブスクリプションからの継承ロールを棚卸しする
高	AKSAuditまたはAKSAuditAdminの診断設定を有効にする
高	名前空間スコープのロールをCLIで確認する
中	個人への直接割り当てをグループベースへ整理する
中	管理者権限へのPIMや多要素認証の適用を検討する
中	CRDのワイルドカード権限を棚卸しする
計画対応	AKS StandardでMicrosoft Entra ID認可への移行を検証する
検証対応	CRD向けABAC条件を非本番環境で評価する

Microsoft Entra ID認可では、既存の条件付きアクセスやPrivileged Identity ManagementをAKSへのアクセス管理に活用できます。恒久的な管理者権限を減らし、必要な時間だけ昇格する設計が有効です。(Microsoft Learn)

よくある設定ミス

認証を有効にすれば認可も完了したと思う

Microsoft Entra統合は、誰がアクセスしているかを確認する認証です。何を実行できるかを決める認可は、Azure RBACまたはKubernetes RBACで別途設定します。

クラスターのIAM画面だけで棚卸しを終える

リソースグループやサブスクリプションから継承されたロール、名前空間スコープのロールを見落とす可能性があります。

Writerを一般的な開発者ロールとして広く配布する

WriterはSecret参照とServiceAccountを利用したPod実行が可能です。名前空間内のServiceAccountが強い権限を持つ場合、実質的な権限昇格につながります。

Kubernetes APIのCluster Adminとkubeconfig取得ロールを混同する

「Azure Kubernetes Service RBAC Cluster Admin」と「Azure Kubernetes Service Cluster Admin Role」は別のロールです。両方を個別に棚卸ししてください。

ローカルアカウントを残したままMicrosoft Entra ID認可だけ整備する

--admin資格情報が使える状態では、Microsoft Entra IDの条件付きアクセスや通常の認可経路を迂回される可能性があります。

`kube-audit-admin`だけで拒否された読み取りを検知できると思う

kube-audit-adminはgetとlistを除外します。CRDの探索や読み取り拒否を検知するには、kube-auditとAKSAuditが必要です。

プレビューのABAC条件を検証せず本番導入する

CRD向けABAC条件はプレビューです。サポート条件や制限を確認し、非本番環境で許可・拒否の両方をテストしてください。

まず実施するべきこと

今回の更新は、緊急パッチではなくAKSのMicrosoft Entra ID認可を整理したガイダンス更新です。一方で、AKS AutomaticではAzure RBACが事前構成され、AKS Standardではクラスターごとに設定が異なることが明確になりました。

管理者は、まず次の順序で確認すると効率的です。

aadProfile.enableAzureRbacとローカルアカウントの状態を確認する
クラスター、名前空間、上位スコープのロールを一覧化する
Writer、Admin、Cluster Adminの利用者を絞り込む
管理者kubeconfigを取得できるAzureロールを確認する
AKSAuditまたはAKSAuditAdminを保存する
代表ユーザーで許可・拒否テストを行う
CRDに広い権限がある場合は、Kubernetes RBACまたはABAC条件による制限を検討する

最初に行うべき作業は、新機能の導入ではありません。現在の認可状態を可視化し、Microsoft Entra IDを迂回する経路と、継承された過剰権限を取り除くことです。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

AKS Kubernetes APIのMicrosoft Entra ID認可ガイダンス更新｜影響範囲と管理者対応

AKSのMicrosoft Entra ID認可ガイダンスで何が更新されたのか

Microsoft Entra ID認可が保護する対象

保護対象になるもの

この認可だけでは保護できないもの

対応が必要かを判断する基準

管理者が最初に確認すべき設定

Microsoft Entra統合とAzure RBACの状態を確認する

クラスターと上位スコープのロールを棚卸しする

名前空間スコープの割り当ても確認する

AKS組み込みロールの選び方

代表ユーザーで実効権限をテストする

CRDへのアクセスはABAC条件で絞り込める

ローカルアカウントと管理者kubeconfigを優先的に確認する

監査と検知への影響

AKSAuditとAKSAuditAdminの違い

403 Forbiddenを検出するKQL例

変更系操作を確認するKQL例

Azureロール変更を確認するKQL例

優先すべき対応

よくある設定ミス

認証を有効にすれば認可も完了したと思う

クラスターのIAM画面だけで棚卸しを終える

Writerを一般的な開発者ロールとして広く配布する

Kubernetes APIのCluster Adminとkubeconfig取得ロールを混同する

ローカルアカウントを残したままMicrosoft Entra ID認可だけ整備する

`kube-audit-admin`だけで拒否された読み取りを検知できると思う

プレビューのABAC条件を検証せず本番導入する

まず実施するべきこと

この記事を書いた人

コメント

コメントするコメントをキャンセル

AKS Kubernetes APIのMicrosoft Entra ID認可ガイダンス更新｜影響範囲と管理者対応

AKSのMicrosoft Entra ID認可ガイダンスで何が更新されたのか

Microsoft Entra ID認可が保護する対象

保護対象になるもの

この認可だけでは保護できないもの

対応が必要かを判断する基準

管理者が最初に確認すべき設定

Microsoft Entra統合とAzure RBACの状態を確認する

クラスターと上位スコープのロールを棚卸しする

名前空間スコープの割り当ても確認する

AKS組み込みロールの選び方

代表ユーザーで実効権限をテストする

CRDへのアクセスはABAC条件で絞り込める

ローカルアカウントと管理者kubeconfigを優先的に確認する

監査と検知への影響

AKSAuditとAKSAuditAdminの違い

403 Forbiddenを検出するKQL例

変更系操作を確認するKQL例

Azureロール変更を確認するKQL例

優先すべき対応

よくある設定ミス

認証を有効にすれば認可も完了したと思う

クラスターのIAM画面だけで棚卸しを終える

Writerを一般的な開発者ロールとして広く配布する

Kubernetes APIのCluster Adminとkubeconfig取得ロールを混同する

ローカルアカウントを残したままMicrosoft Entra ID認可だけ整備する

kube-audit-adminだけで拒否された読み取りを検知できると思う

プレビューのABAC条件を検証せず本番導入する

まず実施するべきこと

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

`kube-audit-admin`だけで拒否された読み取りを検知できると思う

コメントするコメントをキャンセル