Azure Kubernetes Service（AKS）のクラスターセキュリティを確認するなら、まず見るべきポイントは「AKS Automatic と AKS Standard で、誰がどこまで責任を持つか」です。2026年6月5日に更新された Microsoft Learn の公式情報では、AKS のセキュリティベストプラクティスが AKS Automatic と AKS Standard の両方を対象に整理され、認証・認可、API サーバー保護、Instance Metadata API へのアクセス制限、コンテナー権限、Kubernetes アップグレード、ノード更新の確認ポイントが明確になりました。(Microsoft Learn)
結論から言えば、今回の更新は「今すぐ全クラスターに破壊的変更が入る」という内容ではなく、運用責任の見直しを促すセキュリティガイダンスの更新です。特に AKS Standard を運用している管理者は、これまで明示的に設定してきたセキュリティ項目が維持されているかを棚卸しする必要があります。AKS Automatic を利用する場合も、事前構成されたベースラインに任せきりにせず、脅威検出、例外管理、ワークロード側の権限制御、アップグレード前検証は運用チームの責任として確認すべきです。
Azure Kubernetes Service のセキュリティ更新で何が変わったのか
今回の公式ドキュメント更新で最も重要なのは、AKS のクラスターセキュリティベストプラクティスが AKS Automatic と AKS Standard の両方に適用される形で整理された点です。Microsoft Learn の該当ページでは、対象として AKS Automatic と AKS Standard が明記され、クラスター認証・認可、API サーバーのネットワーク強化、ポリシー、イメージ管理、システムノードプール、アップグレード責任の違いが比較されています。(Microsoft Learn)
GitHub 上の公式ドキュメント履歴では、2026年6月4日のコミットで「Adding AKS Automatic」として差分が記録され、1ファイルに対して 59行追加、51行削除の変更が行われています。ページ上の最終更新日は 2026年6月5日と表示されています。(GitHub)
実務上は、次のように捉えると分かりやすいです。
| 確認項目 | 今回の見直しポイント | 管理者・開発者への影響 |
|---|---|---|
| クラスターモード | AKS Automatic と AKS Standard の責任分界が追加 | 自社の運用モデルに応じて、誰が設定・監査するかを再確認する |
| 認証・認可 | Microsoft Entra ID と Kubernetes RBAC の利用を重視 | 個人単位ではなく、グループやロール単位で権限を管理する |
| API サーバー保護 | 最小権限と監査性を重視 | 管理者権限の過剰付与、広すぎる namespace 権限を見直す |
| Instance Metadata API | Pod からのメタデータエンドポイント到達を制限 | NetworkPolicy の適用状況を確認する |
| コンテナー権限 | root 実行、特権昇格、不要な権限を避ける | Pod Security、AppArmor、seccomp、user namespaces を確認する |
| アップグレード | Kubernetes とノード OS の更新を継続的に行う | 本番前検証、PDB、メンテナンス時間、ノードプール単位の展開計画が必要 |
影響範囲は AKS Automatic と AKS Standard の両方
今回のガイダンスは AKS Automatic と AKS Standard の両方に関係します。ただし、影響の出方は同じではありません。
AKS Automatic は、サポートされる構成において、セキュリティやノード管理、スケーリングなどの一般的な設定を Azure 側がより多く事前構成するモードです。公式説明でも、AKS Automatic はクラスター設定、ノード管理、スケーリング、セキュリティ、AKS Well-Architected に沿った事前構成を Azure が扱うと説明されています。(Microsoft Learn)
一方、AKS Standard は構成の自由度が高い分、オペレーター側が明示的に設定・維持する範囲が広くなります。公式ドキュメントでも、AKS Automatic はより多くの事前構成された制御を含み、AKS Standard は直接構成できる範囲が広い代わりに、ベースライン設定と継続運用の責任が増えると整理されています。(Microsoft Learn)
AKS Automatic 利用者が誤解しやすい点
AKS Automatic は「セキュリティ運用が不要になるモード」ではありません。事前構成されたセキュリティベースラインがあっても、次の作業は利用者側に残ります。
- Defender for Containers の有効化とアラート対応
- アプリケーションごとの権限設計
- namespace 単位の例外管理
- デプロイ前の動作検証
- アップグレードによるアプリケーション影響の確認
- セキュリティポリシー違反時の調査と改善
特に本番環境では、「Automatic だから安全」と判断するのではなく、「Automatic が担う範囲」と「自社チームが担う範囲」を運用手順書に分けて書くことが重要です。
AKS Standard 利用者が確認すべき点
AKS Standard では、次の設定が暗黙的に安全になっているとは考えない方がよいです。
- Microsoft Entra ID 統合が有効か
- Kubernetes RBAC が適切に設計されているか
- API サーバーへのアクセス元が制限されているか
- NetworkPolicy が利用可能な構成になっているか
- Pod が root や privileged で動いていないか
- ノードイメージ更新と Kubernetes バージョン更新の計画があるか
- 本番アップグレード前に検証環境でテストしているか
特に複数チームで namespace を共有している場合、権限の棚卸しは優先度が高い作業です。過去に一時的に付与した cluster-admin 権限や、退職・異動後も残っているグループ権限が、攻撃経路になることがあります。
まず確認すべきセキュリティ設定
AKS のセキュリティ確認は、範囲を広げすぎると手が止まりがちです。最初は、公式ガイダンスで重視されている項目に沿って、API サーバー、ID、Pod の外向き通信、コンテナー権限、ノード更新の順に確認すると進めやすくなります。
Microsoft Entra ID と Kubernetes RBAC で API サーバーを守る
AKS クラスターで最も重要な防御ポイントの一つが Kubernetes API サーバーです。公式ガイダンスでは、API サーバーへのアクセスを保護するため、Microsoft Entra ID と Kubernetes RBAC を統合し、Azure サブスクリプションと同じようにアクセス制御することが推奨されています。(Microsoft Learn)
実務では、次のような設計が基本です。
| 悪い例 | 改善例 |
|---|---|
| 個人ユーザーに直接 cluster-admin を付与する | Microsoft Entra ID グループにロールを割り当てる |
| すべての開発者に全 namespace の編集権限を付与する | チーム別 namespace に RoleBinding を設定する |
| 障害対応用の強権限を常時付与する | 緊急時用グループを分け、利用履歴を監査する |
| 権限付与の理由が記録されていない | 申請・承認・期限・棚卸し日を残す |
たとえば、開発チーム A が team-a namespace だけを操作すればよい場合、クラスター全体の ClusterRoleBinding ではなく、namespace スコープの RoleBinding を使います。これにより、誤操作や侵害時の影響範囲を小さくできます。
Instance Metadata API への Pod からのアクセスを制限する
公式ガイダンスでは、すべてのユーザー namespace で NetworkPolicy を追加し、Pod からメタデータエンドポイントへの egress をブロックすることが推奨されています。AKS で NetworkPolicy を使うには、クラスター作成時に --network-policy azure などの指定が必要になる場合があります。(Microsoft Learn)
Instance Metadata API は、Azure リソースのメタデータや ID に関係する情報へ到達する経路になり得ます。アプリケーションの脆弱性を突かれて Pod 内から外向き通信を実行された場合、メタデータエンドポイントに到達できる構成はリスクになります。
確認すべき観点は次の通りです。
| 確認項目 | 判断基準 |
|---|---|
| NetworkPolicy が使える構成か | 使用中のネットワークプラグインとポリシーエンジンで egress 制御できるか |
| user namespace で既定拒否に近い設計か | 必要な宛先だけ許可しているか |
169.254.169.254 への到達を制御しているか | Pod からメタデータエンドポイントへ不要にアクセスできないか |
| 例外 namespace があるか | 例外理由、期限、所有者が記録されているか |
失敗しやすいのは、「NetworkPolicy の YAML は用意したが、クラスター側で NetworkPolicy が有効になっていない」ケースです。既存クラスターでは、ポリシー適用前にネットワーク構成を必ず確認してください。
コンテナーの root 実行と特権昇格を避ける
公式ガイダンスでは、コンテナーが実行できる操作を最小限にし、root アクセスや特権昇格を避けることが推奨されています。また、user namespaces によるホスト分離の改善、AppArmor や seccomp などの Linux セキュリティ機能の活用にも触れられています。(Microsoft Learn)
開発者が確認すべき代表的な項目は、次の通りです。
securityContext:
runAsNonRoot: true
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities:
drop:
- ALLただし、すべてのアプリケーションに同じ設定を機械的に入れればよいわけではありません。たとえば、一時ファイルを書き込むアプリケーションで readOnlyRootFilesystem: true を指定すると、起動に失敗することがあります。その場合は、書き込みが必要なパスだけ emptyDir などに逃がし、コンテナーイメージ全体を書き込み可能にしない設計にします。
脅威検出は Defender for Containers の有効化だけで終わらせない
Microsoft のガイダンスでは、Defender for Containers を有効化することで、クラスター構成の評価、セキュリティ推奨事項、脆弱性スキャン、Kubernetes ノードとクラスターへのリアルタイム保護とアラートを利用できると説明されています。(Microsoft Learn)
ただし、実務で重要なのは「有効化した後」です。アラートが出ても、誰が、どの優先度で、どこまで対応するかが決まっていなければ、セキュリティ効果は限定的です。
最低限、次の運用ルールを決めておきましょう。
| 運用項目 | 決める内容 |
|---|---|
| アラート確認 | 毎営業日確認するのか、重大度 High 以上を即時通知するのか |
| 対応責任 | インフラチーム、SRE、開発チームのどこが一次対応するのか |
| 例外管理 | 修正できない脆弱性をいつまで許容するのか |
| 再発防止 | Dockerfile、Helm chart、CI/CD のどこを直すのか |
| 監査証跡 | チケット、Pull Request、変更履歴をどう残すのか |
特にコンテナー脆弱性は、ベースイメージの更新だけで解消する場合もあれば、アプリケーション依存パッケージの更新が必要な場合もあります。アラートを「インフラの問題」として放置せず、開発チームの修正フローに接続することが大切です。
Kubernetes とノードのアップグレードで確認すべきこと
AKS のセキュリティでは、アクセス制御だけでなく、Kubernetes とノード OS を更新し続ける運用が欠かせません。公式ガイダンスでは、AKS クラスターを最新の Kubernetes バージョンへ定期的にアップグレードし、ノードも更新することが推奨されています。(Microsoft Learn)
AKS は GA の Kubernetes マイナーバージョンについて、最新バージョン N と、その前の N-1、N-2 の合計3つをサポートする方針です。新しいマイナーバージョンが導入されると、古いマイナーバージョンは一定期間後にサポート対象外になります。(Microsoft Learn)
利用可能なアップグレードを確認する
Azure CLI を使う場合、まず現在のクラスターで利用可能なアップグレード先を確認します。
az aks get-upgrades \
--resource-group myResourceGroup \
--name myAKSCluster \
--output tableアップグレード自体は、公式ガイダンスで示されている通り az aks upgrade を使います。AKS のアップグレード処理では、ノードを1台ずつ cordon/drain し、残りのノードへ Pod をスケジュールし、新しい OS と Kubernetes バージョンのノードを展開する流れになります。(Microsoft Learn)
az aks upgrade \
--resource-group myResourceGroup \
--name myAKSCluster \
--kubernetes-version <KUBERNETES_VERSION>本番環境では、いきなりこのコマンドを実行するのではなく、次の順序で進めるのが安全です。
| 手順 | 実施内容 | 失敗しやすいポイント |
|---|---|---|
| 事前確認 | サポート対象バージョン、非推奨 API、リリースノートを確認 | Kubernetes API の廃止を見落とす |
| 検証環境 | 同じ Helm chart、Manifest、Ingress、CSI でテスト | 本番だけにある設定差分を見落とす |
| PDB 確認 | Pod Disruption Budget が適切か確認 | maxUnavailable=0 などで drain が進まない |
| 容量確認 | surge ノード用のクォータ、IP、SKU 在庫を確認 | 追加ノードを作れずアップグレード失敗 |
| 段階展開 | ノードプール単位、クラスター単位で順次更新 | 全環境を同時に上げて障害範囲が広がる |
| 監視 | エラー率、レイテンシ、Pod 再起動、HPA 動作を確認 | アップグレード完了だけを見て正常判断する |
AKS のアップグレード推奨事項では、計画メンテナンス時間、max surge、PDB、node drain timeout、node soak time を組み合わせ、停止影響を抑えることが推奨されています。production では max surge 33% が推奨値として挙げられていますが、クォータやリージョン容量に制約がある場合は調整が必要です。(Microsoft Learn)
マイナーバージョンのスキップに注意する
Kubernetes のマイナーバージョンアップでは、複数バージョンをまとめて飛ばせないケースがあります。AKS の公式情報では、サポート対象クラスターのアップグレードで Kubernetes マイナーバージョンはスキップできないと説明されています。たとえば 1.27.x から 1.29.x へ直接上げるのではなく、1.28.x を経由する必要があります。(Microsoft Learn)
アップグレードを長期間放置すると、検証回数も作業リスクも増えます。月次または四半期ごとに「現在の Kubernetes バージョン」「サポート期限」「次の検証予定」を確認する運用にしておくと、緊急対応になりにくくなります。
ノードイメージと OS 更新の確認ポイント
AKS では Linux ノードに対し、ディストリビューションの更新チャネルを通じて毎晩セキュリティパッチが適用される一方、セキュリティパッチやカーネル更新で再起動が必要な場合でも、ワークロード影響を抑えるためノードは自動再起動されません。(Microsoft Learn)
また、ノード OS にパッチが入っても、クラスター内で新規ノードを作成する際に使われるノードイメージ自体は別途更新が必要です。公式情報では、Linux ノードイメージは週次、Windows ノードイメージは月次で更新されると説明されており、ノードイメージのアップグレードを定期的に行うことが推奨されています。(Microsoft Learn)
確認コマンドの例は次の通りです。
az aks nodepool get-upgrades \
--resource-group $AKS_RESOURCE_GROUP \
--cluster-name $AKS_CLUSTER \
--nodepool-name $AKS_NODEPOOL現在のノードイメージバージョンを確認するには、次のようにします。
az aks nodepool show \
--resource-group $AKS_RESOURCE_GROUP \
--cluster-name $AKS_CLUSTER \
--name $AKS_NODEPOOL \
--query nodeImageVersionすべてのノードイメージを更新する場合は、Kubernetes バージョンを上げずに --node-image-only を使う方法があります。
az aks upgrade \
--resource-group $AKS_RESOURCE_GROUP \
--name $AKS_CLUSTER \
--node-image-only \
--yes特定のノードプールだけを更新する場合は、次のようにします。
az aks nodepool upgrade \
--resource-group $AKS_RESOURCE_GROUP \
--cluster-name $AKS_CLUSTER \
--name $AKS_NODEPOOL \
--node-image-only注意したいのは、ノードイメージ更新も通常のアプリケーション運用に影響し得る点です。DaemonSet、CSI ドライバー、監視エージェント、セキュリティエージェント、GPU ノードなど、ノードに依存するコンポーネントは特に事前検証が必要です。
管理者・開発者が今すぐ行うべきチェックリスト
今回の AKS セキュリティガイダンスを受けて、まずは次のチェックリストを使って現状を確認しましょう。
| 対象 | チェック項目 | 優先度 |
|---|---|---|
| クラスターモード | AKS Automatic か AKS Standard かを一覧化している | 高 |
| 責任分界 | Azure 側、自社インフラ側、開発チーム側の責任を文書化している | 高 |
| 認証 | Microsoft Entra ID 統合を利用している | 高 |
| 認可 | Kubernetes RBAC を namespace 単位で最小権限にしている | 高 |
| 管理者権限 | cluster-admin の付与先と理由を説明できる | 高 |
| API サーバー | アクセス元、監査ログ、緊急時権限を管理している | 高 |
| Metadata API | Pod から 169.254.169.254 への不要な到達を制限している | 高 |
| コンテナー | root 実行、privileged、特権昇格を避けている | 高 |
| 脅威検出 | Defender for Containers のアラート対応フローがある | 中 |
| Kubernetes 更新 | 現在のマイナーバージョンがサポート範囲内にある | 高 |
| ノード更新 | ノードイメージ更新の頻度と担当者が決まっている | 高 |
| 本番展開 | PDB、max surge、メンテナンス時間を設定している | 中 |
| 監査 | 例外設定に期限と所有者がある | 中 |
最初から完璧なセキュリティ運用を作る必要はありません。まずは「クラスター一覧」「権限一覧」「バージョン一覧」「例外一覧」の4つを作るだけでも、リスクの見える化が進みます。
移行・展開時に注意すべきポイント
AKS Standard から AKS Automatic への移行や、新規クラスターで AKS Automatic を検討する場合は、単純に「管理が楽になるか」だけで判断しない方がよいです。見るべき観点は、セキュリティベースライン、拡張性、既存ネットワーク設計、監査要件、運用チームのスキルです。
AKS Automatic を選びやすいケース
AKS Automatic は、クラスター運用の標準化を進めたい組織や、AKS のベストプラクティスに沿った既定構成を活用したいチームに向いています。たとえば、アプリケーション開発チームが Kubernetes の低レイヤー運用に多くの時間を割けない場合、AKS Automatic の事前構成は有力な選択肢になります。
ただし、すべての既存要件に合うとは限りません。ネットワーク、ポリシー、セキュリティツール、ノード構成に強いカスタマイズ要件がある場合は、AKS Standard の方が適していることもあります。
AKS Standard を継続すべきケース
AKS Standard は、細かなネットワーク制御、特殊なノードプール、既存のセキュリティ基準、組織独自の運用フローを維持したい場合に向いています。その代わり、責任範囲は広くなります。
特に次のような環境では、AKS Standard の設定を継続的に監査する仕組みが必要です。
- 金融、医療、公共系など監査要件が厳しい
- 複数テナントが同じクラスターを使う
- GPU ノードや Windows ノードを使っている
- 独自の CNI、Ingress、Service Mesh、セキュリティエージェントを組み込んでいる
- 本番クラスターが複数リージョンに分散している
よくある失敗と回避策
AKS のセキュリティ運用では、設定そのものよりも「継続運用」でつまずくことが多くあります。
| よくある失敗 | 原因 | 回避策 |
|---|---|---|
| cluster-admin が増え続ける | 緊急対応後に権限を戻していない | 期限付き権限、月次棚卸し、承認フローを導入する |
| NetworkPolicy が効いていない | クラスター側のネットワークポリシー設定を確認していない | 作成前後でポリシーエンジンと通信テストを確認する |
| アップグレードが失敗する | PDB、クォータ、IP 枯渇を見落としている | 事前検証と pre-upgrade validation の結果を確認する |
| ノード更新を後回しにする | Kubernetes バージョン更新と混同している | ノードイメージ更新を別タスクとして管理する |
| AKS Automatic に任せきりにする | 責任分界を誤解している | アラート対応、例外管理、ワークロード設定は自社責任と明記する |
| 開発環境だけで判断する | 本番固有の負荷、PDB、外部接続が反映されていない | 本番相当の検証環境か段階展開を用意する |
特に注意したいのは、セキュリティ設定を「一度入れたら終わり」にしないことです。AKS は Kubernetes、ノード OS、Azure 側の機能、アプリケーション依存関係が継続的に変わるため、定期的な見直しを前提に運用する必要があります。
まとめ：AKS のセキュリティ対策は「責任分界」と「継続更新」から始める
今回更新された Azure Kubernetes Service の公式セキュリティベストプラクティスでは、AKS Automatic と AKS Standard の違いを踏まえた運用責任の整理が重要なテーマになっています。AKS Automatic は事前構成されたセキュリティベースラインを活用できますが、脅威検出、例外管理、ワークロード権限、アップグレード検証まで自動で完結するわけではありません。AKS Standard は柔軟に構成できる一方で、認証・認可、ネットワーク、ポリシー、ノード更新、アップグレード計画を管理者が明示的に維持する必要があります。
次に取るべき行動は、まず自社の AKS クラスターを一覧化し、クラスターモード、Kubernetes バージョン、ノードイメージ、RBAC、NetworkPolicy、Defender for Containers、例外設定を確認することです。そのうえで、AKS Automatic と AKS Standard のどちらであっても、セキュリティを「初期設定」ではなく「継続的な運用品質」として管理する体制を作りましょう。
コメント