Kubernetes准入控制怎么做，决定了安全规则能否从文档要求变成自动执行。很多团队有安全规范，却依赖人工检查YAML，结果特权容器、root运行、hostPath挂载、不合规镜像和缺失资源限制仍然进入生产集群。准入控制的目标，是在资源创建或更新时及时拦截高风险配置。
这篇文章会把问题放在企业平台和生产环境中讨论，而不是只停留在单个命令或单项配置。你可以把它和Kubernetes安全、容器安全、云原生安全配合阅读，先建立整体判断，再回到具体场景设计实施步骤。
本文适用范围
本文讨论Kubernetes资源进入集群前的准入治理，重点包括Pod安全标准、安全上下文、镜像规则、OPA或Kyverno策略，以及例外流程设计。它不替代运行时检测，但可以显著减少高风险配置进入集群。
准入控制解决什么问题
准入控制可以检查Pod、Deployment、Ingress、Service和自定义资源是否符合平台规则。典型规则包括禁止特权容器、限制hostNetwork、限制hostPath、要求非root运行、要求资源限制、限制镜像来源和要求指定标签。
Pod安全标准怎么用
Pod安全标准提供特权、基线和受限几个级别，适合建立通用安全底线。生产环境通常不应允许特权级别随意使用，受限级别适合安全要求较高的命名空间，但需要提前评估兼容性。
OPA策略适合什么场景
OPA和Rego适合表达更细的组织规则，例如不同命名空间允许不同镜像仓库、特定团队可以申请GPU、生产环境必须设置资源限制、敏感命名空间禁止外部LoadBalancer。策略越复杂，越需要测试和版本管理。
例外流程不能缺失
没有例外流程的准入控制容易被绕过，例外过多又会失去治理效果。建议对例外设置申请人、原因、有效期、审批人和审计记录，并定期清理过期例外。
落地顺序
先从只提示不拦截开始，收集影响范围；再对高风险配置启用拦截；最后把策略纳入CI/CD和集群准入双重检查。这样可以减少一次性强制策略导致的大面积发布失败。
常见问题
准入控制会不会影响发布效率？
如果直接强拦截可能影响发布，因此建议先审计和提示，再逐步对高风险规则启用拦截。
OPA和Pod安全标准怎么选？
Pod安全标准适合作为通用底线，OPA适合表达组织自定义规则，两者可以配合使用。
准入控制能发现运行时攻击吗？
不能。准入控制主要防止不合规配置进入集群，运行时攻击还需要日志、监控和运行时检测能力。
策略应该由谁维护？
建议平台团队和安全团队共同维护，业务团队参与例外和兼容性评估。
小结
Kubernetes准入控制怎么做的关键，不是把某个功能单独做出来，而是把规则、流程、指标和复盘机制连接起来。对平台团队来说，先明确边界和目标，再逐步自动化，通常比一次性追求复杂能力更稳妥。后续也可以回到相关标签页继续查找更多文章，形成从概念、实践到选型的完整路径。
转载请注明出处：https://www.cloudnative-tech.com/p/8390/
