Kubernetes RBAC 与 Pod 安全标准实战：把谁能动、怎么跑握在自己手里

Kubernetes 集群里，权限管理往往是"看着不起眼、出事才追悔"的部分：很多人图省事用管理员账号（cluster-admin）干所有事，结果一个被攻破的 CI 令牌、一次误操作的 kubectl 就能把整个集群掀翻。K8s 的权限体系由 RBAC（基于角色的访问控制）与 Pod 安全标准（PSS，Pod Security Standards）共同构成：RBAC 管"谁能对集群做哪些操作"，PSS 管"允许以什么样的安全配置运行 Pod"。这篇讲清二者解决什么、RBAC 的 Role/ClusterRole/Binding 怎么配、Pod 安全怎么收，以及常见坑与边界。

一、RBAC 与 Pod 安全解决什么：把"谁都能动集群"收成"最小够用"

K8s 里权限失控的典型表现：所有人共用 cluster-admin（能删任何命名空间、能读所有 Secret、能改集群配置）；CI 或监控用的 ServiceAccount 给了集群级权限，一旦令牌泄露等于交出整个集群；Pod 用 root 跑、带特权、挂宿主目录，被攻破后容器就变宿主跳板。RBAC 解决"操作权限"：按角色（Role/ClusterRole）给用户或 ServiceAccount 授权最小必要的能力（能看哪些、能改哪些、在哪个命名空间），把"谁都能动"收成"各自只够用"。Pod 安全标准（PSS）解决"运行姿态"：分三个档（privileged/baseline/restricted）约束 Pod 能不能以 root/特权/挂宿主文件系统等危险方式运行，把"容器里乱跑"收成"默认受约束"。二者合起来，一个管"操作者"，一个管"运行者"，是集群安全的地基。

它和前面聊的容器加固/镜像签名是协同的：镜像签名管"拉的是不是可信的"，容器加固管"单个容器怎么受限"，而 RBAC + Pod 安全管"整个集群的权限与运行边界"——越往上越到"平台层"的收口。

二、RBAC 怎么配：Role/ClusterRole + RoleBinding/ClusterRoleBinding

RBAC 的最小骨架是两组对象：权限定义（Role 限命名空间内 / ClusterRole 集群级）与授权绑定（RoleBinding 把角色绑给主体/限命名空间内 / ClusterRoleBinding 集群级）。实践套路：先"最小够用"地声明一个角色（例如"只能在某命名空间看 Pod 和日志"），再把它绑给需要的用户或 ServiceAccount——给 CI 只开它要的、给监控只开只读、给人只开自己负责的命名空间。别用 cluster-admin 图省事，出事的代价远大于配置成本。

