Pod 安全性标准的三个策略
- Privileged（特权）：提供完全不受限制的政策。这种配置文件允许已知的权限提升。
- Baseline（基线）：提供最低限度的限制性措施，同时防止已知的权限提升。适用于非关键应用程序的应用程序运营商和开发人员。
- Restricted（受限）：遵循当前的 Pod 硬化最佳实践，但可能限制兼容性。适用于安全关键应用程序的操作员和开发人员。
使用 Pod 安全性标准的技巧
- 配置 Pod 安全准入控制器：通过在命名空间中设置相关的标签来配置 Pod 安全准入控制器，以选择执行、审计或警告模式，并指定特定的安全级别（Privileged、Baseline 或 Restricted）。
- 审计和警告模式：启用审计和警告模式以收集有关 Pod 的重要安全洞察，而不会破坏现有工作负载。
- 特权安全配置文件的使用：在仅受信任用户执行关键基础设施工作负载的有限用例中使用。
- 基线安全配置文件的使用：适用于希望在不使环境过于复杂的情况下确保其安全的应用程序运营商和非关键应用程序的开发人员。
- 受限安全配置文件的使用：最安全的选项，强制执行当前的 Pod 硬化最佳实践，特别适用于处理敏感信息的容器化工作负载。
使用案例
假设我们有一个名为 "my-namespace" 的命名空间，并希望检查它是否符合最新的基线版本的 Pod 安全性标准。我们可以使用以下命令设置警告：
代码语言：javascript复制kubectl label --overwrite ns my-namespace
pod-security.kubernetes.io/warn=baseline
pod-security.kubernetes.io/warn-version=latest
如果我们想要执行 "baseline" 安全级别，同时在日志中通知审计安全级别以查看是否可以达到 "Restricted" 级别标准，我们可以这样设置：
代码语言：javascript复制kubectl label --overwrite ns my-namespace
pod-security.kubernetes.io/enforce=baseline
pod-security.kubernetes.io/enforce-version=latest
pod-security.kubernetes.io/audit=restricted
pod-security.kubernetes.io/audit-version=latest
通过这种方式，组织可以确保符合行业标准的安全要求，同时保护免受潜在的权限提升和其他恶意活动的影响。利用 Pod 安全性标准，通过 Pod 安全准入控制器简化了开发过程，同时保护 Kubernetes 集群中运行的任何工作负载。
