确保 Kubernetes 安全：不要低估错误配置带来的风险

Kubernetes (K8s) 被全球超过 60% 的组织部署，是云计算领域采用最广泛的容器编排系统。K8s 集群已成为希望有效编排容器化应用程序的从业者的首选解决方案，因此这些集群通常包含各种软件、服务和资源，使用户能够相对轻松地部署和扩展应用程序。

为了支持典型的 K8s 环境操作，集群通常被授予对其他环境的访问权限，例如工件存储库、CI/CD 环境、数据库等。因此，K8s 集群可以存储客户数据、财务记录、知识产权、访问凭证、机密、配置、容器镜像、基础设施凭证、加密密钥、证书以及网络或服务信息。由于如此多的集群包含暴露在互联网上的潜在有价值和利润丰厚的数据，K8s 为威胁行为者提供了一个诱人的目标。随着配置错误的组织数量的增加，这种风险也会不断升级，导致 K8s 集群暴露并容易受到攻击。

Aqua Nautilus在最近的研究中发现，在三个月的时间里，超过 350 个信誉良好的组织（其中一些是财富 500 强）和开源项目完全暴露在世人面前。这种暴露持续几天到几个月。如果被威胁行为者利用，这些错误配置可能会导致严重的安全漏洞。

在暴露的开源项目集群的情况下，如果被攻击者利用，它们可能会导致供应链感染媒介，从而影响数百万用户。Aqua Nautilus 研究人员发现，只需进行一次 Shodan 搜索即可识别组织配置错误的集群。

暴露的集群有什么风险？

在三个月的时间里，Aqua Nautilus 使用 Shodan 进行了一系列单独的搜索。通过这些搜索，该团队查明了超过 350 个连接到有风险的 K8s API 服务器的不同 IP 地址。其中至少 60% 遭到破坏，并开展了部署恶意软件和后门的活动。

K8s 集群通常包含机密，对 API 服务器的未经身份验证的访问可能会导致对这些机密的访问，因此对其进行开放访问使攻击者能够完全控制集群。更糟糕的是，K8s 集群通常不仅存储自己的秘密。在许多情况下，K8s 集群是组织软件开发生命周期 (SDLC) 的一部分，因此它授予对源代码管理 (SCM)、持续集成/持续部署 (CI/CD)、注册表和云服务的访问权限提供商（CSP）。

这些秘密通常包含有关内部或外部注册表的信息。在许多情况下，开发人员构建了注册表的配置文件（例如“.dockerconfig”），其中包含指向其他环境和机密或凭据（包括 Docker Hub、云服务提供商和内部管理的）的链接。威胁行为者可以使用这些凭证来扩大他们的影响范围。他们甚至可以毒害注册表（如果密钥允许的话），以便在网络中的其他系统上运行恶意代码。

真实世界的曝光示例

该团队发现了不安全的 K8s API 服务器的实时示例，其中包含与各种环境相关的各种附加秘密。其中包括 GitHub 等 SCM 环境、Jenkins 等 CI 平台、Docker Hub 等各种注册表、Redis 或 PostgreSQL 等外部数据库服务等等。SCM 访问令牌允许攻击者访问组织的代码。在某些情况下，攻击者甚至可以修改它来破坏组织（如果密钥允许的话）。

一些确定的配置错误的集群只能访问几个小时，但 Aqua Nautilus 的数据收集工具设法识别并记录了暴露的信息。这凸显了有关此类错误配置的一个发人深省的事实；即使及时检测到并纠正，具有自动化功能、准备充分的攻击者仍然可以在后期访问 K8s 集群或渗透 SDLC 的各种其他元素。在安全领域，自动化很大程度上是一条双向路。只需一次有限的秘密暴露实例，威胁参与者就可以随意获得对您的集群的经过身份验证的访问。

组织应该注意哪些错误配置？

Aqua Nautilus 研究发现了组织中广泛存在并在野外被积极利用的两种常见错误配置。

1. 具有高权限的匿名用户

创建新集群时，需要考虑四件事：1）API 服务器是否暴露在互联网上；2）谁被授权与集群通信；3）他们拥有哪些特权；4) 是否有任何进一步的访问控制。在许多情况下（在本机 K8s 环境中，甚至在某些云提供商的托管集群中），集群默认设置为对互联网开放，并且有很多实际原因这样做。但是，这也意味着，如果扫描托管 API 服务器的 IP 地址，就会发现这是一个 K8s 集群，任何人都可以尝试连接到该集群。

