Kubernetes 安全指南

在容器部署方面，Kubernetes 可以说是这个行业的领导者。据Statista报导，约 46%的受访者表示，他们会使用 Kubernetes 来实现计算机应用的部署、管理和扩展的自动化。

即使如此，在容器生命周期的阶段，我们仍需要注意一些安全问题。在开发和部署阶段，我们应采取措施缓解包括错误配置等已知漏洞的风险，而在运行阶段，我们还应有面对威胁时快速响应能力。

为此，企业应对 K8s 攻击树和其相关文档有深入的了解。攻击树本质上是一个树状视图形式的威胁模型，为潜在的安全威胁和对应缓解措施提供详细的可视化展示。

我们可以以这个威胁模型为参考，检查潜在安全漏洞，查找可能被黑客利用、对系统造成破坏的常见攻击向量。或利用攻击树测试 Kubernetes 的安全性，并在安全事件发生时获得输出日志的可见性。

但攻击树不是万能的，它只负责 Kubernetes 的安全性，不能保证端对端容器是否安全。在软件部署生命周期中添加的任何其他应用程序和组件也不在它监管的范围内。

当我们决定在生产环境中使用 Kubernetes 时，我们必须要考虑到系统的整体安全。根据美国国家安全局（NSA）发布的指南，常见安全威胁包含内部威胁、人为恶意攻击和供应链风险。

这就意味着我们必须要在项目的开始就建立 Kubernetes 的安全实践，这样才能更好地保护云基础架构的关键区域和云原生环境。

Kubernetes 攻击的种类

说起 Kubernetes 的攻击手段，大致可以分为三类：外部攻击者、恶意容器，以及被渗透的或恶意用户。

第一类：外部攻击者

为避免服务暴露在不信任的网络中，我们还需要对管理服务等控制措施的使用保持警惕。举例来说，一个没有集群访问权限的攻击者，在无需任何形式的认证协议的情况下，却可以以网络的形式直接接触到集群上运行的应用程序，甚至还有机会访问其管理接口。

第二类：恶意容器

如果攻击者成功攻陷一个容器，那么他们接下来会设法提高自己的权限，并最终接管整个集群。而如果我们没有有效的手段组织他们获取完整集群的管理权限，那么我们将只能坐以待毙。

这类风险的缓解措施是必须保证所有的端口都要在集群网络上可见，所有用户都要使用多重验证手段，并且避免容器中挂载服务账号，如果无可避免，确保账号权限受到限制。

通过使用各种网络策略，再加上 Magalix 的“策略即代码”，我们可以限制 pod 和命名空间的访问权限。

第三类：被渗透的或恶意用户

当我们忙于处理受损账户或恶意用户时，黑客盗窃的凭证仍旧有效，这时他们还可以执行命令攻击网络访问和 Kubernetes 的 API。缓解这类危险的策略和最佳实践是执行“最小特权”的策略，以及对所有用户采用基于角色的访问控制（RABC）。

主要攻击向量

在 2020 年，CNCF金融用户组发表了一个针对一般 Kubernetes 集群的威胁模型练习，主要为各类潜在威胁和其对应缓解措施提供一个详细的图解，并提供一个检查清单帮助团队识别 Kubernetes 集群内的常见漏洞和易被利用的点。

由 CNCF 提供的 Kubernetes 可信边界

借助STRIDE方法论，CNCF 分析了 Kubernetes 架构中的每一个元素，并总结出了一个平台内潜在安全问题的列表。STRIDE 是六类威胁的首字母缩写：伪装身份、篡改数据、拒绝承认、信息泄露、拒绝服务、权限提升。

其中一些主要的攻击向量有：

服务 Token

服务 Token 在一般情况下是默认挂载到每个 pod 上的，但如果黑客成功骇入任何一个容器，那么他们将可以使用同一个凭据进一步利用该容器。

若要缓解此风险，我们必须建立严格的 RBAS 策略，并禁用服务 Token 自动挂载的协议。

受损容器

集群内的远程执行点是黑客们的主要集火点之一。除了利用服务 Token 之外，其他的攻击向量还包括所有运行中容器上，默认暴露的网络控制面板。

网络端点

确保所有 Kubernetes 端点免受内部威胁，可以避免黑客利用攻击向量中的弱点。需要注意的是，如果黑客成功攻入一个容器，那么只要 pod 的网络策略允许，他们将迅速获得对端点的访问权限。

拒绝服务攻击（DOS）

在版本 1.14 发布之前，针对 DOS 攻击的缓解策略相对较少。

RBAC 的问题

RBAC 的错误配置可能会被利用并导致数据泄露，但开发团队可以借助自动化工具来验证和确认策略。

攻击树

CNCF 金融用户组提出了一套可能会协助确定集群内潜在攻击发起点的攻击树，并提出了两种可行方法：1. 自下至上。2. 基于情景。

