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资源。

1 个评论

欢迎添加微信助手(rancher2),进技术群,了解更多~~

要回复文章请先登录注册