资讯专栏INFORMATION COLUMN

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

ghnor / 1830人阅读

摘要:若企业想要保护集群不受内部威胁无论是来自实际的恶意内部威胁,还是仅仅是防止错误或错误编码传播时,防御的手段非常少。不过所幸的是,有一些解决方案已经着眼于保护集群免受未经授权的内部访问。

这是关于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资源。

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/32929.html

相关文章

  • Kubernetes安全步谈:如何通过RBAC和强身份验证确保外部安全

    摘要:本文将介绍通过强身份验证如何确保企业的集群免受外部攻击。服务器虽然面向公开,但是受到证书身份验证的保护。年年底被爆出的首个严重安全漏洞,就是由联合创始人及首席架构师发现的。 毋庸置疑,K8s已经成为云容器编排系统的标准,但是,如果缺乏K8s环境相关的安全问题认识的话,会致使各种组件暴露在网络集群内外的攻击之下。本文将介绍通过强身份验证如何确保企业的K8s集群免受外部攻击。 showIm...

    _DangJin 评论0 收藏0
  • 拥抱Kubernetes,为企业节约时间和成本

    摘要:目前,亚太地区的组织机构每周会遭受起攻击。实施必要的程序以防止和战胜勒索软件攻击对任何企业而言都至关重要,中小企业尤为如此。鉴于市场对更完善的勒索软件实践简化的业务流程以及业务敏捷性的需求不断增长,中小企业及其人员越来越青睐。在仅仅一年多的时间里,新冠疫情给所有公司的经营方式都带来了以往数年才能发生的改变。据麦肯锡报道,各企业已提前三到四年开始部署客户和供应链互动以及内部运营的数字化进程。但...

    z2xy 评论0 收藏0
  • 多云成功的最大障碍是学习曲线

    摘要:例如,公司在年年初发布的年云计算全球安全趋势报告表明,将近一半的受访者表示,当前的工具在云计算中无法运行。云计算项目是一项值得关注的技术,因为它具有巨大的潜力。云计算供应商的基础设施拥有一支合格的专业人员团队,他们按照最佳实践维护云计算基础设施,并在发现新威胁和新方法时继续改进其安全架构。基于此,大多数云计算基础设施实际上比类似的内部部署更安全。人们都认为云计算值得探索,但绝大部分人并不是行...

    BLUE 评论0 收藏0
  • 企业云计算战略中混合搭配至关重要的5个原因

    摘要:主要的云计算基础设施提供商具有个人优势,精心规划的多云战略使企业能够选择为每个应用程序提供技术特性定价和性能的最佳组合的云平台。企业不希望在进入新的云计算环境并采用新的应用程序时损害自己的安全态势。云计算的兴起解决了关于IT团队是否应该从各种提供商中选择特殊技术,还是从单一供应商那里选择完全集成的应用程序的争论。借助云计算,企业可以拥有最好的应用程序,以及最好的云平台用于处理IT任务。而且不...

    Rindia 评论0 收藏0
  • 我们换个角度来看主机与x86之争

    摘要:对于一个应用工作负载复杂业务覆盖类型广泛的企业来说,集中式与分布式不再是非此即彼的选择。为此,也可以看到,针对分布式与集中式架构的发展特点,也与时俱进,试图在分布式和集中式架构之间构建一个和谐共处的方案。看着某云本月初又出现一波宕机故障,不免让我想起了一个业界讨论已久的问题:分布式与集中式,这两种架构到底谁最好?云计算的发展,让分布式架构大有看头,也风靡一时。曾几何时,集中式架构也似乎备受争...

    wangbjun 评论0 收藏0

发表评论

0条评论

最新活动
阅读需要支付1元查看
<