自下至上的方法

这种方法通过找出所有 Kubernetes 平台的入点来达成目标。我们借此摸清所有的安全控制和标准，更好地了解他们的覆盖范围。

基于情景的方法

这种方法可以让我们确定在特定情况下暴露于威胁者的攻击向量，并将关注点更多地放在较为普遍攻击向量上。这种基于情景的方法虽然会借用自下至上方法中的大部分细节，但却更加基于现实情况。

以下展示的是 GitHub 上开源可用的攻击树总结：

自下至上：执行恶意代码

我们一般会选择在一个集群上执行恶意代码，但这也就意味着我们得毁掉一个提供容器访问的应用程序。

然而，威胁者只要可以访问容器，他们就会将更多的恶意代码加载到环境之中。如果威胁者拿到了获取镜像的权限，他们可能会污染仓库并将恶意代码扩散到其他分支。

自下至上：确定持久化

该攻击树的主要目标是探寻黑客访问集群的不同方式，并研究了其不同的寿命周期。

在这种情况下，一个分支会集中探查集群内的秘密，让黑客能发现其他的漏洞区域。另一个分支则侧重于黑客获取容器访问权限后的造成的威胁。攻击者会利用错误的配置，尝试建立对容器、节点或 Pod 重启持久且弹性的权限。

自下至上: 访问敏感数据

大多数的方法都是在利用配置错误的 RBAC 权限直接从集群中读取机密数据，另一部分则是通过查看查看日志中存储的所有数据等方式获取数据。可以说，这类方法几乎和窃听网络流量和通信数据差不多。

自下至上：拒绝服务攻击

此攻击树主要分析攻击者在集群上发起 DoS 攻击时采用的不同手段。第一种，需要一个受损容器为前提，攻击者会尝试从集群中发起 DoS，耗尽其所有资源。

第二种更关注拥有集群控制面板网络权限的威胁者。黑客会尝试在最合适的一个端点上发起冲击堵塞网络，并耗尽目标所有资源。

情景一：受损应用导致黑客在容器中立足

该场景重点介绍在利用容器内运行应用程序后，可能会暴露给黑客的攻击向量。黑客可以利用这些向量，通过编程或 shell 访问，远程在容器内执行代码。

情景二：通过网络的攻击

此情景侧重于内部威胁。拥有 Kubernetes 集群网络访问权限的内部攻击者，不用直接访问集群便能拥有多种用户权限。不过，合适的 Kubernetes 配置和防火墙可以迅速地应对这类大多数的威胁。

更多相关可参见Kubernetes安全审计工作组，以及他们将安全审计工作总结后公布的威胁模型以及白皮书。他们的关注点遍布 Kubernetes 集群的各个部分，这些文档值得我们花时间通读。

其他关于 Kubernetes 安全的最佳实践和推荐包括：

• （如果可能）始终以最小权限策略运行 Pod 和容器。

• 要求使用强身份验证和授权协议，限制管理员和用户访问权限（缩小攻击面）。

• 加密数据以确保机密性。

• 利用防火墙限制非必要链接。

• 应用网络分离控制来减少攻击造成的潜在损害。

• 通过日志审计监控容器活动。

• 定期检查所有设置，使用漏洞扫描工具识别潜在风险并安装安全补丁。

• 扫描 Pod 和容器，检查是否存在配置错误或漏洞。

利用 "策略即代码 "保护你的 K8s 环境

管理 Kubernetes 并预防黑客攻击载体需要大量的实践经验、配置和可维护性，即使是经验丰富的专家恐怕也会觉得颇具挑战。为此，Magalix 提供的最大的“策略即代码”可扩展库之一，力求简化管理安全 K8 的复杂性。

这些策略包括：- 容器不应以 root 权限运行- 容器不应共享 hostIPC- 容器不应使用 hostPort- 容器不应挂载 Docker 套接字- 容器不应缺失安全上下文- 容器不应缺失存活探针- 服务不应使用 NodePort- 禁止 RBAC 的动词通配符- 用 RBAC 的集群角色绑定保护集群管理员权限- 容器应将根文件系统挂载为只读

Magalix 还提供以编程方式，安全且符合规定地执行“策略即代码”标准，以开发者为中心，持续补充云原生应用程序的部署协议。这样，集群内的所有自动化操作都可通过监控仓库变化进行观测。

不仅如此，我们还可以通过一个集中的开发手册，让“策略即代码”贯彻整个软件开发生命周期，在不影响安全的情况下加速创新发展。

如果开发团队可以根据本文中提供的建议搭建开发云原生应用程序，那么环境的安全将得到保证，并提供更好的用户体验。

原文链接：

Kubernetes Main Attack Vectors Tree: An Explainer Guide