午前I問題

コンテナ型仮想化の特性として、最も適切なものはどれか。

ア）各コンテナは独立したOSカーネルを持ち、ハイパーバイザを介してホストのハードウェアリソースを管理する。　イ）コンテナイメージはビルド時に確定した不変の構成単位であり、実行中のコンテナへの変更はコンテナ停止後に失われる。　ウ）コンテナ内のプロセスはホストOSカーネル機能に一切アクセスできないため、仮想マシンより高い分離性を持つ。　エ）コンテナ型仮想化はホストOSに依存しないため、LinuxコンテナはWindowsカーネル上でも変更なく動作する。

午前I の解答・解説を見る

正解： イ）

解説：

  • ア）誤り。コンテナは独立したOSカーネルを持たず、ホストOSのカーネルを複数のコンテナで共有する。独立したカーネルを持ちハイパーバイザを介してリソース管理を行うのは仮想マシン（VM）の特性である。
  • イ）正解。コンテナイメージはDockerfileなどによりビルド時に構成が確定した不変（イミュータブル）な成果物である。実行中のコンテナ内でファイルを変更しても、コンテナ停止・削除後には変更が失われる。この特性により環境の再現性と一貫性が確保され、イミュータブルインフラの考え方の基礎となる。
  • ウ）誤り。コンテナはホストOSのカーネルを共有するため、特権コンテナ（--privileged）や不適切なCapabilities設定の場合、ホストカーネルの機能に広くアクセスできてしまう。仮想マシンの方がカーネルレベルの分離性は高い。
  • エ）誤り。コンテナはホストOSのカーネルに依存するため、LinuxコンテナはLinuxカーネル上でのみネイティブに動作する。Windowsホスト上では WSL2（Windows Subsystem for Linux 2）を介する必要がある。

午前II問題

Kubernetesにおけるセキュリティ機能の説明として、最も適切なものはどれか。

ア）NetworkPolicyは、Podが受信するHTTPリクエストの内容をL7レイヤで解析し、WAFのように不正なリクエストパターンをブロックする機能である。

イ）RBACのRoleは特定の名前空間内のリソースへのアクセス権限を定義し、ClusterRoleはクラスタ全体のリソースに対する権限を定義する。

ウ）PodのsecurityContextでrunAsRootをtrueに設定することで、コンテナ内のrootプロセスがホストOSのrootに昇格することを防止できる。

エ）ServiceAccountはPod間通信を暗号化するmTLSを実装するために必須の設定であり、省略するとPod間通信が自動的に拒否される。

午前II の解答・解説を見る

正解： イ）

解説：

  • ア）誤り。NetworkPolicyはPod間または外部とPod間の通信をIPアドレス・ポート番号・ラベルセレクタで制御するL3/L4レイヤのファイアウォール機能である。HTTPリクエストの内容をL7で解析するWAF機能は持たない。L7制御にはIstioなどのサービスメッシュが必要となる。
  • イ）正解。KubernetesのRBAC（Role-Based Access Control）では、Roleは特定の名前空間（Namespace）内のリソース（Pod・Service・Deploymentなど）へのアクセス権を定義し、ClusterRoleはクラスタ全体または名前空間横断のリソース（Node・PersistentVolumeなど）への権限を定義する。それぞれをRoleBinding・ClusterRoleBindingでServiceAccountやユーザに紐づける。
  • ウ）誤り。runAsRootではなくrunAsNonRoot: trueを設定することでコンテナがroot以外のユーザで実行されることを強制する。またallowPrivilegeEscalation: falseを設定して権限昇格を禁止する。コンテナ内のrootはLinuxのNamespaceにより分離されているが、設定なしでは誤った特権操作のリスクがある。
  • エ）誤り。ServiceAccountはPodがKubernetes APIサーバにアクセスするためのIDを提供する仕組みである。Pod間通信の暗号化（mTLS）はIstioなどのサービスメッシュが担うものであり、ServiceAccount設定とは独立している。設定なしでもPod間通信は拒否されず、デフォルトでは平文通信が行われる。

午後問題

ECサービスを提供するX社は、オンプレミスのモノリシックアーキテクチャから、Kubernetes上のマイクロサービスアーキテクチャへの移行を完了した。セキュリティ担当のC氏は移行後の本番クラスタを監視していたところ、決済サービスPodの一つが外部C2サーバと不審な通信を行っていることをSIEMで検知した。調査の結果、決済サービスのコンテナイメージに含まれていたサードパーティライブラリに既知の脆弱性があり、攻撃者がRCE（リモートコード実行）を成功させていたことが判明した。さらに、その侵害されたPodからクラスタ内の他マイクロサービス（在庫管理・ユーザ管理）へのポートスキャンが行われており、水平移動（ラテラルムーブメント）が試みられていた。C氏はこの事案を受け、再発防止のためのセキュリティ設計を見直すことにした。

設問1

侵害されたPodからクラスタ内の他Podへの水平移動（ラテラルムーブメント）を防ぐために、Kubernetesクラスタに事前に実装すべきセキュリティ対策を2つ挙げ、それぞれの有効性を述べよ。

設問1の解答・解説を見る

