RBAC 如何与 ServiceAccount 配合工作，你如何保护一个 Kubernetes 集群？

Question

IT Interview Practice · Accepted Answer

**RBAC（Role-Based Access Control，基于角色的访问控制）**管理*谁能在 API 上做什么*。权限通过把 **subject**（用户、组、**ServiceAccount**）**绑定（binding）**到列出资源上允许 verb 的 **Role** 来授予。RBAC 是更广泛的集群加固策略中的一层。

## RBAC 模型

```text
SUBJECT (user / group / ServiceAccount)
   │  绑定于
   ▼
RoleBinding ───────► Role         (命名空间级：一个 namespace 内的权限)
ClusterRoleBinding ► ClusterRole  (集群级，或跨 namespace 可复用)

Role/ClusterRole = 一组规则：“对这些 RESOURCE 的这些 VERB”
绑定是叠加式的，且没有 deny —— 你只授予所需的权限。
```

## Role + RoleBinding 示例

```yaml
# 一个 Role：对 "app" namespace 中 Pod 的只读访问
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: app
  name: pod-reader
rules:
  - apiGroups: [""]
    resources: ["pods", "pods/log"]
    verbs: ["get", "list", "watch"]
---
# 把该 Role 绑定到一个 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
ServiceAccount 是 Pod 用来与 API server 通信的身份。
  → 每个 Pod 都有一个（未指定时用 namespace 的 "default" SA）。
  → 一个 projected token 被挂载到 Pod 中；RBAC 决定该 token 能做什么。
最佳实践：给每个 workload 它自己的 SA 并配以最小权限 RBAC，
当 Pod 不需要访问 API 时设置 automountServiceAccountToken: false。
```

```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        → 最小权限 RBAC；每 workload 一个 ServiceAccount；审计访问
NETWORK     → 默认拒绝的 NetworkPolicy（未允许则 Pod 之间不能通信）
WORKLOAD    → securityContext: runAsNonRoot, readOnlyRootFilesystem, 丢弃 capability
              seccomp profile；Pod Security Admission (restricted) 来强制执行
SECRETS     → etcd 静态加密；外部 secret 管理器；对 secret 的严格 RBAC
IMAGES      → 扫描镜像、使用可信 registry、用 admission 强制执行（例如策略引擎）
API/etcd    → 限制并加密 etcd；处处 TLS；限制匿名与 cluster-admin 访问
SUPPLY CHAIN→ 签名镜像、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          # 当前用户能做什么？
```

## 为什么这很重要

保护集群是高级职责，而带 ServiceAccount 的 RBAC 是其基础，因此理解两者都是必备的安全知识。RBAC 模型优雅且值得内化：权限是**纯叠加、没有 deny** 的，通过把 **subject**（用户、组，尤其是 **ServiceAccount**）**绑定**到列举资源上允许 **verb** 的 **Role**（命名空间级）或 **ClusterRole**（集群级）来授予——这意味着良好的安全来自只授予每个 workload 所需的权限（**最小权限**），而非依赖拒绝。理解 **ServiceAccount 是 Pod 用来调用 API 的身份**——每个 Pod 都有一个 token，`default` SA 是一个常见的过度授权陷阱，你应给每个 workload 它自己的最小权限 SA（并在不需要 API 访问时禁用 token 自动挂载）——非常实用，也是真实世界中配置错误的常见来源。至关重要的是，高级工程师知道 RBAC 只是**纵深防御**的一层：默认拒绝的 **NetworkPolicy**、加固的 **securityContext** 设置（非 root、只读根文件系统、丢弃 capability、seccomp）、**Pod Security Admission**、对 Secret 的**静态加密**和外部管理器、镜像扫描与签名、admission controller（OPA/Gatekeeper、Kyverno），以及锁定的 etcd/API 访问，全都组合起来保护一个集群。因为 Kubernetes 集群是高价值目标，单个过度授权的 ServiceAccount 或开放的 NetworkPolicy 就可能导致完全沦陷，精通 RBAC 和更广泛的加固工具箱是在生产中安全运维集群的基础。

RBAC 模型

Role + RoleBinding 示例

ServiceAccount：Pod 的身份

纵深防御 —— 超越 RBAC

为什么这很重要

相关问题