# 一个"只读某命名空间"的 Role + RoleBinding 示例
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata: { name: ns-reader, namespace: myapp }
rules:
  - apiGroups: [""]
    resources: ["pods", "pods/log", "services", "configmaps"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata: { name: ci-reader, namespace: myapp }
subjects:
  - { kind: ServiceAccount, name: ci-bot, namespace: myapp }
roleRef: { kind: Role, name: ns-reader, apiGroup: rbac.authorization.k8s.io }

# 验证某主体到底有什么权限（排障利器）
kubectl auth can-i list pods -n myapp --as=system:serviceaccount:myapp:ci-bot

RBAC 的坑主要在三处：一是"权限给太宽"（用 ClusterRole 绑到所有命名空间、`*` verbs）——坚持"最小够用 + 命名空间收口"；二是"配完不验证"——用 `kubectl auth can-i` 实测"能不能、不能什么"，别凭想象；三是"ServiceAccount 泛滥"——每个应用/CI 都建独立 SA 并最小授权，别共用一个高权限 SA。

三、Pod 安全标准：三个档位 + 准入控制把"危险运行"挡在外面

Pod 安全标准（PSS）把 Pod 的安全姿态分为三档：privileged（无限制，默认继承宿主能力）、baseline（限制最明显的危险项：禁 root？不——是禁特权容器、禁 hostPID/hostNetwork、禁挂宿主目录等）、restricted（最严：要求 non-root、只读根文件系统、丢弃所有能力等）。落地方式是"准入控制"：在命名空间上打标签（如 `pod-security.kubernetes.io/enforce: restricted`），让 API Server 拒绝不符合档位的 Pod 创建——不满足就直接报错，从源头挡掉危险运行。收口原则：能 restricted 的 restricted（业务应用），必须特权的（如部分网络组件）单独开 privileged 命名空间，别一刀切。

# 给命名空间打上"强制 restricted"标签，不符合的 Pod 创建被拒
kubectl label ns myapp \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/audit=restricted \
  pod-security.kubernetes.io/warn=restricted

# 一个符合 restricted 的容器片段（non-root + 只读根 + 丢权限）
securityContext:
  runAsNonRoot: true
  readOnlyRootFilesystem: true
  capabilities: { drop: ["ALL"] }

PSS 的坑：一是"一刀切导致合法 Pod 被拒"——有些镜像本来就以 root 起（如部分中间件），先看镜像再定档位，或给特殊命名空间开 baseline；二是"只 enforce 不 audit/warn"——先开 warn/audit 观察"哪些会违规"，再逐步 enforce，别上来就把合法服务全拒了；三是"忘了容器自身 securityContext"——PSS 管准入，容器还得自己声明 non-root/只读/丢能力（前面聊过），两者配合才完整。

四、常见坑：cluster-admin 泛滥、RBAC 与审计脱节、PSS 误伤、Secret 权限

集群权限管理四个坑要尤其防。一是"cluster-admin 泛滥"：admin 应该给极少数人，且配审计，别让所有人、所有 CI 都挂着它。二是"RBAC 配了但没审计"：授权列表一年不看，离职/换岗的人权限还在、无用的 SA 还挂着高权限——定期盘点（kubectl get rolebinding/role）与回收。三是"PSS 误伤"：想收权限却把正常服务拒了（见上），用 warn/audit 过渡 + 按命名空间分级。四是"Secret 权限"：能读 Secret 等于拿到集群内所有凭据，RBAC 里对 secrets 的 get/list 要单独、最小授权，别放进"通用只读"角色里。

# 排障 SOP：权限相关问题的快速定位
#   1) "没权限" → kubectl auth can-i 确认到底缺哪项，别瞎猜
#   2) "权限太大" → 查该主体绑了哪些 RoleBinding/ClusterRoleBinding
#   3) "Pod 建不起来" → 看是不是 PSS 准入拒绝（describe 看 Events）
#   4) "谁在动集群" → 配合审计日志（K8s audit log）留痕

把它当排障 SOP：先"auth can-i 实测权限边界"，再"查绑定关系找谁被授了什么"，后"用审计日志确认实际动作"。权限管理最怕"凭感觉以为没权限/以为只有自己能用"——一切以实测与审计为准。

五、边界：RBAC/PSS 管"集群内权限与运行边界"，管不了"外部与业务层"

这层的边界要认清：RBAC 与 Pod 安全管的是"集群内部的授权与运行姿态"，管不了"集群入口之外"的威胁（前面聊的网络策略、WAF/限流、镜像签名各管一段）也不替代"业务数据安全"（数据库备份、加密仍要做）。其次，RBAC 授权是"逻辑权限"，真正的威胁是"拿到高权限令牌"——密钥管理（Secret 加密、令牌轮换、最小签发）与 RBAC 要配合，别只盯着授权模型忘了凭据本身。最后，安全配置越严，合规越细，但排障与运维复杂度也越高——按"集群谁在用、跑什么"来定档位，别为了"看起来很安全"把所有服务都塞进 restricted 然后把维护成本拉爆。

把 RBAC 与 Pod 安全放回自托管整体：它是 K8s 的"权限与运行边界"地基——RBAC 管"谁能对集群做什么"，PSS 管"允许以什么姿态跑 Pod"。落地要点：给用户/CI/监控各自建最小 Role/ClusterRole + 命名空间收口的绑定，用 `kubectl auth can-i` 实测；用命名空间标签 + enforce/warn/audit 分级推行 Pod 安全标准，容器自身配合 non-root/只读/丢能力；防住 cluster-admin 泛滥、授权不审计、PSS 误伤、Secret 权限过大四坑，并配审计日志；认清它管集群内授权与运行边界、管不了入口与业务数据。当你把"操作者最小够用、运行者默认受限、凭据妥善管理"这条链做成，K8s 集群才真正敢把关键工作负载放进去。

结语

Kubernetes RBAC 与 Pod 安全标准的价值，是把"谁都能动集群、Pod 爱怎么跑怎么跑"收成"操作者最小够用、运行者默认受限"的收口：RBAC 用 Role/ClusterRole + Binding 管"谁能做什么"，PSS 用 privileged/baseline/restricted 三档 + 命名空间准入管"允许以什么姿态跑 Pod"。落地要点：给每个主体最小授权并命名空间收口，用 auth can-i 实测；用 enforce/warn/audit 分级推行 PSS，容器自身配 non-root/只读/丢能力；防住 cluster-admin 泛滥、授权不审计、PSS 误伤、Secret 权限过大四坑，并配审计留痕；认清它管集群内授权与运行边界、不替代入口防护与数据安全。当权限与运行边界都被收口，K8s 自托管才算真正把"谁能动、怎么跑"这两件事握在了自己手里。