正解例（下記から2つ）：

  1. NetworkPolicyによるPod間通信のホワイトリスト制御 デフォルトでクラスタ内のすべてのPod間通信を拒否するNetworkPolicyを設定し、決済サービス・在庫管理・ユーザ管理など必要なサービス間の通信のみを明示的に許可する。侵害されたPodが不要なポートスキャンや横断アクセスを試みても、許可されていない宛先への通信がネットワークレベルで遮断され、ラテラルムーブメントを防止できる。

  2. 最小権限ServiceAccountの適用（RBAC） 各Podに専用のServiceAccountをRBACで割り当て、そのPodが必要とするKubernetes APIリソースのみにアクセスを制限する。侵害されたPodがKubernetes APIを通じて他のPod情報の取得やSecretの読み取りを試みても、権限がない操作はAPI Serverに拒否される。

  3. securityContextによる権限制限 PodのsecurityContextでrunAsNonRoot: true・allowPrivilegeEscalation: false・readOnlyRootFilesystem: trueを設定する。侵害されたコンテナ内での特権昇格や、ファイルシステムへのマルウェア書き込みを防ぎ、攻撃者がコンテナ内で実行できる操作を大幅に制限できる。

採点ポイント：

  • NetworkPolicyを挙げ「デフォルト拒否」「ホワイトリスト制御」「ネットワーク遮断」のいずれかに言及（5点）
  • ServiceAccount/RBACを挙げ「最小権限」「KubernetesAPI制限」に言及（5点）
  • または securityContext を挙げ「権限昇格防止」「読み取り専用」に言及（代替正解として5点）

設問2

今回の侵害の起点となったのは「コンテナイメージに含まれるサードパーティライブラリの既知脆弱性」であった。CI/CDパイプラインにおいてコンテナイメージのサプライチェーンセキュリティを確保するための対策を2つ挙げ、それぞれの有効性を説明せよ。

設問2の解答・解説を見る

正解例（下記から2つ）：

  1. コンテナイメージの脆弱性スキャン（TrivyやClair等の導入） CI/CDパイプラインのビルドステージで、コンテナイメージをコンテナレジストリへプッシュする前に脆弱性スキャナで解析する。OSパッケージやアプリケーション依存ライブラリに含まれるCVE（共通脆弱性識別子）の有無を確認し、高深刻度の脆弱性が検出された場合はデプロイをブロックするゲートを設ける。既知の脆弱なコンポーネントを持つイメージが本番環境へデプロイされることを防止できる。

  2. コンテナイメージへの署名と検証（Cosign/Notary等の導入） ビルドしたコンテナイメージにCI/CDパイプライン上でデジタル署名（Cosign等）を付与し、Kubernetesクラスタへのデプロイ時にAdmission Controllerで署名の有効性を検証する。署名のないイメージや検証に失敗したイメージのデプロイを拒否することで、改ざんされたイメージや承認されていない経路から持ち込まれたイメージの実行を防止できる。

  3. 信頼できるベースイメージの管理とアップデートポリシーの策定 公式・最小限のベースイメージ（Distroless・Alpine等）のみを許可し、組織内で承認されたイメージリストを管理する。定期的にベースイメージを最新版に更新するパイプラインを設け、既知の脆弱性が修正された新バージョンへ継続的に追従する仕組みを整備する。

採点ポイント：

  • 脆弱性スキャンを挙げ「CVE検出」「デプロイブロック」「レジストリプッシュ前」のいずれかに言及（5点）
  • イメージ署名・検証を挙げ「改ざん検知」「Admission Controller」「未承認イメージ拒否」のいずれかに言及（5点）

重要キーワード

用語説明
NetworkPolicyKubernetesでPod間・外部間の通信をIPアドレス・ポート・ラベルセレクタで制御するリソース。デフォルト拒否ルールとホワイトリスト許可を組み合わせてラテラルムーブメントを防止する
RBAC（Role-Based Access Control）ロールに基づいてKubernetesリソースへのアクセス権を制御する仕組み。RoleとClusterRoleで名前空間単位・クラスタ単位の権限を分けて管理し、最小権限の原則を実現する
securityContextKubernetesのセキュリティ設定項目。runAsNonRoot・allowPrivilegeEscalation: false・readOnlyRootFilesystemなどを設定してコンテナの特権を制限する
イミュータブルインフラコンテナイメージを不変の成果物として扱い、設定変更は再ビルド・再デプロイで実施する考え方。デプロイの再現性・一貫性を確保し、ドリフトによる設定不整合を防ぐ
サプライチェーンセキュリティソフトウェアの開発・ビルド・配布の全工程にわたるセキュリティ確保。コンテナイメージの脆弱性スキャン・署名検証・信頼できるベースイメージの管理が主な対策となる
Admission ControllerKubernetesのAPIサーバがリソース操作を受け付ける前にリクエストを検証・変更するプラグイン機構。イメージ署名検証やPodセキュリティ設定の強制適用に活用される

まとめ

  • 午前I視点： コンテナはホストOSカーネルを共有するため仮想マシンより分離性が低く、イミュータブルなイメージにより再現性を担保するという基本特性を押さえる。VMとコンテナの違い（カーネル共有の有無・起動速度・分離レベル）は高度試験全般で頻出。
  • 午前II視点： KubernetesのRBAC（Role/ClusterRoleの違い）・NetworkPolicy（L3/L4制御でL7ではない）・ServiceAccount（KubernetesAPI認証用でありmTLSとは別）という3つの機能の役割と限界を正確に区別することが重要。
  • 午後視点： コンテナ環境のインシデント対応では「侵害されたPodの横展開をどう防ぐか（NetworkPolicy＋RBAC）」と「侵害の起点となったイメージの脆弱性管理（CI/CDスキャン＋署名）」という2軸で対策を整理する。設問では単なるツール名の列挙でなく、具体的なメカニズムと有効性の説明が採点対象となる。