Skip to main content
Kubernetes 安全是一个纵深防御体系。本章按访问链路逐层讲解:谁能访问 API、Pod 能以什么权限运行、镜像从哪里来。

API 访问控制三段

每个发到 API Server 的请求都要经过三道关卡:
  1. 认证(Authentication):确认你是谁。支持客户端证书、Bearer Token、ServiceAccount Token 等方式。
  2. 授权(Authorization):确认你能做什么。生产环境一律使用 RBAC 模式。
  3. 准入控制(Admission):对请求对象做最后的校验和修改,例如 PodSecurityLimitRanger
任何一段失败,请求都会被拒绝。排查权限问题时按「认证 → 授权 → 准入」的顺序逐段定位。

ServiceAccount 与 Token

ServiceAccount 是 Pod 访问 API Server 的身份。每个 namespace 自带一个 default ServiceAccount。
Pod 中通过 serviceAccountName 指定身份:
不需要访问 API 的 Pod,建议设置 automountServiceAccountToken: false,减少攻击面。

RBAC 详解

RBAC 的核心是四个对象:

示例:给开发者开 namespace 只读权限

验证权限是否生效:
永远不要把 cluster-admin 绑定给普通用户或应用。权限最小化是第一原则。

Pod 安全

Pod Security Standards

Kubernetes 内置三档 Pod 安全标准,通过 namespace 标签启用准入控制:
  • privileged:不做任何限制,仅用于系统组件。
  • baseline:禁止已知的提权手段,兼顾兼容性。
  • restricted:最严格,强制非 root、只读根文件系统等最佳实践。

securityContext 常用配置

镜像安全

私有仓库 imagePullSecrets

镜像扫描(如 Trivy)与镜像签名(如 Cosign)应在 CI 流水线中完成,确保入集群的镜像无高危漏洞且来源可信。

安全清单小结

延伸阅读