这是关于Kubernetes安全系列三篇文章中的第二篇。在上篇文章中我们分享了如何确保企业的Kubernetes集群免受外部***，这篇文章中我们将分享三种保护Kubernetes免受内部威胁的方法，后续我们还想介绍如何处理资源消耗或noisy neighbor问题。
本质上讲，Kubernetes集群是多用户的。因此，组织通常希望通过RBAC（基于角色的访问控制）、逻辑隔离和网络策略来确保交叉通信受到保护。
像Kubernetes这样的容器编排系统将开发人员和运维人员（DevOps）更紧密地联系在一起，使团队更容易有效地相互协作。诚然，我们相信DevOps团队的大多数成员不会存在什么恶意企图，但是，组织仍然需要确保，如果应用程序之间存在交叉通信，并且如果有人编写了错误代码，我们能够将损失控制在最小。
减轻对容器的恶意威胁与保护物理服务器，这两者的策略不同。然而，无论系统管理员是在数据中心部署了多个服务器，还是在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充当了每个集群的身份验证代理，管理员不再需要为部署集群所在的每个提供者提供或管理账户。
此外，部署到集群的应用应该使用命名空间，将资源进行逻辑隔离后，管理员可以给它们附加安全策略。命名空间可以给集群资源分段，并且包括它们所包含的pod的配额以及默认资源限制。尽管命名空间最初的目的是用于跨多个团队或项目的多用户环境，但现在它已经是公认的集群内的最佳标准实践了。
默认情况下，在Kubernetes中，没有任何东西可以阻止拥有容器的两个不同团队进行对话。但是，Kubernetes的RBAC功能就能限制这种通信。
“我们可以说，我的命名空间中的容器只能够与同一命名空间内的容器通信，而不允许与其他命名空间中的容器通信。”Goins说，此外，“可以这么说，作为用户，我只允许与我自己的命名空间对话，而你作为用户，你也只允许和自己的命名空间对话。这是工作负载层面以及用户层面的安全性。如果操作正确，用户甚至无法看到另一个工作负载的存在。”
这是Kubernetes的功能之一——单个集群中的多租户。但是，Rancher对命名空间功能进行了进一步拓展，整合了“项目”资源，以帮助减轻集群的管理负担。
在Rancher中，项目（Projects）允许管理员在单个实体下收集多个命名空间。在Kubernetes的基础版本中，RBAC或集群资源等特性被分配给各个命名空间。在有些Kubernetes集群里，多个命名空间需要相同的访问权限，而手动将这些权限分配给每个命名空间，可以说是一项乏味的任务。即使所有命名空间都需要相同的权限，也无法保证在一个操作中能将这些权限应用于所有命名空间。Goins指出，管理员必须重复地将这些权限分配给每个命名空间。
而Rancher的Project概念，让管理员可以在项目层级分配资源和访问权限，从而解决了上述问题。然后项目中的每个命名空间继承这些资源和策略，因此管理员只需将它们分配给项目一次，而不是将它们分配给每个命名空间。
通过Project，管理员可以执行很多操作，例如为用户分配访问一组命名空间的权限、为用户分配项目中的特定角色、为项目分配资源、分配pod安全策略等等。
NetworkPolicy是一种Kubernetes资源，用于配置pod（具有共享存储和网络资源的一个或多个容器的逻辑组）如何相互通信或如何与其他网络端点通信。
默认情况下，pods是非隔离的，这意味着它们会接受来自任何来源的流量。Goins解释说：“NetworkPolicy就像Kubernetes集群上运行的pods之间基于软件的防火墙。管理员可以为命名空间创建‘默认’隔离策略，方法是先创建一个NetworkPolicy，选择所有pods，但不允许向这些pods发送任何传入或传出的流量。”
此外，管理员可以配置哪些pods可以彼此连接。这些策略可以再进一步详细描述，让管理员可以指定哪些命名空间可以通信，或者选择端口号来执行每个策略。
NetworkPolicy资源需要支持配置的网络后端，如Calico、Canal、Romana或Weave。根据Kubernetes文档，简单地创建资源而没有控制器来实现它是没有效果的。
尽管有一些默认工具可以保护Kubernetes安全，但其中许多工具似乎只是为了防止外部威胁到集群。更有甚者，它们甚至很难进行扩展。若企业想要保护集群不受内部威胁（无论是来自实际的恶意内部威胁，还是仅仅是防止错误或错误编码传播）时，防御的手段非常少。
不过所幸的是，有一些解决方案已经着眼于保护集群免受未经授权的内部访问。其中一些存在于Kubernetes框架中，比如命名空间，而Rancher的Project则在默认设置之上还有进一步扩展，以便对整个企业环境进行更精确的管理和控制。
关键的是，不要在内部资源的网络安全问题上感到放弃或者气馁。遵循本文的三个步骤，您依然可以在严格控制内部访问保护的同时获得使用Kubernetes集群最高效率。
下篇文章将是本系列文章的最后一篇，我们将来看看如何处理资源限制的问题，如何防止用户过度消耗Kubernetes资源。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
