特斯拉遭 Kubernetes 漏洞攻击，也许只是开始！

Posted 2021-04-16 开源村OSV

转载信息

转载自：K8sMeetup

原文链接： 

引言

Kubernetes ，帮助企业完成应用程序自动化部署，为企业带来了巨大的商业利益。但，与传统环境相同，Kubernetes 也很容易遭受来自黑客和内部人员的恶意攻击。

审时度势，Kubernetes 安全问题已经成为部署的关键。今天的文章我们就来说说面对纷繁复杂的攻击手段， 开发人员和运维人员应该如何在生产环境下保障 Kubernetes 的安全。

勒索软件、加密挖掘、数据窃取、服务中断…… 无论在私有云还是公有云中，攻击者的手段层出不穷，躲在暗处伺机对虚拟环境中的新容器发起攻击。

更糟糕的是，像 Docker 和 Kubernetes 这样的新技术本身就容易受到攻击。几个月前，特斯拉的 Kubernetes 漏洞攻击虽是针对容器技术的首例，但未来几个月和几年中未必不会出现第二例，甚至第 N 例……

Kubernetes 101

Kubernetes 是非常流行的容器编排工具，可以自动执行容器的部署、更新和监视任务。目前，Kubernetes 几乎可以在市面上所有主要容器管理和云平台上运行，如 Red Hat OpenShift，Docker EE，Rancher，IBM Cloud，AWS EKS，Azure，SUSE CaaS 和 Google Cloud 等。在介绍安全问题之前，首先介绍一些 Kubernetes 的基础知识：

主节点（Master Node）：管理 Kubernetes 工作节点群集和在节点上部署 Pod 的服务器。

工作节点（Worker Node）：通常用来运行应用程序容器和其他 Kubernetes 组件，如 agents 和 proxies。

Service：Service 可以用作其底层 pod 的代理，并且可以在复制 pod 中请求进行负载均衡。

系统组件：用于管理 Kubernetes 集群的关键组件包括 API Server，Kubelet 和 etcd。这些组件都是攻击者的潜在目标。实际上，最近特斯拉事件就是黑客通过攻击未受保护的 Kubernetes  控制台来安装加密挖掘软件的。

Kubernetes 网络基础知识

挑战与问题 

容器的超动态性为 Kubernetes 的安全带来一系列挑战：

East-West 流量大爆炸。容器可以跨主机甚至跨云端进行动态部署，大大增加了 east/west 或内部流量，这导致 Kubernetes 非常容易受到攻击。

Attack Surface 增加。每个容器都有不同的 Attack Surface 和可被利用的漏洞。另外，容器编排工具（如 Kubernetes 和 Docker）非常容易引入额外的 Attack Surface。

安全工具不能及时更新。旧模型和安全工具无法适应不断变化的容器环境。

Kubernetes 团队需要回答的问题

为了评估容器在运行时的是否安全，Kubernetes 团队可以结合自己情况思考以下安全相关的问题：

你是否对正在部署的 Kubernetes pod 有可见性？例如，应用程序 pod 或集群如何互相通信的？

你是否有办法检测容器之间 east/west 流量的不正常行为？

你是否能够监控 pod 内或容器内存在潜在的漏洞？

你是否已经查看 Kubernetes 集群的访问权限并了解内部潜在的攻击媒介？

安全团队需要回答的问题

安全过程自动化可以有效保证应用程序开发团队的速度，不会拖慢 DevOps。因此，实现安全过程自动化对于安全团队来说至关重要。Kubernetes 安全团队必须能够回答以下有关容器部署的问题：

你会如何缩短开发人员获得新代码的安全审批流程所需时间？

你如何简化安全报警和运营团队监控工作，并快速查明那些需要特别关注的潜在攻击目标？

你如何在 Kubernetes 环境中分割某特定容器或网络连接？

小心漏洞和攻击媒介

Kubernetes 容器在 pod 中运行时受到的攻击可能来自外部网络，也可能来自内部人员，另外还有钓鱼攻击，自家的系统随时可能成为内部攻击的“便捷通道”。以下是一些典型例子：

容器受损：应用程序配置错误或漏洞让攻击者能够进入容器，探测网络、过程控制或文件系统中的弱点。

