Kubernetes 安全策略实践

要解决什么问题

多租户或生产级 Kubernetes 集群里，默认的「全通」网络、过宽的 ServiceAccount 权限、以及特权容器，往往比应用 bug 更容易变成横向移动入口。单靠某个 Helm chart 或零散 YAML 很难系统对齐 CIS Kubernetes 基准、NIST 里常见的分段、最小权限和审计要求。

本技能面向「把策略写进集群、并能验证是否生效」这类工程任务，而不是泛泛的安全概念科普。

技能如何帮你落地

围绕 纵深防御，技能把实现路径拆成几块可操作的模块：

• Pod 安全标准：在命名空间级别选用 Privileged / Baseline / Restricted，并结合 Pod 安全上下文（非 root、只读根文件系统、丢弃 capabilities）约束工作负载。
• 网络策略：从「默认拒绝」起步，再按需放行前端→后端、DNS 等路径；可参考 assets/network-policy-template.yaml 里的模板思路。
• RBAC：区分 Role / ClusterRole 与绑定关系，按最小权限给服务账户授权；模式说明见 references/rbac-patterns.md。
• 准入与执行：用 OPA Gatekeeper（ConstraintTemplate + Constraint）或同类机制把策略变成集群级门禁。
• 服务网格（可选）：在 Istio 场景下配置 PeerAuthentication（mTLS）与 AuthorizationPolicy。

操作方式强调：先明确目标、约束和输入，再按最佳实践给出可执行步骤与验证方法；需要完整示例时可对照 resources/implementation-playbook.md 与清单模板。

适用边界

• 任务与 K8s 安全策略无关，或依赖本技能范围外的工具/领域时，不必启用。
• 文档中的 PodSecurityPolicy（PSP） 属于历史机制（集群版本较新时通常以 Pod Security Standards 与准入控制器为主）；实施前需对照你的 K8s 版本与现有准入栈（Gatekeeper / Kyverno 等）。
• NetworkPolicy 不生效、RBAC 权限被拒绝 等常见问题，技能会指向排查方向，但具体 CNI、API Server 审计配置仍依赖你的环境。

与 k8s-manifest-generator、gitops-workflow 搭配时，更适合把上述策略纳入清单生成与 GitOps 发布流程。