此外，在许多情况下，默认情况下会启用对 K8s 集群的未经身份验证的请求。这意味着集群将接收来自任何人的请求。但是，默认情况下，匿名用户的请求没有权限。因此，它们将导致 403 回复，从而禁止访问。最后，准入控制需要有人主动创建。

该团队已经看到了从业者将匿名用户角色与其他角色（通常是管理员角色）绑定的案例，这将他们的集群置于危险之中。这些错误配置的混合可能会让攻击者获得对 Kubernetes 集群的未经授权的访问，从而可能危及在集群上以及其他环境中运行的所有应用程序。

因此，您的组织可能只需一个 YAML 就可以避免灾难。一个简单的错误配置、一个简单的错误都可能导致集群暴露。这是一个现实世界中的错误示例：

2.“Kubectl 代理”命令

Nautilus 观察到的另一个错误配置以前从未见过或发布过：“kubectl proxy”命令。使用具有特定标志的“kubectl proxy”命令时。一些出版物鼓励从业者出于多种目的使用“kubectl proxy”命令。例如，有一些关于 Kubernetes Dashboard 安装的教程鼓励用户运行代理命令，并且没有明确警告可能的影响。

运行“kubectl proxy”时，您会将经过授权和身份验证的请求转发到 API 服务器。当使用以下标志“--address=`0.0.0.0` --accept-hosts `.*`”运行命令“kubectl proxy”时，工作站上的代理现在将监听并将经过授权和身份验证的请求转发到 API从任何对工作站有 HTTP 访问权限的主机上的服务器，如下图所示。注意：权限与运行“kubectl proxy”命令的用户的权限相同。

威胁是真实的

Aqua Nautilus 记录了许多针对其蜜罐的野外攻击，凸显了暴露的 K8s 集群所面临的威胁。事实上，60% 的集群正受到加密货币矿工的攻击。三个主要例子是 Lchaia/xmrig、SSWW 攻击和 Dero 活动。研究人员还发现了RBAC Buster 活动，该活动利用 RBAC 创建一个非常隐蔽的后门。最后，该团队报告了 TeamTNT 发起的一项新颖的高度攻击性的活动（第 1 部分，第 2 部分）。在此活动中，TeamTNT 正在搜索并收集云服务提供商代币（AWS、Azure、GCP 等）。

缓解建议

为了避免针对这些错误配置的大量活跃威胁活动的风险，保护云资源和集群，Nautilus 建议组织遵循以下五个步骤：

1. 培训员工：组织必须投资培训员工，了解潜在风险、最佳实践和正确配置。这将最大限度地减少导致此类错误配置的人为错误。

2. 保护“kubectl proxy”：确保“kubectl proxy”不暴露在互联网上。它应该设置在安全的网络环境中，并且只能由经过身份验证和授权的用户访问。

3. 使用基于角色的访问控制 (RBAC)：RBAC 是一项原生 Kubernetes 功能，可以限制谁可以访问 Kubernetes API 以及他们拥有哪些权限。避免将管理员角色分配给匿名用户。确保为每个用户分配适当的权限，并严格遵守最小权限原则。

4. 实施准入控制策略：Kubernetes准入控制器可以在持久化之前拦截对Kubernetes API服务器的请求，使您能够定义和实施增强安全性的策略。该团队强烈建议采用准入控制来防止将任何角色与匿名角色绑定，这将强化 Kubernetes 集群的安全状况。

5. 定期审核：对 Kubernetes 集群进行定期审核。这使您可以跟踪集群中执行的每个操作，帮助识别异常并采取快速补救措施。

通过采用这些缓解策略，组织可以显着增强其 Kubernetes 安全性，确保其集群免受常见攻击。

随着 Kubernetes 的发展和被更多企业使用，从业者必须熟悉它可能给组织带来的风险。重要的是要记住，K8s 中的安全性并不是静态的、一劳永逸的情况。集群中不断发生操作和事件，仅仅因为您的集群昨天是安全的，并不意味着它今天仍然安全。因此，手动检查集群是否存在已知的错误配置是不够的。如果您的组织使用 K8s，如果您不主动扫描，那么总会存在风险。

---

作者：Assaf Morag

更多技术干货请关注公号【云原生数据库】

squids.cn，云数据库RDS，迁移工具DBMotion，云备份DBTwin等数据库生态工具。