数据通过 pod 泄露：数据窃取通常使用多种技术手段进行配合，其中一项技术就是连接到命令/控制服务器的 pod 中的反向 shell 和隐藏机密数据的网络隧道。

最具破坏力的攻击——杀伤链

最具破坏性的攻击通常是一个杀伤链（Kill Chain) 或一系列恶意攻击行为，它们经常同时实施以达到攻击者的目的。这样的攻击可以在几秒钟内迅速发生，或在数天，数周甚至数月内传播开来。

因为攻击者动用了不同资源，所以处理“杀伤链”需要进行多层安全监控。为了在生产环境中获得最佳检测时机，需要着重以下几个方面监控： 

网络检查：攻击者首先会通过网络连接进入，然后通过网络扩大攻击范围。网络是攻击者进行攻击的第一入口，随后进行横向移动，最终实现数据窃取的目的。

容器监控：可以通过监视每个容器进程、系统调用和文件系统活动来检测应用程序或系统漏洞，及时查明是否有可疑进程正在尝试提升特权或突破容器束缚。

主机安全：传统的主机（端点）安全工具可以用来检测针对 kernel 或系统资源的攻击。新情况下，主机安全工具还必须能识别 Kubernetes 和容器以保证监管范围。

除上述几个攻击途径之外，攻击者还会攻击部署工具，例如 Kubernetes API 服务器或控制台，以获取机密信息的访问权限或控制正在运行的 pod。

攻击 K8S 基础设施

为了禁用或破坏应用程序、获取机密信息，机密资源或容器的访问权限，黑客还可能对Kubernetes 基础设施进行破坏，如攻击 API 服务器或 Kubelets。在特斯拉事件中，黑客就是利用无保护的控制台访问底层基础设施并运行加密挖掘软件的。

当 API Server token 被盗或者有黑客冒充授权用户时，攻击者就可以堂而皇之地通过部署恶意容器或阻止关键应用程序运行来访问数据库了。

通过攻击 Kubernetes，黑客可以中断正在运行的应用程序，甚至可以控制用于运行容器的底层资源。Kubernetes 中有一些已发布的特权升级机制，攻击者可以利用 Kubelet 访问 etcd 或 service tokens，获得受损容器的集群管理权限。

为生产准备 Kubernetes 工作节点

在容器中部署应用程序之前，应锁定 Kubernetes 工作节点的主机系统。以下是锁定主机最有效方法。建议在生产部署前确认以下步骤保证安全：

使用 namespaces

限制 Linux 功能

启用 SELinux

使用 Seccomp

配置 Cgroups

使用 R / O 安装

使用最小的主机操作系统

更新系统补丁

运行 CIS Benchmark （CIS 基准）安全测试

Kubernetes 运行时安全

容器在生产环境下运行需注意这三个方面：网络过滤，容器检查和主机安全。

网络过滤

Kubernetes ，帮助企业完成应用程序自动化部署，为企业带来了巨大的商业利益。但，与传统环境相同，Kubernetes 也很容易遭受来自黑客和内部人员的恶意攻击。

审时度势，Kubernetes 安全问题已经成为部署的关键。今天的文章我们就来说说面对纷繁复杂的攻击手段， 开发人员和运维人员应该如何在生产环境下保障 Kubernetes 的安全。

勒索软件、加密挖掘、数据窃取、服务中断…… 无论在私有云还是公有云中，攻击者的手段层出不穷，躲在暗处伺机对虚拟环境中的新容器发起攻击。

更糟糕的是，像 Docker 和 Kubernetes 这样的新技术本身就容易受到攻击。前些日子，特斯拉的 Kubernetes 漏洞攻击虽是针对容器技术的首例，但未来几个月和几年中未必不会出现第二例，甚至第 N 例……

容器检查

黑客经常利用特权升级和恶意进程进行攻击或传播。利用 Linux 内核（如Dirty Cow）、软件包、库或应用程序本身的漏洞在容器内进行破坏活动。

检查容器过程和文件系统活动中可疑行为是确保容器安全的关键要素。可疑进程（如端口扫描和反向 shell）或特权升级需要进行全面检测。内置检测和基线行为学习过程的组合，应该可以基于以前的行为检测出异常过程。

