今天，如果你正在运行Kubernetes，你知道，安全是不是“内置”。为了确保您的集群，您必须在额外的控制配置，添加或建立。有些是Kubernetes的一部分，是基于角色的访问控制（RBAC），但其他的最佳实践包括指定受信任的存储库已知良好的容器中，然后在运行时扫描工具层次感为好。
但现实是，在Kubernetes，你可以做所有这些事情“正确的”，但一切仍可能会出错。您RBAC控件可以是有一定作用，你只能使用可靠且签名的Image，用户可以无尽扫描你的容器中 ，你的集群会断裂或破坏。换句话说，即使是干净且可信的Image，如果部署不正确，也会导致集群配置错误——从而导致返工、停机或（更糟糕的）数据丢失的风险。
然而，Kubernetes 的一个美妙之处在于它提供了一种优雅的控制来防止正确的事物以错误的方式行事。Kubernetes准入控制（admission control）允许开发者直接在其集群上执行安全策略，以管理和控制什么可以为了被部署到极限的危险，并防止以往出现的许多安全问题。
。例如，此类策略可能会阻止软件以 root 身份运行，防止来自 Web 的有害入侵，或确保新部署的容器无法从现有的暴露于 Internet 的工作负载中窃取流量——所有潜在的安全问题，如 RBAC 或运行时安全性工具无法解释。事实上，准入控制不仅功能强大而且正迅速成为确保Kubernetes的强制性工具。
RBAC的局限性
要理解为什么开发人员需要准入控制，让我们先来看看RBAC的局限性，值得信赖的存储库和运行时工具。这需要我们来看看这些工具的源：发展预云时代。在传统的IT安全模式，核心因素，开发商对其进行评价：
- 身份与网络 - 谁可以访问什么？
- 已知的漏洞 - 这已知漏洞可以在我们的环境中执行？
在 Kubernetes 中，这些概念非常接近于 RBAC 和容器中的代码扫描；在运行之前和运行期间。很自然，具有安全意识的团队会采用这些工具作为保护集群的第一道防线。但在完全由软件定义的环境中，借助 Kubernetes 允许的精细控制，传统方法本身在这些云原生环境中不可避免地存在差距。
以RBAC为例。RBAC 控制谁或什么可以将代码放入您的集群；通常，这些权限是通过 CI/CD 管道自动化的。理论上，这意味着只有受信任的参与者才能将受信任或批准的Image镜像放入您的集群。但是，通过 CI/CD 流程大规模自动化的人为错误会带来大规模问题。而且，由于Kubernetes API是基于意图和要求YAML的任意块的检查，RBAC实际上提供远低于在Kubernetes比其他系统的控制。
可信库，同时，保证镜像永不来自未知或不可信来源。它们包含已批准的镜像，通常带有已扫描漏洞的代码。然而，正如我们将看到的，即使是可信的镜像也可能以错误的方式部署。
最后，运行时工具允许您监控部署的环境。这些工具有助于检测异常活动、监控容器之间以及外部客户端和服务之间的通信，以及发现新发现的漏洞。尽管如此，您的运行时环境可以完全干净、无漏洞，并且仍然会遭到破坏。
在实践中，传统工具无法解决天生的云问题。例如，即使是一个干净且可信的镜像，如果部署不正确，也可能被恶意行为者用来横向移动到其他容器。或者，它可以简单地以不应该的方式与互联网交谈。这些“干净的形象，糟糕的结果”的情况是多种多样的：
由正确的管道部署并持续扫描的干净镜像可以：
- 允许意外从互联网出口；
- 无意中扩展以捕获 CPU 资源并使其他进程崩溃；
- 以特权运行，使其成为可妥协的、支持横向移动的风险；
- 与其命名空间外的容器“对话”并放置数据和风险；
- 命名为“latest”，防止集群回滚；
- 还有很多很多。
Kubernetes 准入控制提供了一种方法来阻止这些不想要的场景中的每一个——您需要做的就是定义允许正确的规则，停止不正确的规则。更具体地说，您可以使用准入控制器来防止错误配置导致问题。这是因为准入控制器是“有目的的瓶颈”，可让您拦截对 Kube API 的请求并对其实施安全策略，然后再将它们作为对象部署到 Kubernetes 中。
由 Kubernetes 准入控制赋予的权力
我们从开发人员社区听到了很多关于 Kubernetes 准入控制的消息，因为我们的开源策略引擎Open Policy Agent (OPA)出人意料地最受欢迎的用例之一就是作为 Kubernetes 准入控制器。OPA 非常适合准入控制，因为它允许您将企业安全策略（通常存储在 wiki、PDF 或人们的头脑中）转换为策略即代码，并通过准入控制 Webhook 直接在集群上实施它们。
无论您选择哪种控制器（即使它只是自定义代码），准入控制都可用于防止各种 Kubernetes 错误配置。例如，您可以创建策略以：
- 防止容器以 root 身份运行（只能以“非 root”身份运行）；
- 仅部署标记为发布的镜像；
- 确保正确的标签/标签；
- 仅公开某些 IP 和端口；
- 仅挂载允许的文件系统。
同样重要的是，您还可以为容器周围的配置实施策略。例如，您可以控制以下因素：
- 自动复制。
- 阻止公众进入。
- 安全。
- 最低可靠性（例如，要求您运行三个副本）。
然而，在准入控制的世界中，可能性（或限制）是无穷无尽的：您可以为在 Kubernetes 上运行的任何软件的配置编写策略。关键在于，使用 Kubernetes 准入控制，您可以实施基本上保证安全性、合规性和操作安全性的护栏——通过在错误配置发生之前防止它们。