RBAC は ServiceAccount とどう連携し、Kubernetes cluster をどうセキュアにしますか？

Question

IT Interview Practice · Accepted Answer

**RBAC（Role-Based Access Control）**は、API 上で*誰が何をできるか*を統制します。権限は、許可された動詞（verb）をリソース上に列挙する **Role** に **subject**（ユーザー、グループ、**ServiceAccount**）を **binding** することで付与されます。RBAC は、より広い cluster ハードニング戦略の 1 つの層です。

## RBAC モデル

```text
SUBJECT (user / group / ServiceAccount)
   │  bound by
   ▼
RoleBinding ───────► Role         (namespaced: permissions within ONE namespace)
ClusterRoleBinding ► ClusterRole  (cluster-wide, or reusable across namespaces)

Role/ClusterRole = a set of RULES: "these VERBS on these RESOURCES"
Bindings are ADDITIVE and there is NO deny — you grant only what's needed.
```

## Role + RoleBinding の例

```yaml
# A Role: read-only access to Pods in the "app" namespace
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: app
  name: pod-reader
rules:
  - apiGroups: [""]
    resources: ["pods", "pods/log"]
    verbs: ["get", "list", "watch"]
---
# Bind that Role to a ServiceAccount
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: app
  name: read-pods
subjects:
  - kind: ServiceAccount
    name: my-app
    namespace: app
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io
```

## ServiceAccount：Pod のための同一性

```text
A ServiceAccount is the IDENTITY a Pod uses to talk to the API server.
  → Every Pod gets one (the namespace "default" SA if unspecified).
  → A projected token is mounted into the Pod; RBAC decides what that token can do.
Best practice: give each workload its OWN SA with least-privilege RBAC,
and set automountServiceAccountToken: false when the Pod doesn't need API access.
```

```yaml
apiVersion: v1
kind: ServiceAccount
metadata: { name: my-app, namespace: app }
automountServiceAccountToken: false   # API 呼び出しが不要ならオプトアウトする
---
apiVersion: apps/v1
kind: Deployment
# ...
spec:
  template:
    spec:
      serviceAccountName: my-app       # この同一性で Pod を動かす
```

## 多層防御 — RBAC を超えて

```text
AUTH        → least-privilege RBAC; per-workload ServiceAccounts; audit access
NETWORK     → default-deny NetworkPolicies (Pods can't talk unless allowed)
WORKLOAD    → securityContext: runAsNonRoot, readOnlyRootFilesystem, drop capabilities
              seccomp profiles; Pod Security Admission (restricted) to enforce
SECRETS     → encryption at rest for etcd; external secret managers; tight RBAC on secrets
IMAGES      → scan images, use trusted registries, enforce with admission (e.g. policy engines)
API/etcd    → restrict & encrypt etcd; TLS everywhere; limit anonymous & cluster-admin access
SUPPLY CHAIN→ signed images, admission control (OPA/Gatekeeper, Kyverno)
```

```bash
kubectl auth can-i list pods --as=system:serviceaccount:app:my-app -n app
kubectl auth can-i --list -n app          # 現在のユーザーは何ができるか？
```

## なぜ重要なのか

cluster をセキュアにすることは senior の責務であり、ServiceAccount を伴う RBAC はその基盤なので、両方を理解することは必須のセキュリティ知識です。RBAC モデルは優雅で身につける価値があります。権限は**純粋に加算的で deny がなく**、許可された**リソース上の verb** を列挙する **Role**（namespace スコープ）または **ClusterRole**（cluster 全体）に **subject**（ユーザー、グループ、とりわけ **ServiceAccount**）を **binding** することで付与されます — つまり良いセキュリティは、拒否に頼るのではなく、各 workload が必要とするものだけを付与すること（**最小権限**）から生まれます。**ServiceAccount が Pod が API を呼ぶために使う同一性である**こと — すべての Pod がトークンを得ること、`default` SA が過剰権限のよくある罠であること、各 workload に自分専用の最小権限 SA を与えるべき（API アクセスが不要ならトークンの自動マウントを無効にする）こと — を理解することは、直接的に実践的で、実務での設定ミスの頻繁な原因です。決定的に、senior エンジニアは RBAC が**多層防御**の 1 つの層にすぎないと知っています。default-deny の **NetworkPolicy**、ハードニングされた **securityContext** 設定（非 root、読み取り専用 root filesystem、削ぎ落とした capability、seccomp）、**Pod Security Admission**、Secret のための**保存時暗号化**と外部マネージャ、image のスキャンと署名、admission controller（OPA/Gatekeeper、Kyverno）、そしてロックダウンされた etcd/API アクセス — これらすべてが合わさって cluster を守ります。Kubernetes cluster は、過剰権限の ServiceAccount 1 つや開いた NetworkPolicy 1 つが完全な侵害につながりうる価値の高い標的であるため、RBAC とより広いハードニングのツールキットの習熟は、production で cluster を安全に運用するための基礎です。

RBAC モデル

Role + RoleBinding の例

ServiceAccount：Pod のための同一性

多層防御 — RBAC を超えて

なぜ重要なのか

関連する質問