如果在设计容器化的应用程序时能考虑微服务原则（容器中的每个应用程序都具有有限的一组功能，并且容器仅包含所需的程序包和库），那么检测可疑进程和文件系统活动会更加容易和准确。

主机安全

Kubernetes ，帮助企业完成应用程序自动化部署，为企业带来了巨大的商业利益。但，与传统环境相同，Kubernetes 也很容易遭受来自黑客和内部人员的恶意攻击。

审时度势，Kubernetes 安全问题已经成为部署的关键。今天的文章我们就来说说面对纷繁复杂的攻击手段， 开发人员和运维人员应该如何在生产环境下保障 Kubernetes 的安全。

勒索软件、加密挖掘、数据窃取、服务中断…… 无论在私有云还是公有云中，攻击者的手段层出不穷，躲在暗处伺机对虚拟环境中的新容器发起攻击。

更糟糕的是，像 Docker 和 Kubernetes 这样的新技术本身就容易受到攻击。前些日子，特斯拉的 Kubernetes 漏洞攻击虽是针对容器技术的首例，但未来几个月和几年中未必不会出现第二例，甚至第 N 例……

保护 Kubernetes 系统和资源

编排工具，例如 Kubernetes， 以及构建在他们之上的管理平台，如果不受保护的话，很容易受到攻击。容器部署中潜在的 attack surfaces 一旦被暴露很容易被黑客利用。最近的特斯拉黑客攻击和 Kubelet 漏洞利用仅仅是开发/补丁持续循环的开始，更多新技术出现只会让事情变得更复杂。

为了保护 Kubernetes 和管理平台本身免受攻击，为系统资源正确配置 RBAC 至关重要。以下是需要查看和配置适当访问控制的区域：

保护 API 服务器。为 API 服务器配置 RBAC 或手动创建防火墙规则以防止未经授权的访问。

限制 Kubelet 权限。为 Kubelet 配置 RBAC 并管理证书轮换以保护 Kubelet。

对所有外部端口进行身份验证。检查外部可访问的所有端口并删除不必要的端口

对外部端口进行认证。 对于未经认证的服务，限制对白名单来源的访问。

限制或删除控制台访问。除非配置用户使用强密码或双因素身份验证登录，否则不允许控制台/代理访问。

如果能与上文提到的可以锁定工作节点的强大主机安全工具结合使用，就可以保护 Kubernetes 部署基础结构免受攻击。建议使用监视工具来跟踪对基础设施服务的访问，以检测未经授权的连接和潜在的攻击。

安全检查测试

Kubernetes ，帮助企业完成应用程序自动化部署，为企业带来了巨大的商业利益。但，与传统环境相同，Kubernetes 也很容易遭受来自黑客和内部人员的恶意攻击。

审时度势，Kubernetes 安全问题已经成为部署的关键。今天的文章我们就来说说面对纷繁复杂的攻击手段， 开发人员和运维人员应该如何在生产环境下保障 Kubernetes 的安全。

勒索软件、加密挖掘、数据窃取、服务中断…… 无论在私有云还是公有云中，攻击者的手段层出不穷，躲在暗处伺机对虚拟环境中的新容器发起攻击。

更糟糕的是，像 Docker 和 Kubernetes 这样的新技术本身就容易受到攻击。前些日子，特斯拉的 Kubernetes 漏洞攻击虽是针对容器技术的首例，但未来几个月和几年中未必不会出现第二例，甚至第 N 例……

Kubernetes 开源安全工具

开源项目不断发展并相继增加安全功能。以下是其中一些可以考虑使用的项目：

Istio，Istio 创建了一个 service mesh，用于管理服务到服务的通信，包括路由，身份验证和加密，但它不是检测攻击和威胁的安全工具。

Grafeas，Grafeas 提供了一种工具，为审核和管理现代软件供应链定义了一种统一的方式。

Clair，Clair 是用于镜像漏洞扫描的简单工具，但缺少注册表集成和工作流程支持。

Kubernetes CIS Benchmark，可以使用 Kubernetes CIS Benchmark 中针对 Kubernetes Security 的合规性检查。

原文链接：

https://neuvector.com/container-security/kubernetes-security-guide/

联系我们：[e-mail]

或扫描二维码

加开源村小秘进群讨论

我

们

About

以开源的思想，做开源社区。关注OpenStack、K8s、Linux等主流开源技术方向。