8 月 3 日,美国国家安全局 (NSA) 和网络安全与基础设施安全局 (CISA) 发布了一份网络安全技术报告“Kubernetes 强化指南”。该报告详细介绍了对 Kubernetes 环境的网络安全威胁,并提供了配置指南以最大限度地降低风险。该报告的发布或许与越来越严重的,针对 Kubernetes 的网络攻击有关。
实际上,该报告最主要的受众群体并不是广大企业内开发者,而是以政府部门为主的重要机构。但这并不妨碍开发者以此作为参考,毕竟 Kubernetes 最近已经成为安全问题的常见关键词,如何从架构层面做好基础设施安全,是架构师们重要的工作内容。
报告内展示的 Kubernetes 架构
NSA & CISA:针对 Kubernetes 的三个主要安全威胁
相比以往在架构层面对 Kubernetes 安全性的考量,NSA 的这份报告显得非常系统,它不单包括了技术层面上需要注意的配置,同时也站在网络安全的角度,提及了对于偏社会工程学攻击的防范。同时,在看完国内许多报告之后,这个“Kubernetes 强化指南”还是能让人耳目一新,因为它足够单刀直入,“废话”比较少。
在技术层面,报告主要从四个维度展开:
如何保证 Kubernetes 的 Pod 安全;
如何做好网络分离与强化;
认证和授权;
日志审核
此外,这份报告强调,针对 Kubernetes 的安全威胁主要可分为三类:
供应链风险
供应链风险通常是指构成 Kubernetes 集群的供应商或第三方依赖本身存在安全风险,包括产品组件、人员等。这大概会在两个维度对 Kubernetes 集群产生影响:
容器/应用层:对于那些跑在容器中的应用程序来说,它们的安全完全依赖于开发者和基础设施本身。一个由第三方提供的恶意容器,就会导致整个安全体系出现问题;
基础设施层:托管 Kubernetes 的底层系统有自己的软件和硬件依赖项。这中间如果出现问题,也会导致整个安全体系中门大开。
恶意行为者
恶意行为者经常利用漏洞从远程位置获取访问权限。 Kubernetes 架构公开了几个 API,黑客可能会利用这些 API 进行远程调用。
控制平面:Kubernetes 控制平面具有各种组件,它们通过通信来跟踪和管理集群。网络攻击者经常利用缺乏适当访问控制的控制平面组件来获利;
工作节点:除了运行容器引擎之外,工作节点还托管 kubelet 和 kube-proxyservice,它们可能会被网络攻击者利用。此外,工作节点存在于锁定的控制平面之外,并且可能更容易被某些行为体访问;
容器化应用程序:在集群内运行的应用程序是常见目标。应用程序经常可以在集群外访问,让人可以通过远程网络访问。 网络攻击者可以从一个已经被攻破的 Pod 转向,或者在应用程序内部通过资源访问,提升在集群中的权限。
内部威胁
简单来说,这一项就是在说“内鬼”,包括 Administrator 和 User,当然也同样包括云和基础设施服务商,此处我们就不再细说了。
报告的末尾贴出了许多实践案例,显得非常贴心:
层出不穷的 Kubernetes 网络攻击
如果你关注 Kubernetes 在安全领域的情况,可能就对 NSA 此举并不意外。
早在 2018 年,就有黑客入侵了特斯拉在亚马逊上的 Kubernetes 容器集群,由于该集群控制台未设置密码保护,黑客便得以在一个 Kubernetes pod 中获取到访问凭证,然后据此访问其网络存储桶 S3,通过 S3 获取到了一些敏感数据,比如遥测技术,并且还在特斯拉的 Kubernetes pod 中进行挖矿。该事件只是 Kubernetes 漏洞利用的一个典型案例。
就在这个 8 月,也有多家媒体报道称,有安全研究人员警告说,大量的 Kubernetes 集群正由于错误配置 Argo Workflows 实例从而导致很容易受到攻击。Argo Workflows 是一个开源的容器原生工作流引擎,主要用于协调 Kubernetes 上的并行工作,加快机器学习和大数据处理等计算密集型工作的处理速度,同时它也被用来简化一般的容器部署。
根据国外一家网络安全公司 Intezer 的分析,由于一些实例可以让用户通过仪表盘访问,不需要对外部用户进行身份验证,恶意软件运营商可以通过 Argo 将加密软件投放到云容器中。因此,这些配置错误的权限可以让攻击者在受害者的环境中运行具有攻击性的代码。
以上问题案例还只是冰山一角,作为现代云原生基础设施最重要的部分之一,Kubernetes 始终处在“炮火”中心,未来对于架构师来说,仅仅利用云原生理念支持业务降本提效还不够,如何强化安全,也将成为最重要的设计指标之一。
评论