Kubernetes Admission Control的力量：为什么基于角色的访问控制还不够

今天，如果你正在运行Kubernetes，你就会知道安全性不是“内置的”。为了保护集群，你必须配置，添加或构建其他控件。其中一些控件是Kubernetes的一部分，例如基于角色的访问控制（RBAC），为容器指定受信任的镜像仓库，以及在容器运行时的扫描工具中进行分层。

在Kubernetes中，即使你可以“正确”地完成所有这些操作，但仍然会出错。虽然你可以使用安全性比较高的RBAC控件，只使用受信任的和已签名的镜像，并且可以扫描容器直到运行结束，但是集群仍然可能攻击会被或被破坏。

这就需要Kubernetes Admission Control了，它允许开发人员直接在其集群上实施安全策略，以控制可以部署的内容，以限制风险并防止出现许多安全问题。例如，此类策略会阻止容器以root用户身份运行，阻止来自Web的有害入侵等。

实际上，Admission Control不仅功能强大，而且正迅速成为确保Kubernetes安全的必备工具。像RBAC，受信任的镜像仓库和容器运行时这样的策略，尽管本身就是美好而必要的，但还远远不够。

Kubernetes需要Admission Control

要了解为什么开发人员需要Admission Control，让我们首先看一下RBAC，受信任的镜像仓库和容器运行时工具的局限性。首先这些工具的来源是：云发展之前的时代。在传统的IT安全模型中，开发人员评估的核心因素是：

• 身份和网络-谁可以访问什么？
• 已知漏洞-在我们的环境中可以执行哪些已知漏洞？

在Kubernetes中，这些概念非常接近RBAC和容器中的代码扫描。具有安全意识的团队会采用这些工具作为保护集群的第一道防线，但是在完全软件定义的环境中，借助Kubernetes允许的精细控制，传统方法本身在这些云原生环境中不可避免地存在差距或局限性。

RBAC

以RBAC为例。RBAC控制着谁可以将代码放入你的集群，通常，这些权限是通过CI/CD流水线自动执行的。从理论上讲，这意味着只有受信任的参与者才能将受信任或已批准的镜像放入集群中。但是，借助CI/CD进行大规模自动化会带来大量问题。而且，由于Kubernetes API是声明式的，并且需要检查任意YAML块，因此RBAC实际上在Kubernetes中提供的控制要比其他系统少得多。

受信任的镜像仓库

同时，使用受信任的镜像仓库，可确保镜像永远不会来自未知或不受信任的存储库。其中,镜像中的代码漏洞已被扫描和处理。但是，正如我们看到的，即使是受信任的镜像也可能会以错误的方式进行部署。

容器运行时工具

最后，容器运行时工具允许你监视部署的环境。这些工具可以帮助检测异常活动，监视容器之间以及外部客户端和服务之间的通信，以及发现新的漏洞。尽管如此，你的容器运行时环境也会遭到破坏。

实际上，传统工具无法解决云计算中的问题。例如，恶意攻击者甚至可以使用配置错误且受信任的镜像来侵入其他容器。这些“干净的镜像，不良的结果”场景是多种多样的：

• 网络出口被暴露；
• 捕获CPU资源并使其他进程崩溃；
• 特权运行(root身份运行容器)；
• 与其命名空间之外的容器“对话”，并放置数据和风险；
• 被打标签为“latest”并防止集群回滚

Kubernetes Admission Control提供了一种方法来阻止这些不良场景中的每一种。你要做的就是定义正确的规则，阻止不正确的规则。更具体地说，你可以使用Admission Control防止配置错误，以免引起问题。

这是因为Admission Control可让你拦截Kube API的请求并对其执行安全策略，然后再将它们部署为Kubernetes中的对象。

Kubernetes Admission Control所赋予的权力

我们从开发人员社区中听到了很多有关Kubernetes Admission Control的信息，其中开源策略引擎Open Policy Agent（OPA）是最受欢迎的用例之一。OPA非常适合于“Admission Control”，因为可以将安全策略转换为代码(policy-as-code)，并通过Admission Control Webhook直接在集群上实施它们。

无论你选择哪种控制器（即使只是自定义代码），Admission Control都可以用来防止Kubernetes的各种错误配置。例如，你可以创建策略以：

• 防止容器以root身份运行（只能以“非root”身份运行）；
• 仅部署标签为release的镜像；
• 确保镜像使用正确的标签；
• 仅公开某些IP和端口；
• 仅挂载允许的文件系统。

同样重要的是，你也可以为容器的配置实施策略。例如，你可以控制以下因素：

• 自动复制
• 网络入口的控制
• 密钥
• 最低可靠性（例如，要求你运行三个副本）

但是，在“Admission Control”世界中，可能性（或限制）的范围是无限的：你可以为Kubernetes上运行的任何软件的配置编写策略。关键是，使用Kubernetes Admission Control，你可以通过减少出错或故障，来保证安全性，和操作的合规性。

译文链接：https://thenewstack.io/the-power-of-kubernetes-admission-control-why-role-based-access-control-isnt-enough/