Azure Policy for Kubernetesの2026年5月7日更新で、Azure Kubernetes Service（AKS）管理者がまず確認すべき点は、Azure Policy Add-on for AKSの新バージョン1.16.1、Validating Admission Policy（VAP）生成、Gatekeeper 3.22.1、そして複数CVEへのパッチ適用です。すぐに全クラスターへ強制適用するのではなく、現在のAKSバージョン、Azure Policyアドオンの有効化状況、denyポリシーの影響、namespace除外、既存リソースへの影響を順番に確認することが重要です。Microsoft公式ドキュメントは2026年5月7日に更新され、Azure Policy for KubernetesがGatekeeper v3とOPAを拡張して、Pod、コンテナー、namespaceなどのクラスター構成要素にポリシーを適用する仕組みであると説明しています。(Microsoft Learn)
この記事では、AKSでAzure Policy for Kubernetesを使っている管理者・開発者向けに、今回の更新で何が変わるのか、どの環境が影響を受けるのか、展開前に確認すべき設定、移行時の注意点、トラブルを避ける実務ポイントを整理します。
Azure Policy for Kubernetesとは何か
Azure Policy for Kubernetesは、Azure Policyを使ってKubernetesクラスター内のリソースを評価・制御する仕組みです。通常のAzure PolicyがAzureリソースを対象にするのに対し、Azure Policy for KubernetesではPod、コンテナー、namespaceなど、Kubernetes内の構成要素までポリシー評価の対象にできます。
仕組みとしては、Open Policy Agent（OPA）のAdmission ControllerであるGatekeeper v3を拡張し、Azure Policyの割り当て内容をKubernetesクラスターへ反映します。AKSでは「Azure Policy Add-on for AKS」、Azure Arc enabled Kubernetesでは「Azure Policy Extension for Arc」を通じて利用します。(Microsoft Learn)
管理者にとっての価値は、セキュリティや運用ルールを「人のレビュー」だけに頼らず、クラスター作成後の実際のワークロードに対して継続的に適用できる点です。
たとえば、次のようなルールを組織全体で統一できます。
| 利用シーン | 具体例 |
|---|---|
| セキュリティ統制 | 特権コンテナーを禁止する、許可されたイメージレジストリだけを使わせる |
| 運用標準化 | 必須ラベルの設定を求める、namespaceごとに例外を管理する |
| コンプライアンス確認 | 違反しているPodやnamespaceをAzure Policy側で可視化する |
| 開発チーム支援 | デプロイ時にルール違反を早期に検出する |
2026年5月7日更新で注目すべき変更点
今回の更新で最も注目すべきなのは、Azure Policy Add-on for AKSのバージョン1.16.1です。公式ドキュメントの変更履歴では、1.16.1について「Validating Admission Policy（VAP）生成の導入」「CVE-2026-25679、CVE-2026-27142、CVE-2026-27139、CVE-2026-32280へのパッチ」「セキュリティ改善」が記載されています。対象はKubernetes 1.36以降で、Gatekeeperは3.22.1です。(Microsoft Learn)
変更点の整理
| 項目 | 内容 | 実務上の確認ポイント |
|---|---|---|
| Azure Policy Add-on for AKS 1.16.1 | 2026年5月リリースの新しいアドオンバージョン | 対象クラスターで実際にどのバージョンが使われているか確認する |
| VAP生成 | CELを含むAzure PolicyからKubernetesネイティブのValidating Admission Policyを生成 | 既存のRegoベース運用との違い、Admission時の挙動を検証する |
| Gatekeeper 3.22.1 | アドオンが利用するGatekeeperの更新 | Gatekeeperの既存制約やログ監視手順を再確認する |
| CVEパッチ | 複数のCVEに対する修正 | セキュリティ要件が厳しい環境では早期適用を検討する |
| Kubernetes 1.36+ | 1.16.1の対象として記載 | AKSクラスターのKubernetesバージョンとアップグレード計画を確認する |
VAPはKubernetes v1.30でstableとなっている、CELを使ったKubernetesネイティブのAdmission制御です。Kubernetes公式ドキュメントでは、Validating Admission PolicyはWebhookに代わる宣言的でインプロセスな検証手段として説明されています。(Kubernetes)
つまり今回の更新は、単なるアドオンの小さな修正ではありません。AKS上のポリシー適用方式が、従来のGatekeeper中心の評価に加えて、KubernetesネイティブなAdmission制御へ寄っていく流れとして捉えるべきです。
影響を受ける対象者
今回のAzure Policy for Kubernetes更新は、次のような利用者に影響します。
| 対象者 | 影響 |
|---|---|
| AKS管理者 | アドオンバージョン、Kubernetesバージョン、ポリシー割り当て、namespace除外の確認が必要 |
| セキュリティ担当者 | denyポリシーやDefender for Cloud連携による自動適用範囲の把握が必要 |
| 開発者 | デプロイ時にPod作成が拒否される可能性があるため、エラー確認手順を理解する必要がある |
| SRE・運用担当者 | azure-policy pod、gatekeeper podのログ監視と障害切り分け手順を整備する必要がある |
| プラットフォームチーム | 本番導入前にAudit、Disabled、Denyの段階的な展開設計が必要 |
特に注意したいのは、Azure Policyのdenyポリシーは「既存リソースを即座に停止する」ものではない点です。公式ドキュメントでは、既存の非準拠リソースは稼働を続けますが、別ノードへ再スケジュールされるとGatekeeperにより作成がブロックされる可能性があると説明されています。(Microsoft Learn)
本番環境では、いきなりdenyを有効化すると、障害時の再作成、ノードメンテナンス、スケールアウト、ローリングアップデートのタイミングで想定外の停止につながる可能性があります。
AKS環境で最初に確認すべき設定
Azure Policy for KubernetesをAKSで利用する場合、まずは「アドオンが有効か」「対象バージョンか」「通信要件を満たしているか」を確認します。
Azure Policy Add-onが有効か確認する
AKSでは、Azure Policy Add-on for AKSを有効化することでAzure Policy for Kubernetesを利用します。公式ドキュメントでは、Azure CLIで次のように有効化する手順が示されています。(Microsoft Learn)
az aks enable-addons \
--addons azure-policy \
--name <AKSクラスター名> \
--resource-group <リソースグループ名>有効化後は、Azure PolicyとGatekeeperのPodが動作しているかを確認します。
kubectl get pods -n kube-system
kubectl get pods -n gatekeeper-systemkube-systemにはazure-policy pod、gatekeeper-systemにはgatekeeper podが配置されます。どちらかがPending、CrashLoopBackOff、ImagePullBackOffになっている場合は、ポリシー同期やAdmission制御が期待通りに動作しない可能性があります。
アドオンとGatekeeperのバージョンを確認する
今回の更新で重要なのは、実際にクラスターへ入っているAzure Policy Add-onとGatekeeperのバージョンです。公式ドキュメントでは、アドオンのコンテナーイメージとGatekeeperのイメージを確認するコマンドが案内されています。(Microsoft Learn)
kubectl get pod azure-policy-<unique-pod-identifier> \
-n kube-system \
-o json | jq '.spec.containers[0].image'kubectl get pod gatekeeper-controller-<unique-pod-identifier> \
-n gatekeeper-system \
-o json | jq '.spec.containers[0].image'実務では、次のように確認結果を台帳化しておくと、監査や障害対応で役立ちます。
| 確認項目 | 記録例 |
|---|---|
| AKSクラスター名 | aks-prod-japaneast-01 |
| Kubernetesバージョン | 1.36.x |
| Azure Policy Add-onバージョン | 1.16.1 |
| Gatekeeperバージョン | 3.22.1 |
| 主要ポリシー効果 | audit / deny / mutate |
| 最終確認日 | 2026-05-13 |
Kubernetesバージョンの確認とアップグレード判断
Azure Policy Add-on 1.16.1は、公式ドキュメント上でKubernetes 1.36以降が対象として記載されています。AKSのKubernetesサポート状況もあわせて確認する必要があります。MicrosoftのAKSサポートページでは、AKSのGA Kubernetesバージョンは原則12か月のサポートポリシーに従うと説明されています。(Microsoft Learn)
2026年5月時点の公式表では、AKS 1.36は2026年5月にプレビュー、2026年6月にGA予定として掲載されています。(Microsoft Learn)
そのため、本番環境での判断は次のように分けると安全です。
| 現在のAKSバージョン | 判断 |
|---|---|
| 1.36以降 | Azure Policy Add-on 1.16.1の適用状況とVAP生成の影響を検証する |
| 1.35以前 | まずAKSのアップグレード計画を確認し、アドオン単体で判断しない |
| サポート終了が近いバージョン | Azure Policyだけでなく、AKS基盤全体の更新計画を優先する |
| LTS利用中 | LTS対象バージョンとAzure Linux、ノードプール更新も含めて確認する |
Azure Policy for Kubernetesの更新だけを見て判断すると、Kubernetes本体、ノードOS、他のAKSマネージドアドオンとの整合性を見落としやすくなります。特に本番クラスターでは、Azure Policy Add-on、Gatekeeper、Kubernetes API、既存のAdmission Webhookをまとめて検証してください。
denyポリシーは本番適用前に必ず段階導入する
Azure Policy for Kubernetesで最も失敗しやすいのは、auditで十分に確認しないままdenyを有効化するケースです。
Azure Policyの割り当てでは、ポリシー適用を有効にすると、違反したKubernetes Admission requestが拒否されます。一方、無効にした場合は違反リクエストを拒否せず、コンプライアンス評価結果だけを確認できます。公式ドキュメントでも、新しいポリシー定義を稼働中クラスターへ展開する際は、違反リクエストを拒否しないDisabled設定がテストに役立つと説明されています。(Microsoft Learn)
推奨する展開手順
| 段階 | 設定 | 目的 |
|---|---|---|
| 検証 | Disabledまたはaudit相当 | どのnamespace、Pod、Deploymentが違反するか把握する |
| 限定適用 | 一部namespaceや開発環境でdeny | CI/CDやkubectl apply時の影響を確認する |
| 本番準備 | 例外ルールと運用手順を整備 | 緊急時に何を見て、誰が判断するか決める |
| 本番適用 | denyを段階的に有効化 | 影響を監視しながら適用範囲を広げる |
本番適用前には、少なくとも次の確認を済ませてください。
- 違反している既存リソースの一覧を確認する
- Deployment、ReplicaSet、Podのどの段階で拒否されるかを検証する
- CI/CDパイプラインで失敗時のメッセージを取得できるようにする
- 緊急時に一時的に適用除外できる運用ルールを決める
- 監査ログとKubernetesイベントの確認手順を共有する
開発者にとっては、「なぜデプロイできないのか」が分からない状態が最もつらいポイントです。denyを使う場合は、ポリシー名、違反理由、修正例をチーム内ドキュメントにまとめておくと、問い合わせ対応を大幅に減らせます。
namespace除外は最小限にする
Azure Policy for Kubernetesでは、namespaceをポリシー評価から除外できます。公式ドキュメントでは、namespace除外の推奨例としてkube-system、gatekeeper-system、azure-arcが示されています。(Microsoft Learn)
ただし、除外を広げすぎると、ポリシーによる統制が形だけになります。特にdefaultやアプリケーション用namespaceを安易に除外すると、実際のワークロードに対してAzure Policyが効かなくなります。
namespace除外の判断基準
| namespace | 除外判断 |
|---|---|
| kube-system | 原則除外を検討。AKSのシステムPodに影響を与えないため |
| gatekeeper-system | 原則除外を検討。Gatekeeper自体の動作を妨げないため |
| azure-arc | Arc利用時は除外を検討 |
| default | 原則除外しない。アプリ配置先として使われる可能性がある |
| app-prod | 除外ではなく、ポリシーを満たすように修正する |
| app-dev | 初期検証では緩めてもよいが、恒久除外は避ける |
独自のnamespace除外を設定する場合は、理由、期限、承認者を残すことをおすすめします。「とりあえず除外」が積み重なると、後からどのnamespaceが統制対象なのか分からなくなります。
Gatekeeperを手動インストールしている環境は注意
公式ドキュメントでは、Azure Policy Add-on外でインストールされたGatekeeperはサポートされないと明記されています。過去にGatekeeperを手動で導入していた場合は、Azure Policy Add-onを有効化する前に、以前のGatekeeperコンポーネントをアンインストールする必要があります。(Microsoft Learn)
また、Azure Policy Add-onがインストールしたconstraint templateやconstraintを管理者が手動で変更しても、その変更は上書きされる可能性があります。公式ドキュメントでも、手動更新はサポートされるシナリオではなく、上書きされると説明されています。(Microsoft Learn)
実務では、次のような状態が危険です。
| 危険な状態 | 起こり得る問題 |
|---|---|
| 手動GatekeeperとAzure Policy Add-onが混在 | constraintの競合、想定外のAdmission拒否 |
| Azure Policy管理下のconstraintをkubectlで直接編集 | 次回同期時に上書きされ、変更が消える |
| 既存Regoルールを棚卸しせず移行 | 似たルールが重複し、開発者が原因を追えなくなる |
| GitOps管理とAzure Policy管理の境界が不明確 | どちらが正なのか分からず運用事故につながる |
移行時は「Gatekeeperで直接管理するルール」と「Azure Policy経由で管理するルール」を分けるのではなく、原則としてAzure Policyに寄せる方が管理しやすくなります。どうしても独自Gatekeeper運用を残す場合は、サポート範囲と責任分界を明確にしてください。
ポリシー評価のタイミングを理解する
Azure Policy Add-onは、Azure Policyサービスに対してポリシー割り当ての変更を定期的に確認します。公式ドキュメントでは、アドオンは15分ごとに変更を確認し、その変更によりconstraint templateやconstraintの作成、更新、削除が行われると説明されています。また、15分ごとにクラスターのフルスキャンも実行され、Gatekeeperによるリアルタイム評価の結果と合わせてAzure Policyへ報告されます。(Microsoft Learn)
この仕組みを理解していないと、次のような誤解が生まれます。
| 誤解 | 実際の考え方 |
|---|---|
| ポリシーを割り当てたら即時に全結果が見える | 同期やスキャンに時間差がある |
| 既存リソースはdenyで即削除される | 既存リソースは稼働を続ける場合がある |
| Deploymentのdescribeだけ見れば拒否理由が分かる | ReplicaSet側のイベント確認が必要な場合がある |
| Azure Portalの結果だけで原因特定できる | kubectl logsやKubernetesイベントも確認する |
特に開発者から「Deploymentが作れない」と相談された場合、DeploymentだけでなくReplicaSetやPodイベントも確認してください。公式ドキュメントでは、Deploymentのdescribeでは拒否メッセージが出ず、ReplicaSetのdescribeで拒否イベントが確認できる例が示されています。(Microsoft Learn)
通信要件とネットワーク制限を確認する
AKSクラスターのアウトバウンド通信を厳しく制限している場合、Azure Policy Add-onがAzure Policyサービスと通信できず、ポリシー取得やコンプライアンス報告に失敗することがあります。
公式ドキュメントでは、Azure Policy extensionがポリシー定義や割り当てを取得し、コンプライアンスを報告するために、次のドメインと443番ポートを使用すると説明されています。(Microsoft Learn)
| ドメイン | ポート |
|---|---|
| data.policy.core.windows.net | 443 |
| store.policy.core.windows.net | 443 |
| login.windows.net | 443 |
| dc.services.visualstudio.com | 443 |
企業ネットワークや閉域構成のAKSでは、Azure Policy Add-onを有効にしただけでは動かない場合があります。ネットワークチームへ依頼する際は、「Azure Policy Add-onが外部通信に使う宛先」として上記を明示し、プロキシ、Firewall、Private Link構成の有無を確認してください。
Microsoft Defender for Cloud連携にも注意する
AKSのサブスクリプションがMicrosoft Defender for Cloudに登録されている場合、Defender for CloudのKubernetesポリシーがクラスターへ自動適用される可能性があります。公式ドキュメントでも、クラスターのサブスクリプションがMicrosoft Defender for Cloudに登録されている場合、Defender for CloudのKubernetesポリシーが自動的に適用されると説明されています。(Microsoft Learn)
これは便利な一方で、「自分で割り当てた覚えのないポリシーで警告が出る」「突然コンプライアンス結果が増えた」と見えることがあります。
確認すべきポイントは次の3つです。
| 確認項目 | 理由 |
|---|---|
| Defender for Cloudのプラン状態 | 自動適用されるポリシーの有無を判断するため |
| Azure Policyの割り当て一覧 | 手動割り当てと自動割り当てを区別するため |
| denyかauditか | 実際にデプロイを止める可能性があるか判断するため |
セキュリティ担当者とAKS管理者が別チームの場合、ここは特に認識ズレが起きやすい箇所です。Azure Policyの割り当て変更時は、AKS運用チームだけでなくDefender for Cloudを管理するチームにも共有してください。
トラブルシューティングで見るべきログ
Azure Policy for Kubernetesで問題が起きた場合は、azure-policy podとgatekeeper podのログを分けて確認します。公式ドキュメントでは、azure-policyログはポリシー取り込みやコンプライアンス報告の問題、gatekeeper-controller-managerログはruntime deny、gatekeeper-auditログは既存リソースの監査確認に使えると説明されています。(Microsoft Learn)
基本コマンドは次のとおりです。
kubectl logs <azure-policy pod名> -n kube-systemkubectl logs <gatekeeper pod名> -n gatekeeper-system障害対応時は、次の順番で見ると原因を絞り込みやすくなります。
| 症状 | 最初に見る場所 |
|---|---|
| Azure Policyの割り当てがクラスターに反映されない | azure-policy podログ |
| Pod作成が拒否される | gatekeeper-controller-managerログ、ReplicaSetイベント |
| 既存リソースの違反が表示されない | gatekeeper-auditログ、Azure Policyのコンプライアンス結果 |
| ポリシー定義が競合している | constraint template、Azure PolicyのComplianceReasonCode |
| アドオンPodが起動しない | kube-system、gatekeeper-systemのPod状態 |
開発者からの問い合わせ対応では、「kubectl applyが失敗した画面」だけでは情報が足りません。namespace、対象Deployment、ReplicaSetイベント、該当ポリシー名、Azure Policy側のコンプライアンス理由をセットで確認する運用にすると、切り分けが速くなります。
安全に展開するためのチェックリスト
Azure Policy for KubernetesをAKSへ展開・更新する前に、次の項目を確認してください。
| チェック項目 | 確認内容 |
|---|---|
| AKSバージョン | 対象クラスターがサポートされるKubernetesバージョンか |
| アドオン状態 | Azure Policy Add-onが有効で、Podが正常稼働しているか |
| アドオンバージョン | 1.16.1など、想定するバージョンになっているか |
| Gatekeeperバージョン | 3.22.1など、公式情報と整合しているか |
| 既存Gatekeeper | 手動インストールされたGatekeeperが残っていないか |
| namespace除外 | kube-systemなど必要最小限に絞られているか |
| deny適用範囲 | 本番適用前にauditまたはDisabledで確認したか |
| Defender連携 | 自動適用されるKubernetesポリシーを把握しているか |
| 通信要件 | 必要なドメインへの443通信が許可されているか |
| 開発者向け案内 | 拒否理由の確認方法と修正例を共有しているか |
このチェックリストを、AKSアップグレード手順書やリリース判定表に組み込むと、Azure Policy更新を単発対応で終わらせず、継続的なガバナンス運用にできます。
まとめ：まずは現在のAKSとポリシー適用状況を棚卸しする
2026年5月7日に更新されたAzure Policy for Kubernetesの公式情報では、AKS向けAzure Policy Add-on 1.16.1、VAP生成、Gatekeeper 3.22.1、CVEパッチ、セキュリティ改善が重要なポイントです。特にVAP生成は、KubernetesネイティブなAdmission制御を取り込む流れとして注目すべき変更です。
ただし、実務で最初にやるべきことは、いきなり新機能を使うことではありません。まずは、対象AKSクラスターのKubernetesバージョン、Azure Policy Add-onの有効化状態、Gatekeeperのバージョン、denyポリシーの有無、namespace除外、Defender for Cloud連携を棚卸ししてください。
そのうえで、開発環境または限定namespaceで検証し、auditやDisabledで影響を見てから、本番のdeny適用範囲を広げるのが安全です。Azure Policy for Kubernetesは、正しく使えばAKSのセキュリティと運用標準化を強力に支援します。一方で、適用範囲や例外管理を誤ると、デプロイ停止や原因不明のAdmission拒否につながります。
次に取るべき行動は明確です。まず、主要AKSクラスターで次の3つを確認してください。
az aks show \
--resource-group <リソースグループ名> \
--name <AKSクラスター名> \
--query addonProfiles.azurepolicykubectl get pods -n kube-system
kubectl get pods -n gatekeeper-systemkubectl get constrainttemplatesこの結果をもとに、Azure Policy for Kubernetesの更新を「セキュリティ改善」と「運用影響」の両面から評価し、段階的に展開していきましょう。
コメント