PAN深入挖掘Kubernetes安全缺陷

导语

Palo Alto Networks（PAN）的Unit 42研究部门本周发布了安全警报，警告先前披露的Kubernetes漏洞可能比最初意识到的更为严重。

正文

最近在Kubernetes节点的网络组件kube-proxy中发现了一个称为CVE-2020-8558的问题。默认情况下，Kubernetes节点的内部服务通常在没有身份验证的情况下运行。事实证明，在某些版本的Kubernetes上，此漏洞可以暴露Kubernetes api服务器，这可能允许未经身份验证的攻击者完全控制群集。

CVE-2020-8558的核心问题是本地主机服务，该服务只能从节点本身进行访问，并暴露给本地网络上的主机以及节点上运行的Pod。

Unit 42威胁情报副总监Jen Miller-Osborn说，本地主机绑定服务期望只有受信任的本地进程才能与它们交互，因此通常在没有任何身份验证要求的情况下就不会对其进行配置。

虽然已经发布了补丁程序来解决CVE-2020-8558问题，但Miller-Osborn说，一些较早版本的Kubernetes（关注 开源村 获取更多k8s资讯）不会禁用api-server不安全端口，该端口通常只能在主节点内访问。

最终修复程序在route_localnet周围添加了缓解措施：路由规则导致节点丢弃外部数据包。kube-proxy仍启用Route_localnet，但是Miller-Osborn说，有关禁用它的讨论正在进行。即使应用了这些缓解措施，仍然存在一种独特的情况，网络攻击可能会将数据包发送到Kubernetes（关注 开源村 获取更多k8s资讯）内部UDP服务。但是，仅当受害者节点禁用反向路径筛选时，攻击才能起作用。

Miller-Osborn表示，网络安全问题不太可能阻碍Kubernetes的进一步采用，但它们将鼓励IT团队确保已制定Kubernetes更新策略。许多Kubernetes（关注 开源村 获取更多k8s资讯）的早期采用者仍在运行较旧，安全性较低的平台版本，因为他们担心更新会破坏其应用程序。这些较早版本中使用的许多应用程序编程接口（API）已被Kubernetes的最新版本所取代。

拥抱Kubernetes的组织必须采用最佳DevSecOps实践，以确保集群和部署在这些集群上的云原生应用程序的安全性。

同时，关于容器安全性的争论日益激烈。一方面，基于容器的云原生应用程序应该更加安全，因为与修补整体应用程序相比，撕裂和替换具有漏洞的容器要容易得多。但是，使用容器（关注 开源村 获取更多k8s资讯）构建的应用程序是基于微服务的，这些微服务具有很多依赖性。如果漏洞在相当长的一段时间内未被发现，则造成的潜在损害可能会很大。

当然，开发人员正在拥抱容器，以构建和部署更具弹性和灵活性的应用程序。如果随着时间的推移证明这些应用程序更安全，则开发人员可能会认为，这是网络安全团队有一天会完全赞赏的一项额外奖励。