Kubernetes安全三步谈：三种方法保护Kubernetes免受内部威胁

这是关于 Kubernetes 安全系列三篇文章中的第二篇。在上篇文章中我们分享了如何确保企业的 Kubernetes 集群免受 外部攻击 ，这篇文章中我们将分享三种保护 Kubernetes 免受 内部威胁 的方法，后续我们还想介绍如何处理资源消耗或 noisy neighbor 问题。

本质上讲，Kubernetes 集群是多用户的。因此，组织通常希望通过 RBAC（基于角色的访问控制）、逻辑隔离和网络策略来确保交叉通信受到保护。

像 Kubernetes 这样的容器编排系统将开发人员和运维人员（DevOps）更紧密地联系在一起，使团队更容易有效地相互协作。诚然，我们相信 DevOps 团队的大多数成员不会存在什么恶意企图，但是，组织仍然需要确保，如果应用程序之间存在交叉通信，并且如果有人编写了错误代码，我们能够将损失控制在最小。

01 基于角色的访问控制

减轻对容器的恶意威胁与保护物理服务器，这两者的策略不同。然而，无论系统管理员是在数据中心部署了多个服务器，还是在 Kubernetes 中部署了虚拟集群，基于角色的访问控制（RBAC）都是一项至关重要的安全举措。

Rancher Labs 的高级解决方案架构师 Adrian Goins 说，“在内部，你希望有某种基于角色的访问控制，遵循最低特权的规则。”Rancher Labs 为 Kubernetes 开发了一个完整的容器管理平台 Rancher。

“你只允许用户和服务账户访问他们需要访问的资源，而且访问权限只适用于他们需要做的任何事情。”这种访问控制向下扩展到无需使用 root 权限来运行容器进程。

Rancher 与 RBAC 的多个后端提供者交互，简化了 Kubernetes 用户的流程。例如，系统管理员可以部署 Rancher 并去到 authentication 选项卡，将其组织的 Microsoft Active Directory 数据导入到 Kubernetes 中。Rancher 会立即从 Activate Directory 中提取所有用户和组，这些组现在可以在角色中使用，然后应用于 Rancher 管理的所有集群。

通常情况下，管理员必须手动配置这些角色，并在每个集群中复制它们。对于一个拥有一到两个集群的组织来说，这可能不是什么问题，但是如果一个公司拥有数十个、数百个或更多集群，那么人为错误的可能性非常高。总有一些东西会遗漏，其后果可能是灾难性的。

通过 Rancher，管理员可以跨集群将角色集中化，drill down 以让用户访问只能执行特定任务的特定集群。如果有员工离职了，只需要停用 Active Directory 中他们的账户就行，一切都非常简单。完成此操作后，被停用的账户会立刻失去访问每个集群的权限。因为 Rancher 充当了每个集群的身份验证代理，管理员不再需要为部署集群所在的每个提供者提供或管理账户。

02 使用命名空间进行逻辑隔离

此外，部署到集群的应用应该使用命名空间，将资源进行逻辑隔离后，管理员可以给它们附加安全策略。命名空间可以给集群资源分段，并且包括它们所包含的 pod 的配额以及默认资源限制。尽管命名空间最初的目的是用于跨多个团队或项目的多用户环境，但现在它已经是公认的集群内的最佳标准实践了。

默认情况下，在 Kubernetes 中，没有任何东西可以阻止拥有容器的两个不同团队进行对话。但是，Kubernetes 的 RBAC 功能就能限制这种通信。

“我们可以说，我的命名空间中的容器只能够与同一命名空间内的容器通信，而不允许与其他命名空间中的容器通信。”Goins 说，此外，“可以这么说，作为用户，我只允许与我自己的命名空间对话，而你作为用户，你也只允许和自己的命名空间对话。这是工作负载层面以及用户层面的安全性。如果操作正确，用户甚至无法看到另一个工作负载的存在。”

这是 Kubernetes 的功能之一——单个集群中的多租户。但是，Rancher 对命名空间功能进行了进一步拓展，整合了“项目”资源，以帮助减轻集群的管理负担。

在 Rancher 中，项目（Projects）允许管理员在单个实体下收集多个命名空间。在 Kubernetes 的基础版本中，RBAC 或集群资源等特性被分配给各个命名空间。在有些 Kubernetes 集群里，多个命名空间需要相同的访问权限，而手动将这些权限分配给每个命名空间，可以说是一项乏味的任务。即使所有命名空间都需要相同的权限，也无法保证在一个操作中能将这些权限应用于所有命名空间。Goins 指出，管理员必须重复地将这些权限分配给每个命名空间。

而 Rancher 的 Project 概念，让管理员可以在项目层级分配资源和访问权限，从而解决了上述问题。然后项目中的每个命名空间继承这些资源和策略，因此管理员只需将它们分配给项目一次，而不是将它们分配给每个命名空间。

通过 Project，管理员可以执行很多操作，例如为用户分配访问一组命名空间的权限、为用户分配项目中的特定角色、为项目分配资源、分配 pod 安全策略等等。

03 NetworkPolicy 资源

NetworkPolicy 是一种 Kubernetes 资源，用于配置 pod（具有共享存储和网络资源的一个或多个容器的逻辑组）如何相互通信或如何与其他网络端点通信。

默认情况下，pods 是非隔离的，这意味着它们会接受来自任何来源的流量。Goins 解释说：“NetworkPolicy 就像 Kubernetes 集群上运行的 pods 之间基于软件的防火墙。管理员可以为命名空间创建‘默认’隔离策略，方法是先创建一个 NetworkPolicy，选择所有 pods，但不允许向这些 pods 发送任何传入或传出的流量。”

此外，管理员可以配置哪些 pods 可以彼此连接。这些策略可以再进一步详细描述，让管理员可以指定哪些命名空间可以通信，或者选择端口号来执行每个策略。

NetworkPolicy 资源需要支持配置的网络后端，如 Calico、Canal、Romana 或 Weave。根据 Kubernetes 文档，简单地创建资源而没有控制器来实现它是没有效果的。

04 防范内部威胁

尽管有一些默认工具可以保护 Kubernetes 安全，但其中许多工具似乎只是为了防止外部威胁到集群。更有甚者，它们甚至很难进行扩展。若企业想要保护集群不受内部威胁（无论是来自实际的恶意内部威胁，还是仅仅是防止错误或错误编码传播）时，防御的手段非常少。

不过所幸的是，有一些解决方案已经着眼于保护集群免受未经授权的内部访问。其中一些存在于 Kubernetes 框架中，比如命名空间，而 Rancher 的 Project 则在默认设置之上还有进一步扩展，以便对整个企业环境进行更精确的管理和控制。

关键的是，不要在内部资源的网络安全问题上感到放弃或者气馁。遵循本文的三个步骤，您依然可以在严格控制内部访问保护的同时获得使用 Kubernetes 集群最高效率。

下篇文章将是本系列文章的最后一篇，我们将来看看如何处理资源限制的问题，如何防止用户过度消耗 Kubernetes 资源。