Azure Kubernetes Service（AKS）のセキュリティ設計を見直すなら、今回まず確認すべきなのは「AKS Automatic と AKS Standard で、最初から有効なセキュリティ既定値が違う」という点です。2026年6月5日に更新された Microsoft Learn の公式ドキュメントでは、AKS のセキュリティ概念が、ID・認可、ネットワーク、ノード、ワークロード保護、サプライチェーン、Secrets 管理まで整理され、特に AKS Automatic の強化された既定構成が明確になりました。(Microsoft Learn)
すでに AKS Standard を運用している管理者は、「Automatic なら既定で有効な設定が、自社クラスターでは未設定のままになっていないか」を棚卸しするのが最優先です。開発者は、コンテナイメージ、権限、Secret、Pod Security Standards、ネットワークポリシーをデプロイ前に確認し、CI/CD と運用ルールに組み込む必要があります。
Azure Kubernetes Serviceのセキュリティ更新で押さえるべき結論
今回の「Concepts – Security in Azure Kubernetes Services (AKS)」更新は、単一の新機能追加というより、AKS のセキュリティ設計を AKS Automatic と AKS Standard の違いを前提に再整理した内容 と見るべきです。
Microsoft Learn のページは 2026年6月5日に更新され、GitHub のドキュメント履歴では 2026年6月4日に「Adding AKS Automatic」という変更が入り、1ファイルに対して 64行追加・35行削除が行われています。(Microsoft Learn)
実務上のポイントは、次の3つです。
| 確認ポイント | 管理者が見るべきこと | 開発者が見るべきこと |
|---|---|---|
| AKS Automatic と Standard の差 | Azure RBAC、API Server VNet 統合、Workload Identity、Pod Security Standards などの既定状態 | デプロイ先クラスターで必要な制約が有効か |
| サプライチェーン保護 | レジストリスキャン、署名、ポリシーゲート、Defender for Containers | 脆弱性対応、イメージ署名、CIでの検査 |
| ノードとOSの継続運用 | ノードOS、アップグレード、Azure Linux 2.0 移行、メンテナンス計画 | ベースイメージ更新、ロールアウト方式、互換性確認 |
特に注意したいのは、AKS Automatic の既定値を「便利な自動化」とだけ捉えないことです。Automatic は多くのセキュリティ制御が事前構成される一方、Standard は柔軟性が高く、同等の保護を得るには明示的な設計と有効化が必要です。(Microsoft Learn)
変更点の中心はAKS Automaticのセキュリティ既定値
今回の更新で最も重要なのは、AKS が「Automatic」と「Standard」の2つのクラスター運用モードを前提に説明されるようになった点です。
公式ドキュメントでは、AKS Automatic は強化されたセキュリティベースラインを持ち、複数の制御が既定で事前構成される一方、AKS Standard は構成の自由度が高いと説明されています。(Microsoft Learn)
AKS Automaticで事前構成される主なセキュリティ項目
AKS Automatic では、次のようなセキュリティ制御が既定で組み込まれます。
| 項目 | AKS Automaticでの扱い | AKS Standardで確認すべきこと |
|---|---|---|
| Azure RBAC for Kubernetes authorization | 事前構成 | Azure RBAC または Kubernetes RBAC + Microsoft Entra ID の設計 |
| API Server VNet 統合 | 事前構成 | パブリックAPIサーバーの公開範囲、Private Cluster、Authorized IP ranges |
| Workload Identity / OIDC issuer | 事前構成 | Pod が Azure リソースへ安全にアクセスする方式 |
| Deployment safeguards | 事前構成 | Azure Policy によるデプロイ制御 |
| baseline Pod Security Standards | enforce mode で事前構成 | privileged Pod、root実行、hostPath などの制限 |
| Image cleaner | 事前構成 | 未使用かつ脆弱なイメージの削除運用 |
| Managed system node pool restrictions | 事前構成 | システムノードとユーザーワークロードの分離 |
AKS Standard を使っている場合、「うちは Standard だから関係ない」と考えるのは危険です。むしろ今回の更新は、Standard クラスターで不足しがちな設定を洗い出すための比較表として使えます。
たとえば、既存の Standard クラスターで API Server がパブリックに公開され、Authorized IP ranges も Private Cluster も使っていない場合、管理プレーンへの到達経路が広すぎる可能性があります。公式ドキュメントでも、API Server は既定でパブリックIPアドレスとFQDNを使い、アクセス制限には Authorized IP ranges や Private Cluster を利用できると説明されています。(Microsoft Learn)
影響範囲は「クラスター設定」だけでなくCI/CDと運用体制にも及ぶ
AKS のセキュリティは、クラスター作成時の設定だけでは完結しません。今回の公式情報では、ビルド環境、レジストリ、クラスター、ノード、ネットワーク、アプリケーション、Secrets までを一連の保護対象として扱っています。(Microsoft Learn)
つまり影響範囲は、インフラ管理者だけではありません。
| 役割 | 影響する領域 | 確認すべき内容 |
|---|---|---|
| クラウド管理者 | クラスター、ネットワーク、ノード | API Server公開範囲、RBAC、Private Cluster、ノードOS、アップグレード |
| セキュリティ担当 | ポリシー、監査、脆弱性管理 | Azure Policy、Defender for Containers、イメージスキャン、例外管理 |
| 開発者 | コンテナ、マニフェスト、Secret | root実行、特権コンテナ、Secretの扱い、リソース権限 |
| SRE / 運用担当 | 更新、障害対応、展開方式 | Node OS更新、Blue/Green、Canary、メンテナンスウィンドウ |
| CI/CD担当 | ビルド、署名、レジストリ | 静的解析、脆弱性評価、イメージ署名、ポリシーゲート |
特に見落としやすいのが、ビルドとレジストリです。公式ドキュメントでは、イメージをデプロイ環境へ昇格する前に、CIで静的解析、脆弱性評価、コンプライアンス評価を実行することが推奨されています。また、レジストリ側でも継続的に脆弱性状態を評価し、Notary V2 などによる署名・検証で信頼できるソースからのデプロイを確認する考え方が示されています。(Microsoft Learn)
管理者が最初に確認すべきAKSセキュリティ設定
AKS 管理者は、まず既存クラスターの状態を「Automatic 相当のベースラインに近いか」という観点で棚卸しします。
IDと認可はMicrosoft Entra IDとRBACを軸に確認する
AKS では、API Server へのアクセス制御に Kubernetes RBAC と Azure RBAC を利用できます。AKS Automatic では Azure RBAC for Kubernetes authorization が事前構成されますが、AKS Standard では環境に合わせて認可モデルを選択・構成します。(Microsoft Learn)
確認すべきことは、単に「RBACが有効か」ではありません。次の観点で見直します。
| 確認項目 | 危険な状態 | 推奨される考え方 |
|---|---|---|
| クラスター管理者権限 | 個人ユーザーに広く付与 | Microsoft Entra ID グループ単位で最小権限を付与 |
| namespace権限 | 全namespaceに広い権限 | チーム・環境ごとに namespace を分離 |
| CI/CDの権限 | 管理者相当の資格情報を使用 | デプロイに必要な範囲だけ許可 |
| 緊急用アカウント | 常用されている | 通常運用では使わず、監査対象にする |
たとえば、開発チームに cluster-admin を渡している場合、デバッグは楽になりますが、Pod Security Standards やネットワーク制御を回避できてしまう可能性があります。namespace単位の Role / RoleBinding に分け、昇格権限は申請制にするほうが安全です。
API Serverの公開範囲を見直す
API Server はクラスター操作の入口です。ここが広く公開されていると、認証情報の漏えいや設定ミスが重大事故に直結します。
AKS では API Server が既定でパブリックIPアドレスとFQDNを使います。アクセスを絞る方法として、Authorized IP ranges や Private Cluster が用意されています。AKS Automatic では API Server VNet 統合が既定のセキュリティ姿勢として事前構成されます。(Microsoft Learn)
実務では、次の基準で判断します。
| 環境 | 推奨方針 |
|---|---|
| 社内・閉域網からのみ運用する本番環境 | Private Cluster または厳格なアクセス制限を優先 |
| CI/CDから操作する環境 | CI/CD実行基盤の送信元IPやプライベート接続を明確化 |
| 検証環境 | 一時的な公開でも期限と所有者を設定 |
| 複数拠点・リモート運用 | VPN、ExpressRoute、踏み台、ゼロトラスト接続を設計 |
「認証があるからパブリック公開でもよい」と考えるのは避けるべきです。認証とネットワーク制限は、どちらか一方ではなく重ねて使うのが基本です。
ノードOSとAzure Linux 2.0の移行状況を確認する
今回の文脈で重要なのが、ノードOSの継続サポートです。公式ドキュメントでは、Azure Linux 2.0 は 2025年11月30日以降 AKS でサポートおよびセキュリティ更新が提供されず、2026年3月31日以降はノードイメージが削除され、該当ノードプールをスケールできなくなると案内されています。(Microsoft Learn)
すでに 2026年6月時点では、この期限を過ぎています。Azure Linux 2.0 のノードプールが残っている場合は、通常のセキュリティ改善ではなく、運用継続リスクとして扱うべきです。
確認手順の例は次の通りです。
| 手順 | 確認内容 | 判断 |
|---|---|---|
| ノードプール一覧を取得 | OS SKU、Kubernetes バージョン、ノードイメージ | Azure Linux 2.0 がないか確認 |
| 本番・検証を分類 | 影響するアプリ、PDB、可用性要件 | 移行順序を決める |
| 移行先を決める | サポート対象の Azure Linux または別OS | 互換性を検証 |
| ステージングで検証 | 起動、通信、監視、ログ、DaemonSet | 問題がなければ本番へ |
| ロールアウト | Blue/Green や段階的移行 | 障害時の切り戻し手順を準備 |
特に DaemonSet、セキュリティエージェント、ログ収集エージェント、CSIドライバー、CNI関連コンポーネントは、OS変更の影響を受けやすい領域です。アプリケーションだけでなく、クラスター周辺コンポーネントも含めて検証してください。
開発者が確認すべきワークロード保護のポイント
AKS のセキュリティは、管理者がクラスターを安全に作れば終わりではありません。開発者が作るマニフェストやコンテナイメージが弱ければ、クラスター側の防御をすり抜けたり、デプロイ時にブロックされたりします。
root実行や特権コンテナを前提にしない
公式ドキュメントでは、コンテナには必要最小限の操作だけを許可し、昇格権限や root アクセスを必要とする構成を避けるべきと説明されています。また、AppArmor や seccomp といった Linux のセキュリティ機能が推奨されています。(Microsoft Learn)
開発者が確認すべき代表例は次の通りです。
| 項目 | 避けたい例 | 改善例 |
|---|---|---|
| 実行ユーザー | root前提のコンテナ | 非rootユーザーで実行 |
| 権限 | privileged: true | 必要な capability のみ付与 |
| ファイルシステム | 書き込み前提のルートFS | readOnlyRootFilesystem を検討 |
| ホスト連携 | hostPath の多用 | PVC、ConfigMap、Secret などに分離 |
| デバッグ | 本番Podへ直接ツール追加 | 別イメージや一時的なデバッグ手順を用意 |
AKS Automatic では baseline Pod Security Standards が enforce mode で事前構成されるため、これまで Standard クラスターで動いていたマニフェストが、そのままでは通らない可能性があります。移行や新規展開の前に、Pod の securityContext を確認しておくことが重要です。
SecretをYAMLに直書きしない
Kubernetes Secrets は、認証情報やキーなどの機密情報を Pod に注入する仕組みです。公式ドキュメントでは、Secret は必要な Pod がスケジュールされたノードにのみ提供され、tmpfs に保存されると説明されています。一方で、Secret のマニフェストには base64 形式のデータが含まれるため、機密情報として扱い、ソース管理へコミットしないよう注意が示されています。(Microsoft Learn)
よくある失敗は、次のような運用です。
| 失敗例 | なぜ危険か | 対応策 |
|---|---|---|
| Secret YAMLをGitに保存 | base64は暗号化ではない | Secret管理ツールや外部シークレット連携を使う |
| 全環境で同じSecretを使う | 検証環境の漏えいが本番影響になる | 環境ごとに分離 |
| アプリログにSecretを出す | 監視基盤・ログ基盤に漏れる | マスキングとログレビューを実施 |
| Secret更新手順がない | 漏えい時に即時ローテーションできない | 更新・再デプロイ手順を整備 |
AKS では etcd 内の Secrets をカスタマー管理キーで保存時暗号化する選択肢もあります。規制対応や内部統制が必要な環境では、クラスター管理者とセキュリティ担当が要件を確認してください。(Microsoft Learn)
イメージの脆弱性は「ビルド時だけ」では足りない
コンテナイメージは、ビルドした瞬間には問題がなくても、その後に新しい脆弱性が公表されることがあります。そのため、CIでの検査だけでなく、レジストリ内の継続的なスキャンが重要です。
公式ドキュメントでも、レジストリセキュリティはビルド後のドリフト検出に役立ち、新たに公開された脆弱性や承認済みビルド経路を通らなかったイメージを検出できると説明されています。(Microsoft Learn)
実務では、次のようなルールに落とし込みます。
| ルール | 具体例 |
|---|---|
| 重大度だけで機械的に止めない | CVSS、悪用可能性、ベンダー状態、公開範囲で優先度を決める |
| 例外には期限を付ける | 「30日以内に修正」「次回リリースまで」など |
| イメージの出所を検証する | 署名、SBOM、承認済みレジストリを使う |
| 古いタグを残しすぎない | latest 依存を避け、不要イメージを削除 |
| 本番反映は段階的に行う | Blue/Green、Canary、ローリング更新を使う |
「脆弱性が1件でもあればビルド失敗」にすると、開発が止まり、例外運用が形骸化しやすくなります。公式ドキュメントでも、すべての脆弱性でビルドを止めるのではなく、リスクベースでトリアージし、ベンダー状態や重大度、猶予期間を使う考え方が示されています。(Microsoft Learn)
ネットワークセキュリティで確認すべき設定
AKS のネットワークセキュリティでは、外部からの入口、Pod間通信、アウトバウンド通信、オンプレミス接続を分けて考える必要があります。
NSGはAKS管理対象のNICレベルを直接変更しない
AKS では Azure Network Security Group（NSG）によって仮想ネットワークの通信を制御できます。ただし、公式ドキュメントでは、独自サブネットを使う場合でも AKS が管理する NIC レベルの NSG を直接変更せず、サブネットレベルの NSG で制御するよう注意されています。ロードバランサー、コントロールプレーン通信、必要な egress を妨げないことも重要です。(Microsoft Learn)
これは実務でよく起きる障害ポイントです。セキュリティ強化のつもりで NSG を厳しくした結果、次のような問題が発生します。
| 発生しやすい問題 | 原因 |
|---|---|
| ノードが正常に参加しない | コントロールプレーンとの通信を遮断 |
| LoadBalancer Service が動かない | Azure Load Balancer 関連通信を遮断 |
| イメージPullに失敗 | レジストリや必要な egress を遮断 |
| 監視ログが欠落 | Azure Monitor やログ送信先への通信を遮断 |
| DNS解決が不安定 | DNSやCNI関連通信の制御ミス |
NSG変更は、アプリ担当だけで判断せず、AKS管理者、ネットワーク担当、セキュリティ担当でレビューするべきです。
Pod間通信はNetwork Policyで制限する
クラスター内部の通信は、何もしなければ想定以上に広がりがちです。AKS では Kubernetes Network Policy を使い、namespace やラベルセレクターを基準に Pod 間の通信を許可・拒否できます。(Microsoft Learn)
たとえば、次のように考えます。
| ワークロード | 許可する通信の例 | 拒否したい通信の例 |
|---|---|---|
| Webフロントエンド | API PodへのHTTP/HTTPS | DB Podへの直接接続 |
| API | DB、Queue、認証基盤 | 他チームnamespaceへの任意通信 |
| バッチ | 必要なストレージ、外部API | 管理系Podへの通信 |
| 監視エージェント | メトリクス収集対象 | Secret管理系への不要通信 |
Network Policy は「制限したい通信を後から拒否する」より、「必要な通信だけ許可する」設計が安全です。ただし、いきなり本番で厳格化すると障害になりやすいため、まず通信経路を可視化し、検証環境で適用してから段階的に本番へ展開します。
AKS Automaticへ移行・新規採用する際の注意点
AKS Automatic は、ノード管理、スケーリング、セキュリティ、推奨構成の多くを Azure 側で扱うため、運用負荷を下げやすい選択肢です。Microsoft Learn では、AKS Automatic はノード管理、スケーリング、セキュリティ、AKS Well-Architected 推奨事項に沿った事前構成を Azure が処理すると説明されています。(Microsoft Learn)
ただし、Automatic を選べば既存運用がそのまま楽になるとは限りません。特に、Standard で細かく調整していたクラスターを Automatic に寄せる場合は、次の点を確認してください。
| 確認項目 | 注意点 |
|---|---|
| セキュリティ制約 | Pod Security Standards や Deployment safeguards で既存マニフェストが拒否される可能性 |
| ノード管理 | システムノードプールの扱いが Standard と異なる |
| ネットワーク | managed Virtual Network、Ingress、Egress の既定が設計と合うか |
| CI/CD | デプロイ権限、namespace、ポリシー違反時の扱いを調整 |
| 監視 | 既存のログ収集・メトリクス基盤との重複や不足を確認 |
| コスト | Standard tier、Pod readiness SLA、関連アドオンの構成を確認 |
AKS Automatic は「自由に何でも変える」より、「Microsoft が用意した安全な既定値に合わせる」方向のサービスです。既存の運用が強いカスタマイズに依存している場合は、Standard のまま不足設定を補うほうが適しているケースもあります。
既存のAKS Standardクラスターで優先的に確認するチェックリスト
既存の AKS Standard クラスターを運用している場合は、以下の順に確認すると効率的です。
| 優先度 | チェック項目 | 確認の観点 |
|---|---|---|
| 高 | Azure Linux 2.0 ノードの有無 | 残存していれば移行を最優先 |
| 高 | API Server公開範囲 | Authorized IP ranges、Private Cluster、VNet統合 |
| 高 | RBAC設計 | 管理者権限の過剰付与、Entra ID連携 |
| 高 | Workload Identity / OIDC | PodからAzureリソースへの認証方式 |
| 高 | Pod Security Standards | privileged、root、hostPath などの制限 |
| 中 | Network Policy | Pod間通信が過剰に許可されていないか |
| 中 | イメージスキャン | CIとレジストリの両方で検査できているか |
| 中 | Defender for Containers | 検出、可視化、継続スキャンの運用 |
| 中 | Secrets管理 | Git混入、ローテーション、etcd暗号化 |
| 低〜中 | Trusted Launch / 分離機能 | 規制対応や高分離要件があるか |
このチェックリストは、単発の監査ではなく、定期レビューに組み込むのが現実的です。特に Kubernetes と AKS はバージョン、OS、アドオン、ポリシーが継続的に変わるため、四半期ごと、または大きなアップグレード前に見直す運用が向いています。
展開時に失敗しやすいポイント
セキュリティ強化は、設定を有効化すれば完了ではありません。むしろ、既存ワークロードとの相性を確認せずに適用すると、障害やリリース停止につながります。
Pod Security Standardsを有効化して既存Podが起動しない
baseline Pod Security Standards を enforce mode で適用すると、これまで許可されていた設定が拒否されることがあります。特に、特権コンテナ、hostPath、root実行、不要な Linux capability を使っている場合は注意が必要です。
対応としては、いきなり本番に enforce するのではなく、検証環境で警告・監査モード相当の確認を行い、違反マニフェストを修正してから段階適用します。
API Serverの制限でCI/CDが止まる
Authorized IP ranges や Private Cluster を適用したあと、CI/CD環境から kubectl やデプロイツールが接続できなくなることがあります。
変更前に、以下を確認してください。
| 確認項目 | 内容 |
|---|---|
| CI/CDの送信元 | 固定IPか、プライベート接続か |
| デプロイ経路 | GitHub Actions、Azure DevOps、自己ホストランナーのどれか |
| 緊急時操作 | 管理者がどこから接続するか |
| DNS | Private Cluster利用時の名前解決 |
| 監査 | 誰が、どの経路で操作したか追跡できるか |
API Server制限は重要ですが、運用経路を閉じてしまうと復旧作業が難しくなります。制限と運用性はセットで設計しましょう。
Network Policyで必要な通信まで遮断する
Network Policy は強力ですが、アプリの通信関係を把握しないまま適用すると、DB接続、DNS、認証、メトリクス収集などが止まります。
最初は重要な namespace から始め、通信ログやサービス依存関係を確認しながら、許可ルールを追加していくのが安全です。
イメージ脆弱性対応が開発チーム任せになる
脆弱性スキャン結果を出すだけでは、実際の修正にはつながりません。担当者、期限、例外承認、再スキャン、リリース判断まで決める必要があります。
たとえば、次のような運用にすると実行しやすくなります。
| 重大度 | 対応例 |
|---|---|
| Criticalかつ悪用可能性あり | 原則即時対応、リリース判断をセキュリティ担当が確認 |
| High | 次回リリースまたは定めたSLA内で修正 |
| Medium | 定期更新で対応 |
| Low | リスク受容またはベースイメージ更新時に対応 |
| 修正不能 | ベンダー状態、回避策、期限付き例外を記録 |
管理者と開発者が次に取るべき行動
今回の AKS セキュリティ更新を受けて、最初にやるべきことは「自社クラスターを AKS Automatic の既定値と比較すること」です。
AKS Automatic を新規採用する場合は、事前構成されたセキュリティ制御にアプリケーションが適合するかを確認します。AKS Standard を継続する場合は、Automatic で既定になっている Azure RBAC、API Server VNet 統合、Workload Identity、OIDC issuer、Pod Security Standards、Image cleaner、Deployment safeguards などを、どこまで明示的に有効化・運用するかを決めます。
最後に、次の順で確認すると無駄がありません。
| 順番 | 実施内容 |
|---|---|
| 1 | 既存クラスターのモード、Kubernetesバージョン、ノードOS、OS SKUを棚卸しする |
| 2 | Azure Linux 2.0 などサポート切れ・移行対象のノードを特定する |
| 3 | API Server、RBAC、Workload Identity、Pod Security Standards の有効状況を確認する |
| 4 | CI/CDでイメージスキャン、署名、ポリシーゲートを整備する |
| 5 | Network Policy、NSG、egress制御をアプリ単位で見直す |
| 6 | Secret管理とローテーション手順を整備する |
| 7 | Blue/Green または Canary で安全にセキュリティ変更を展開する |
AKS のセキュリティは、クラウド管理者だけの作業ではありません。管理者は安全なクラスター基盤を作り、開発者は安全に動くコンテナとマニフェストを用意し、運用担当は継続的に更新・監視・例外管理を回す必要があります。今回の更新は、その役割分担を見直すよいタイミングです。
コメント