文章目录1. 认证与授权：两道门的本质区别1.1 用户身份的三种类型1.2 X.509 证书认证的工作原理2. RBAC 授权模型：四个核心对象2.1 Role 与 ClusterRole：作用域差异2.2 RoleBinding 的一个反直觉特性2.3 聚合 ClusterRole：可扩展的权限体系3. ServiceAccount：权限泄露的真实链路3.1 默认 SA 的隐性风险3.2 Bound Service Account Token：K8s 1.22+ 的改进3.3 最小权限配置的完整模板4. Pod Security Standards：PSP 废弃后的安全基线4.1 PSP → PSS 的本质变化4.2 三个安全级别的核心控制点4.3 Pod Security Admission 配置5. OPA Gatekeeper：策略即代码的准入控制5.1 Gatekeeper 在准入控制链中的位置5.2 ConstraintTemplate 与 Constraint 的两层架构5.3 Gatekeeper vs Kyverno：选型参考6. 整体安全层次与防御体系6.1 快速安全自检清单6.2 常见错误配置及修复7. 完整权限设计决策树总结核心问题：ServiceAccount 的权限泄露为什么是集群安全的最大隐患？1. 认证与授权：两道门的本质区别在讨论 RBAC 之前，有必要先厘清 Kubernetes 的**认证（Authentication）与授权（Authorization）**之间的边界，因为生产环境的大量安全事故恰恰源于对这两个概念的混淆。认证解决的是"这个请求者是谁"，授权解决的是"它能做什么"。两者的失效模式完全不同：认证失效意味着身份无法验证（通常直接返回 401），授权失效则意味着身份合法但权限越界（返回 403）。Kubernetes 的请求处理链路：失败成功401 未认证通过403 无权限通过拒绝通过客户端请求TLS 握手拒绝连接认证 Authentication返回 401授权 Authorization返回 403准入控制 Admission返回 400/403API Server 执行操作写入 etcd1.1 用户身份的三种类型Kubernetes 的 API 请求主体分三类，底层认证方式截然不同：身份类型由谁管理认证方式典型用途User外部系统（LDAP/OIDC/证书）X.509 证书（CN 字段）/ OIDC Token人工操作、kubectlGroup外部系统聚合X.509 O 字段 / OIDC groups claim批量授权（如团队）ServiceAccountKubernetes API 原生管理Bearer Token（JWT）Pod 内进程访问 API关键差异：User 和 Group 在 Kubernetes 中没有对应的 API 对象，无法通过kubectl get user查询。ServiceAccount 是 Kubernetes 原生资源，每个命名空间创建时会自动生成一个名为default的 ServiceAccount。1.2 X.509 证书认证的工作原理kubectl 使用的 kubeconfig 中的证书认证方式，由 API Server 的--client-ca-file参数指定 CA 证书路径。证书中的字段与 Kubernetes 身份的映射关系：证书 CN（commonName） → Kubernetes 用户名（Username） 证书 O（organization） → Kubernetes 组（Group）admin 用户的证书通常配置为：CN=kubernetes-admin O=system:masterssystem:masters组被硬编码绑定到cluster-adminClusterRole，这意味着拥有 system:masters 证书的用户绕过了 RBAC 检查。这是 kubeadm 初始化集群后 admin.conf 权限如此敏感的根本原因。2. RBAC 授权模型：四个核心对象Kubernetes RBAC 建立在四个 API 对象之上：主体 Subject权限绑定权限定义被引用被引用被引用授权给授权给授权给授权给授权给授权给Role命名空间级别ClusterRole集群级别RoleBinding命名空间级别