Pod 安全标准分为 Privileged、Baseline 和 Restricted 三级，逐级强化安全控制，通过 Pod Security Admission 或 OPA Gatekeeper 等机制实施，建议生产环境按需选用并持续审计配置。
Kubernetes 的 Pod 安全标准（Pod Security Standards）是一组推荐的安全策略，用于限制 Pod 的行为，防止其以不安全的方式运行。这些标准定义了不同级别的安全控制，帮助集群管理员确保工作负载符合最小权限原则和安全最佳实践。
三种 Pod 安全标准级别
Pod 安全标准分为三个递进的级别，每个级别对 Pod 的配置提出更严格的要求：
- Privileged（特权级）：允许所有安全相关的配置，包括以 root 用户运行、挂载主机文件系统、使用 hostNetwork 等。这个级别几乎没有限制，适用于需要完全控制节点的可信系统组件。
- Baseline（基线级）：禁止明显的危险行为，例如不允许特权容器、不允许以 root 身份运行进程、限制 capabilities 的使用。大多数普通应用应能在此级别下运行。
- Restricted（受限级）：最严格的一层，基于强化的 Pod 配置要求，比如必须启用 seccomp 或 AppArmor、强制使用非 root 用户、禁止 hostPort 使用等。它遵循 RuntimeDefault 或 pod-security-admission 等机制来执行。
如何实施 Pod 安全标准
虽然原始的 PodSecurityPolicy（PSP）已被弃用，但可以通过以下方式实现类似效果：
- 使用 Pod Security Admission（PSA）：Kubernetes 内置的准入控制器，在命名空间上设置标签即可自动校验 Pod 是否符合指定级别。
- 结合 OPA Gatekeeper 或 Kyverno：这些策略引擎支持更细粒度的规则定义，并可扩展默认标准之外的自定义策略。
- 为命名空间打上相应安全级别的标签，例如
pod-security.kubernetes.io/enforce: baseline来强制执行基线策略。
实际应用建议
在生产环境中，推荐逐步提升安全等级：
- 新项目从 Restricted 开始设计，确保默认安全。
- 遗留应用先运行在 Baseline，再逐步修复不符合项。
- 避免随意使用 Privileged，仅限 kube-system 等核心组件。
- 定期审计 Pod 配置，利用 kubectl 插件或 CI/CD 检查工具提前发现问题。
基本上就这些。Pod 安全标准不是一成不变的规则，而是一种可落地的安全框架，关键是根据业务需求选择合适的级别并持续维护。不复杂但容易忽略细节，比如用户 ID 设置或 capabilities 控制，往往成为突破口。
