导语
Kubernetes中的安全性是一个多维问题,必须从各个不同的角度来解决才算完善,这篇文章将从4个方面为读者列出安全清单。
正文
Kubernetes,经过更快的采用和社区的更多贡献,正日益攀登到新的高度。不过,安全性仍然是Kubernetes的重要方面之一,最初使早期采用者望而却步。与虚拟机相比,许多人怀疑容器和Kubernetes的安全性,随后注销了容器。但是人们逐渐和稳定地开始相信容器和Kubernetes现在和物理机和虚拟机一样安全。
Kubernetes中的安全性是一种实践,而不仅仅是一项功能。安全是一个多维问题,必须从许多不同的角度来解决。Kubernetes中的安全性无法在一篇文章中涵盖,但是以下清单涵盖了应该在整个堆栈中进行审查的主要安全性领域。
安全必须是任何组织的DevOps流程(通常称为DevSecOps)的一等公民。使用DevSecOps,从一开始就将安全问题作为DevOps管道的一部分嵌入其中。DevSecOps实践可实现大多数安全问题的自动化,并在开发过程中提供一系列安全检查。
由空军首席软件官Nicolas M. Chaillan牵头的DevSecOps开放计划是在组织中采用DevSecOps及其重要性的一个很好的例子。详细信息已发布在
空军网站上,以便其他组织深入DevSecOps使用。这些DevSecOps做法可以为组织提供在其Kubernetes基础架构中嵌入安全保护措施的途径。
Kubernetes的安全性可以定义为以下4个方面:基础设施、Kubernetes、容器和应用程序,见下图所示。
图1. Kubernetes安全的4个方面
一.保护基础设施
基础结构级的安全性通常是最基本的任务,但也是最大的任务。但是,在开发过程中经常会忽略它。在构建应用程序时,请务必牢记基础架构的安全性,因为它会影响应用程序的架构方式。
基础结构安全本身具有许多方面:
1.联网
Kubernetes部署主要是微服务,所有微服务都在彼此对话或与外部应用程序和服务通信。重要的是,仅将网络流量限制为必需的流量,同时要了解微服务可能是短暂的,并且可以在集群中的节点之间移动。您需要考虑网络设计的各个方面,以开发安全的网络。
(1)控制流量的隔离:Kubernetes控制平面流量必须与数据平面流量隔离。这不仅出于安全原因,而且还避免数据流量影响Kubernetes控制平面流量。如果没有隔离,来自数据平面的流量可能会使来自控制平面的流量蒙上阴影,并导致临时服务中断。
(2)隔离存储流量:类似地,需要将存储流量与常规数据隔离开来并控制流量,以使基础结构的存储服务不会消耗或关闭应用程序网络,反之亦然。
(3)网络细分:Kubernetes对用户隐藏了基础架构。开发人员在设计网络时应牢记这一事实以及多租户。底层网络基础结构必须同时支持基于第2层
VLAN的分段和基于第3层VXLAN的分段,以隔离各种租户或应用程序之间的流量。两种分割技术都可以根据需要使用。
(4)服务质量:在共享网络基础结构中,嘈杂的“邻居”是一个大问题。重要的是,基础网络基础结构可以保证为每个Pod或租户指定的服务水平,同时
确保一个Pod的流量不会影响其他Pod。诸如SR-IOV之类的网络虚拟化技术有助于在共享基础架构上提供虚拟化隔离。
(5)网络策略,防火墙和ACL:我们将在后面更详细地讨论应用程序级别的网络访问控制,但是网络应在硬件级别上具有较低级别的访问控制,并应更好地控制共享环境中的流量。
2.存储
对于任何组织来说,存储都是安全性的关键部分。黑客通常会寻找保存在应用程序存储中的机密数据,例如信用卡信息或个人身份信息(PII)。使用Kubernetes的开发人员应考虑以下形式的存储级安全性实现。
(1)自加密驱动器:存储安全性的一种基本形式是自加密驱动器。使用这些驱动器,加密就转移到磁盘本身上,在那里数据在写入磁盘时得到加密。这样可以确保如果有人可以物理访问磁盘驱动器,则他们将无法访问数据。
(2)卷加密:在共享基础架构中,Kubernetes CSI管理卷的生命周期。这样可以将用户与基础存储基础架构隔离开。卷加密可确保保护各个卷,以防止来自不需要的元素的访问。
(3)服务质量:在共享存储基础结构中,大量I / O应用程序可能会影响其他应用程序的性能。重要的是,基础存储基础架构应具有确保为每个Pod或
租户提供保证的服务水平的能力。同样,SR-IOV有助于在PCI级别提供存储隔离,每个租户使用单独的队列。
3.主机和操作系统(OS)
基础架构的下一个层次是物理或虚拟主机本身。运营商将希望通过以下方式保护基础:
(1)加强操作系统:站点可靠性工程师(SRE)应遵循一般安全准则保护主机操作系统,并加强操作系统以避免任何进一步的更改。SRE还应该应用防
火墙,端口阻止和其他标准最佳实践安全措施。常规安全更新和修补程序在可用后必须立即应用。黑客和入侵者经常利用已知漏洞。
(2)启用内核安全性:SELinux和AppArmor之类的内核安全性模块定义了系统上的应用程序,进程和文件的访问控制。
(3)审核日志记录:使用Kubernetes的组织应该实施审核日志记录,不仅可以帮助监视系统,还可以帮助调试和查找安全漏洞的踪迹。
(4)轮换凭证:用户凭证必须经常轮换,并且必须遵循严格的安全准则,以免被破解或被盗。
(5)锁定节点:在Kubernetes集群中配置并设置节点后,应删除操作系统。除了补丁和升级外,无需安装或配置任何新内容。所有节点都必须锁定,并且只能由超级管理员访问。
(6)CIS一致性:CIS(Internet安全中心)提供了一致性测试,以确保已实施所有最佳实践。查看您的主机设置,并通过一致性测试以确保符合要。
4.主机级访问管理
进入Kubernetes集群的最薄弱点是节点本身。由于Kubernetes极大地将用户与基础节点隔离开来,因此控制对节点的访问非常重要。
(1)严格访问:组织应谨慎将对节点的root / admin访问限制为一组非常有限的受信任用户。
(2)建立锁定:即使对于非root用户,理想情况下也应限制对开发人员的直接登录并将其限制为通过Kubernetes API服务器进行访问。为了避免对运行在节点上的Kubernetes服务造成任何威胁,应锁定所有节点。
(3)隔离Kubernetes节点:Kubernetes节点必须位于隔离的网络上,并且绝对不能直接暴露给公共网络。如果可能的话,它甚至不应直接暴露于公司网络。仅当Kubernetes控制和数据流量隔离时才有可能。否则,两个业务流都流经同一管道,并且对数据平面的开放访问意味着对控制平面的开放访问。理想情况下,应该将节点配置为仅接受来自指定端口上主节点的连接(通过网络访问控制列表)。
(4)主节点:主节点访问必须由网络访问控制列表控制,仅限于管理集群所需的IP地址集。
二. 保护Kubernetes
在锁定基础架构的情况下,确保安全的下一层是Kubernetes安装本身。在典型的开源Kubernetes安装中,由于默认情况下它们并未全部打开,因此其中许多需要手动配置。
1.安全etcd
etcd是高度可用的键值存储,用作所有集群数据的Kubernetes的后备存储。它包含了Kubernetes的所有状态,秘密和信息,这意味着保护etcd非
常重要。
(1)如前所述,etcd中的节点应该以最小的访问权限被锁定。
(2)理想情况下,应加密包含etcd数据的驱动器。
(3)对etcd的访问必须仅限于母版。
(4)理想情况下,etcd通信应通过TLS。
2.确保对Kubernetes集群的访问
Kubernetes允许企业使用标准的身份和访问控制解决方案,但是它们需要与环境集成,并且默认情况下不提供。访问控制可以细分为以下组件。
(1)身份验证:用户必须先经过身份验证,然后才能访问Kubernetes API。Kubernetes提供了各种身份验证模块-包括客户端证书,密码,普通令牌,引导令牌和JWT令牌(用于服务帐户)。但是,实际的用户管理和身份验证不是Kubernetes的一部分。对于生产环境,组织将需要支持这些功能的外部用户管理和身份验证插件或Kubernetes平台。与LDAP,Active Directory或其他身份提供程序解决方案集成非常重要。
图2. Kubernetes中基于角色的访问控制
(2)授权:验证用户身份(即允许其连接到Kubernetes集群)后,下一步是授权,以确定对所请求资源的访问权限。Kubernetes支持多种授权模块,例如基于属性的访问控制(ABAC),基于角色的访问控制(RBAC)和Webhooks。RBAC是最受欢迎的授权插件之一,因为它允许在多租户环境中对单个Kubernetes资源进行精细控制。
(3)准入控制:准入控制挂钩允许组织在用户经过身份验证并被授权访问所请求的资源之后,拦截和控制Kubernetes请求。准入控制的最佳示例是资源配额,该配额使组织可以控制资源消耗。还必须通过TLS保护对Kubernetes API服务器的访问。
3.安全政策
Kubernetes提供了一些可由用户定义的可配置策略。这些应符合企业惯例,但默认情况下未启用。
一个吊舱安全策略是一个准入控制插件,确保遵循一定的安全准则时舱体只承认。可以定义的策略包括限制特权Pod的创建,阻止容器作为root用户运行或限制对某些名称空间,网络或卷的使用。网络策略由容器网络接口(CNI)插件实现,该插件控制如何允许Pod组与彼此以及其他网络端点进行通信。设置网络策略非常重要,因为默认情况下,pod是非隔离的(它们接受来自任何来源的流量)。
Kubernetes为计算资源(CPU和内存)提供服务质量(QoS)保证,以避免邻居过多或资源匮乏的问题,但它不为I / O(存储和网络)提供QoS。Diamanti等超融合平台增加了对I / O QoS的支持。
4.工作负载隔离和多租户
在多租户环境中,每个租户或租户组必须具有单独的名称空间,以使工作负载和数据彼此隔离。CNI,CSI和身份验证插件需要支持这些分隔和边界,以便它们在整个堆栈中保持一致。
三. 保护容器
容器在开发过程中和运行时都需要加以保护。有很多很棒的资源可用于保护容器,包括本文,但这里有一些关键要素:
1.容器映像安全
所有正在运行的容器均基于映像文件,该映像文件可以从诸如Docker Hub之类的开放库中下载,也可以从一个团队传递给另一个团队。重要的是要知道图像的来源和内部内容。所有这些举措都应该成为组织DevOps流程的一部分,以实现自动化并确保安全。
(1)图像漏洞扫描:必须使用Aqua,Twistlock,Sysdig和Clair等工具对正在构建的容器映像进行扫描以查找已知漏洞。这些工具解析映像中的程序包和依赖项,以查找已知的漏洞。
(2)图像签名:组织还应执行严格的准入控制政策,仅允许通过公司公证人签名的图像。TUF和Notary是用于签名容器映像和维护容器内容信任系统的有用工具。
(3)限制特权:此外,组织应避免在容器映像中使用root用户,并防止特权升级。容器内部的用户必须具有必需的最低级别的操作系统特权,才能实现容器的目标。
2.容器运行时
容器运行时是安装在操作系统中的程序。今天,大多数环境都使用Docker,而CIS基准可用。Seccomp可用于减少攻击面,而更新的运行时(如CRI-O)具有附加的内置安全功能。
3.运行容器
Twistlock,Aqua和Sysdig等许多工具还通过监视网络和系统调用,为运行时漏洞提供连续监视和威胁预防。这些工具还具有拦截和阻止这些不需要的呼叫或通信并执行安全策略的能力。
四. 保护应用程序
最后,在保护了基础架构,Kubernetes和容器之后,保护应用程序本身仍然很重要。
1.应用程序访问
(1)用于Kubernetes入口的TLS:将您的应用程序暴露在集群外部的最常见做法是使用入口控制器,例如Envoy或NGINX。所有对入口控制器的外部访问都必须通过TLS,并且入口控制器与应用程序容器之间的通信也应使用TLS,尽管在某些情况下不需要使用TLS,具体取决于网络设计和公司安全策略。
(2)加密传输中的所有内容:除少数情况外,默认行为应是加密传输中的所有内容。即使在公司防火墙后面,也建议对容器之间的网络流量进行加密。Istio和Linkerd等许多服务网格提供了mTLS选项,以自动加密Kubernetes集群中的流量。
2.通讯
(1)网络:Istio,Linkerd和Consul等服务网格提供了许多第7层网络功能,从而可以限制和控制多个租户之间的流量。
(2)端口:仅在应用程序/容器上公开对于与该应用程序通信绝对必要的端口,这一点很重要。
3.应用强化
CI / CD管道中应内置许多DevOp实践,以确保应用程序安全并遵循最佳实践。一些例子是:
(1)定期分析源代码,以确保其遵循最佳实践,以避免漏洞和威胁。有许多可用的工具,例如Veracode和Synopsys。
(2)大多数开发人员都依赖第三方应用程序和库来构建其应用程序和微服务。定期扫描代码依赖项以查找新漏洞,以确保它们不会威胁到应用程序的安全。
(3)持续测试您的应用程序是否受到常见攻击实践的影响,例如SQL注入,DDoS攻击等。这里有各种动态分析工具可为您提供帮助。
综上所述
安全始终是组织的头等大事。但是从传统上讲,安全性是组织中一个独立的团队,该组织在独立于开发过程的孤岛中工作。开发人员通常专注于应用程序,并且安全团队会在开发周期结束时介入其中。但是,由于开发团队忽略了关键的安全策略,因此安全团队拖延了流程,这可能会使部署脱轨。安全和开发团队之间的这种不健康的互动不仅导致脆弱的软件开发,而且还导致许多最新的错误以及生产中意外的延迟。
在容器和Kubernetes的新时代,拥有强大的安全实践自动化非常重要。从一开始就应该将安全性纳入开发周期。随着安全性在DevOps流程中根深蒂固,DevSecOps现在成为焦点。挑战在于,必须在多个域中手动配置以上清单中概述的许多项目。缺少其中一项可能会使整个应用程序和公司面临风险。
应用程序安全性仍然是开发人员的责任。但是与基础设施,平台和Kubernetes相关的其他安全功能可以通过Diamanti平台等现代超融合方法解决。Diamanti平台是Kubernetes的全栈硬件和软件平台,它内置了本文中提到的许多安全功能,从而减轻了为组织自己实施这些功能的痛苦。这可以帮助您轻松设置DevSecOps管道,以便您可以专注于应用程序开发。