K8s 安全模型总览

摘要：本文面向生产 SRE / 平台工程师，建立 Kubernetes 安全模型的整体心智模型，明确认证（AuthN）、授权（AuthZ）、准入控制（Admission）与运行时防护四道防线各自的职责边界与失败模式，并给出后续 7 篇细分文章的导航。适用版本：Kubernetes v1.28+。

适用版本与前提

• Kubernetes：v1.28+（PSA 在 v1.25 即 GA；下文细分文章会标注各自版本门槛）
• 读者需了解 kubectl、Pod / Namespace / ServiceAccount 基本概念
• 本文是分类索引，不展开命令细节；具体落地见各子文

为什么需要分层安全模型

Kubernetes 本身没有"一个开关管全部安全"。它的安全能力是按请求生命周期分阶段落地的：一个 API 请求从客户端发出，到最终在节点上运行容器，会依次经过 认证 → 鉴权 → 准入控制 → 运行时约束 四道防线。每一道防线只解决一类问题，也因此都有各自的"管不到"的盲区。理解这些边界，才能避免把"我配了 RBAC"误当成"集群安全了"。

心智模型

安全不是单点功能，而是纵深防御（defense in depth）。任何一道防线失效，其他防线应当仍能提供保护。生产环境的目标不是追求某层"绝对安全"，而是让任意单点失效都不会直接导致集群沦陷。

四道防线与职责边界

1. 认证（Authentication）：你是谁

认证解决"这个请求来自哪个身份"。Kubernetes 支持多种认证器：客户端证书、bearer token（ServiceAccount Token、OIDC）、Webhook Token、bootstrap token 等。API server 把请求映射为一个 User、Group 或 ServiceAccount 身份。

• 边界：认证只确认身份，不决定"能做什么"（那是鉴权的事）。没有认证器通过时，身份为 system:anonymous，通常被 RBAC 拒绝。
• 失败模式：长期有效的静态 token（如 Legacy ServiceAccount Secret）泄漏即失控；OIDC 证书过期导致 CI 全部失败。详见 ServiceAccount 与 Token 管理。

2. 鉴权（Authorization）：你能做什么

Kubernetes 默认使用 RBAC（rbac.authorization.k8s.io）。权限纯累加（没有 deny 规则），通过 Role / ClusterRole + RoleBinding / ClusterRoleBinding 授予。除 RBAC 外还有 Node Authorizer、ABAC（已废弃）、Webhook 模式。

• 边界：RBAC 只在 API server 上生效，对节点上已运行的容器、对 etcd 直接访问、对 kubelet 端口无约束力。
• 失败模式：escalate / bind / impersonate 动词滥用导致提权；RoleBinding 到 default ServiceAccount 造成越权。详见 RBAC 权限模型实战。

3. 准入控制（Admission Control）：对象长什么样

准入控制器在对象被持久化前拦截请求，可校验（validating）或变更（mutating）。内置包括 PodSecurity、ResourceQuota、LimitRanger、NodeRestriction 等；外部可通过 ValidatingAdmissionPolicy（CEL）或 Webhook 扩展。

• 边界：准入只看对象本身，不感知运行时真实行为；Webhook 自身高可用直接影响 API 可用性（webhook 不可用时默认 deny 或 fail-open，取决于配置）。
• 失败模式：OPA/Gatekeeper 或 Kyverno webhook 宕机导致全集群无法创建资源。详见 Pod Security Admission 与 OPA/Gatekeeper。

4. 运行时约束（Runtime）：容器能干什么

即使请求通过了前三关，容器真正能做什么由 SecurityContext（UID、capabilities、seccomp、readOnlyRootFilesystem 等）、容器运行时（containerd/CRI-O）、节点内核（AppArmor、SELinux）共同决定。

• 边界：这是最后一道、也是离攻击面最近的一道。但它无法约束 API 层面的越权。
• 失败模式：runAsNonRoot 未设导致容器以 root 运行；capabilities 过大导致容器逃逸。详见 SecurityContext 安全上下文。

供应链与多租户视角

除请求生命周期外，安全还有两条横向主线：

• 供应链安全：镜像来源、签名与验证、SBOM。镜像在进入集群前就应被签名，在准入时验证。见 供应链安全与镜像签名。
• 多租户隔离：在共享控制面下，用 Namespace + RBAC + NetworkPolicy + ResourceQuota + PSA 组合实现软隔离，或用 vCluster / 独立集群实现硬隔离。见 多租户隔离方案。

生产落地清单

落地优先级建议

1. 关闭匿名访问、启用审计日志。
2. 每个 workload 用独立 ServiceAccount，关闭不必要的 token 自动挂载。
3. 全集群启用 PSA restricted 或至少 baseline（enforce + warn）。
4. 用 OPA/Gatekeeper 或 Kyverno 补 RBAC 覆盖不到的"对象级"策略（镜像仓库白名单、禁止 :latest）。
5. 镜像签名 + 准入验证。
6. 多租户用 NetworkPolicy 默认拒绝 + ResourceQuota 防资源耗尽。

常见坑

不要把 RBAC 当成全部

很多团队认为"配好 RBAC 就安全了"，但 RBAC 不约束：节点上容器的实际权限、Pod 间网络、镜像来源、resource 配额。纵深防御要求四道防线都到位。

不要在 Webhook 失败时 fail-open

第三方准入 Webhook（Gatekeeper/Kyverno）若配置 failurePolicy: Ignore，在 webhook 不可用时请求会被放行，等于临时关闭了安全策略。生产建议 failurePolicy: Fail（影响可用性）或对非关键策略用 Ignore 并配告警。[版本相关：具体策略的 failurePolicy 需结合可用性取舍评估]

参考资料

• Kubernetes 官方文档 - Securing a Cluster，访问日期：2026-10-08。
• Kubernetes 官方文档 - Authenticating，访问日期：2026-10-08。
• Kubernetes 官方文档 - Authorization Overview，访问日期：2026-10-08。
• Kubernetes 官方文档 - Admission Controllers，访问日期：2026-10-08。
• Kubernetes 官方文档 - Pod Security Standards，访问日期：2026-10-08。