レッスン4：RBACとKubernetesセキュリティ

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

RBACは誰（User、Group、ServiceAccount）がどのリソース（resources）に対して何（verbs）ができるかを、namespaceまたはクラスターレベルで制御します。

RBAC Flow:
Subject (Who?)    →    Role/ClusterRole (What?)    →    RoleBinding (Links)

  User "alice"          Role "pod-reader"              RoleBinding
  ServiceAccount        - get pods                     alice → pod-reader
  Group "devs"          - list pods                    (in namespace "dev")
                        - watch pods

オブジェクト	スコープ	使用場面
Role	Namespace	1つのnamespace内の権限
ClusterRole	Cluster-wide	クラスター全体またはnamespaceに属さないリソース（nodes）の権限
RoleBinding	Namespace	RoleまたはClusterRoleを1つのnamespace内のSubjectに紐付け
ClusterRoleBinding	Cluster-wide	ClusterRoleをクラスター全体のSubjectに紐付け

試験のポイント： RoleBindingでClusterRoleを特定のnamespaceに紐付けることができます。これはクラスター全体の権限を付与せずに権限テンプレートを再利用する方法です。試験によく出ます！

2. ServiceAccount

各PodにはServiceAccountを関連付けることができます。ServiceAccountのトークンは自動的に/var/run/secrets/kubernetes.io/serviceaccount/にマウントされます。PodはこのトークンでKubernetes APIを呼び出します。

Default ServiceAccount flow:
  Pod → ServiceAccount → RBAC Role → API Server

例: PrometheusがPodメトリクスを読み取る必要がある場合:
  ServiceAccount: prometheus-sa
  ClusterRole: pod-metrics-reader (verbs: get, list, watch)
  ClusterRoleBinding: prometheus-sa → pod-metrics-reader

3. NetworkPolicy

デフォルトでは、クラスター内のすべてのPodが相互通信可能です。NetworkPolicyはPodセレクター、namespaceセレクター、またはIPブロックに基づいてingress/egressトラフィックを制限します。

❌ Default (no NetworkPolicy): All pods talk to all pods
✅ With NetworkPolicy:
   frontend → backend (allowed)
   frontend → database (BLOCKED)
   backend → database (allowed)

試験のポイント： NetworkPolicyはCNIプラグインがサポートしている場合のみ有効です（Calico、Cilium、Weave）。FlannelはNetworkPolicyをサポートしません。ポリシーがなければ→全許可。1つでもポリシーがあれば→選択されたトラフィックはデフォルト拒否。

4. Pod Security Standards

Kubernetesは3つのPod Security Standardsを定義しています（v1.25からPodSecurityPolicyを置き換え）：

プロファイル	制限レベル	用途
Privileged	制限なし	システム/インフラワークロード（kube-system）
Baseline	明らかな権限エスカレーションを防止	一般的なワークロード
Restricted	最大限のハードニング準拠	セキュリティ重視のアプリ

5. SecurityContext

SecurityContextはPodまたはコンテナレベルでセキュリティを構成します：

セキュリティ設定	意味
runAsNonRoot: true	コンテナはUID 0で実行不可
runAsUser: 1000	UID 1000でコンテナを実行
readOnlyRootFilesystem: true	ファイルシステムは読み取り専用（書き込みはvolumeを使用）
allowPrivilegeEscalation: false	プロセスの権限エスカレーションを禁止
capabilities.drop: ["ALL"]	すべてのLinux capabilitiesを削除

6. チートシート

試験の質問	回答
PodがK8s APIを呼び出す必要がある場合は？	ServiceAccount
1つのnamespace内でユーザー権限を制限するには？	Role + RoleBinding
Pod間のネットワークトラフィックを制限するには？	NetworkPolicy
NetworkPolicyが機能するために何が必要？	サポートするCNIプラグイン（Calico、Cilium）
Privileged → Restricted、Pod Securityには？	Pod Security Admission

7. 練習問題

Q1: アプリケーションPodが自身のnamespace内のPodをリストするためにKubernetes APIにアクセスする必要があります。クラスター管理者は何を作成すべきですか？

• A) すべてのnamespace用のClusterRoleとClusterRoleBinding
• B) ServiceAccountとRole（list pods）とRoleBinding ✓
• C) APIサーバー用のLoadBalancerタイプのService
• D) APIサーバーの認証情報を含むConfigMap

解説：PodにはServiceAccount、そのnamespace内で「list pods」を許可するRole、およびそれらを紐付けるRoleBindingが必要です。ClusterRoleを使用するとすべてのnamespaceにアクセス権を過剰に付与することになります。

Q2: NetworkPolicyがPodに適用されています。どのルールにも明示的に一致しないトラフィックのデフォルトの動作は何ですか？

• A) すべてのトラフィックが許可される（デフォルト許可）
• B) トラフィックはログに記録されるがブロックされない
• C) Podセレクターに一致するトラフィックは拒否され、その他のトラフィックは通過する ✓
• D) Podとの間のすべてのトラフィックが拒否される

解説：NetworkPolicyがPodを選択すると（podSelector経由）、そのポリシータイプ（ingress/egress）で明示的に許可されていないすべてのトラフィックは拒否されます。選択されていないPodは影響を受けず、完全な接続性を維持します。

Q3: ホストへの特権アクセスを必要とするシステムレベルコンポーネントには、どのPod Security Standardsプロファイルを使用すべきですか？

• A) Restricted
• B) Baseline
• C) Privileged ✓
• D) SystemAdmin

解説：PrivilegedプロファイルはPodに制限を設けず、すべてのcapabilitiesを許可します。システム/インフラコンポーネント向けです。Baselineは既知の権限エスカレーションを防止し、Restrictedは最大限のハードニングを適用します。