現場実践｜Kubernetesセキュリティ

Kubernetesのセキュリティ設計入門｜RBAC・Pod Security・ネットワークポリシーの実践

「KubernetesのセキュリティってどこまでやればいいのI？」——KubernetesのRBAC（アクセス制御）・Pod Security Standards・NetworkPolicyを使ったセキュリティ設計の基礎を解説します。

読了目安：約18分更新日：2026年3月

💡 Kubernetesはデフォルトでは「同じクラスター内のPod同士が自由に通信できる」という危険な状態です。本番環境では必ずRBAC・Pod Security・NetworkPolicyの3つを設定する必要があります。

この記事を書いた人

現役ITエンジニア・IT講師（経験14年）

CCNA・CCNP 取得LPIC-1 保有SES現場を複数経験

Kubernetesのセキュリティ設計・本番環境の構築を複数案件で担当してきた立場から解説します。

1. RBAC（ロールベースアクセス制御）

KubernetesのRBACはServiceAccount・Role・RoleBindingの3つの概念で構成されます。「開発者はdevelopmentネームスペースのDeploymentをget/list/watchできる」「SREは全ネームスペースのPodをget/listできる」という細かいアクセス制御をRBACで実現します。

2. Pod Security Standards

# ネームスペースにrestricted Pod Security Standardsを適用
kubectl label namespace production \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/enforce-version=latest

# restrictedでは以下が禁止される:
# - privilegedコンテナの実行
# - hostNetworkの使用
# - rootユーザーでの実行（runAsNonRoot: true が必要）
# - 危険なSysCtlsの設定

Pod Security StandardsにはPrivileged（制限なし）・Baseline（基本的な制限）・Restricted（最も厳格）の3レベルがあります。本番環境ではRestrictedを適用することを推奨します。

3. NetworkPolicyでPod間通信を制限

デフォルトのDeny-Allポリシー：まず全ての通信を禁止するNetworkPolicyを設定してから、必要な通信のみを許可するホワイトリスト方式が推奨
フロントエンド→バックエンドのみ許可：「frontendラベルのPodからbackendポートへの通信のみ許可」というポリシーでマイクロサービス間の通信を制限する
DB Podへのアクセス制限：「app-serverラベルのPodからのみDBの5432ポートへのアクセスを許可」という設定でDB Podを保護する

4. イメージの脆弱性スキャン

本番環境にデプロイするコンテナイメージは、CI/CDパイプライン内で脆弱性スキャンを実行することを推奨します。TrivyはOSSの軽量なコンテナイメージスキャナーで、GitHub ActionsでPR時に自動スキャンを実行できます。HIGH/CRITICAL の脆弱性があるイメージのデプロイをブロックするポリシーが理想です。

📌 この記事のポイント