概要

コンテナ技術（Docker）とオーケストレーション（Kubernetes）は現代のWebシステムのインフラ標準になっています。コンテナはVM（仮想マシン）より軽量ですがカーネルを共有するため、固有のセキュリティリスクがあります。SC試験では近年コンテナ環境のセキュリティが出題されており、基本概念と対策を押さえる必要があります。

コンテナとVMのセキュリティの違い

VM（仮想マシン）：
[アプリA] [アプリB] [アプリC]
 [Guest OS] [Guest OS] [Guest OS]
 [ハイパーバイザ]
 [ホストOS]
 ← VMは独立したカーネルを持つため分離度が高い

コンテナ：
[アプリA] [アプリB] [アプリC]
 [コンテナランタイム（Docker等）]
 [ホストOS（カーネルを共有）]
 ← カーネルを共有するため、カーネル脆弱性は全コンテナに影響
VM と コンテナ の分離度の比較
VM（仮想マシン） コンテナ
カーネル
各VMが独立したカーネル
ホストOSのカーネルを共有
分離度
高い
VMより低い
カーネル脆弱性の影響
他VMに影響しにくい
全コンテナに影響し得る
起動速度・軽量性
遅い・重い
速い・軽量

コンテナのセキュリティリスクと対策

1. イメージの脆弱性

コンテナイメージは基盤OSイメージと依存パッケージを含みます。

脆弱性の混入経路：
FROM ubuntu:20.04          ← 古いベースイメージに既知脆弱性
RUN apt-get install ...    ← 脆弱なライブラリのインストール
COPY app.jar .             ← アプリ依存ライブラリの脆弱性

対策：

  • イメージスキャン（Trivy・Snyk・AWS ECR Scan）でCI/CDに組み込む
  • ベースイメージを定期更新
  • ディストロレスイメージ（gcr.io/distroless 等）：最小限のコンポーネントのみを含み攻撃面を削減

2. 特権コンテナの禁止

# 危険な設定
securityContext:
  privileged: true    ← ホストカーネルへのフルアクセスを許可

# 安全な設定
securityContext:
  runAsNonRoot: true  ← rootで実行しない
  readOnlyRootFilesystem: true  ← ファイルシステムを読み取り専用に
  capabilities:
    drop: ["ALL"]     ← 不要なLinuxケーパビリティを全て削除

3. コンテナの脱出攻撃

コンテナ内の脆弱性や設定ミスを利用してホストに脱出する攻撃です。

手法内容
特権コンテナの悪用privileged: true のコンテナからホストにアクセス
マウントの悪用ホストのファイルシステムをマウントしてアクセス
カーネル脆弱性共有カーネルの脆弱性を利用して脱出
Kubernetesのセキュリティ構成要素
RBAC
役割ベースのアクセス制御
ServiceAccount
PodのAPI認証
NetworkPolicy
Pod間通信の制限
K8s Secrets
base64のみ・Vault連携推奨
Podセキュリティ標準
Restricted等のプロファイル
K8sクラスタ
セキュリティ制御

Kubernetesのセキュリティ

RBAC（Role-Based Access Control）

Kubernetesのリソースへのアクセスを役割で制御します。

# 必要最小限の権限のみを付与
kind: Role
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]  ← readのみ。deleteは不要なら与えない

認証・認可

仕組み説明
kubectl + kubeconfig管理者がAPIサーバに接続するための設定ファイル
ServiceAccountPod がKubernetes APIにアクセスするための認証
OIDC統合外部IdP（Okta・Azure AD等）でKubernetes認証

ネットワークポリシー

デフォルトではK8s内の全Podが相互通信可能です。NetworkPolicyで制限します。

# 同じNamespace内のPodからのみ受信を許可（マイクロセグメンテーション）
kind: NetworkPolicy
spec:
  podSelector:
    matchLabels:
      app: database
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: backend

シークレット管理

# 避けるべき設定
env:
- name: DB_PASSWORD
  value: "plaintext_password"  ← 環境変数に平文パスワード

# 改善（K8s Secrets + 外部Vault）
env:
- name: DB_PASSWORD
  valueFrom:
    secretKeyRef:
      name: db-secret
      key: password

さらに安全な対策：K8sのSecretはbase64エンコードのみで暗号化ではありません。HashiCorp Vault・AWS Secrets Managerと連携して真の暗号化を実現します。

Podセキュリティ標準

Kubernetesが提供する3つのセキュリティプロファイルです。

レベル説明
Privileged制限なし（CI/CDエージェント等に使用）
Baseline明らかに危険な設定のみ禁止
Restricted最小権限。本番ワークロードで推奨

SC試験での頻出ポイント

  • コンテナとVMの分離の違い：VMはカーネル独立、コンテナはカーネル共有（カーネル脆弱性の影響が全コンテナに及ぶ）
  • 特権コンテナの危険性：ホストカーネルへのフルアクセスが可能になり、コンテナ脱出リスクが高い
  • イメージスキャンの目的：コンテナイメージに含まれる脆弱なライブラリをCI/CDで早期に検出
  • K8sのRBACの重要性：デフォルト設定では過剰な権限があるため、最小権限でRoleを設計する
  • K8s Secretsの問題点：base64エンコードであり暗号化ではないため、外部のVaultとの連携が推奨

よくある誤問・ひっかけパターン

誤り① 「コンテナはVMより安全」→ 誤。コンテナはカーネルを共有するためVMより分離が弱く、適切な設定が必要です。

誤り② 「K8s Secretsに保存すれば平文より安全」→ 不十分。K8s Secretsはbase64エンコードのみで暗号化ではありません。etcdの暗号化設定またはVault連携が必要です。

誤り③ 「コンテナのファイアウォールはホストOSのiptablesで十分」→ 誤。K8sのNetworkPolicyによるPodレベルのマイクロセグメンテーションが必要です。

関連用語

重要キーワード

用語説明
コンテナアプリとその依存環境を隔離して実行する軽量仮想化技術
特権コンテナホストカーネルへのフルアクセスを持つ危険なコンテナ設定
イメージスキャンコンテナイメージの既知脆弱性を検出するツール・プロセス
K8s RBACKubernetesリソースへのアクセスを役割で制御する仕組み
NetworkPolicyK8s内のPod間通信を制限するマイクロセグメンテーション
K8s SecretsK8sの認証情報管理機能。base64のみでVault連携を推奨