云原生应用的最小特权原则

作者：HummerCloud

2022-12-02
北京
本文字数：2447 字
阅读完需：约 8 分钟

IDC 预计，从现在到 2024 年初，将开发和部署 5 亿个新应用程序——超过过去 40 年的总和。 Gartner 预测，到 2025 年，75% 的企业将运行某种容器化应用程序。

现代应用程序需要现代安全性。公共云供应商非常积极地提升平台安全性，以保证他们的平台不会成为安全攻击的对象。

在云原生应用程序中，许多组件可能会纯在风险。如果单个组件受到威胁，整个应用程序也将面临风险，我们需要采取适当的安全方法来解决安全风险。

服务信任陷阱

云原生应用程序安全性的最大挑战之一是服务之间的信任。应用程序的一项服务能否相信另一项服务不会存在潜在风险？

我们经常会遇到这样的问题，同一应用程序中的不同服务在逻辑上应该能够相互信任，但从安全的角度这是一个非常糟糕的设计。永远不要假设信任——即使是在同一家公司或开发团队构建的服务之间。

相反，服务不应访问它们不需要访问的任何组件。每个服务都应该只能访问完成其工作所需的生产系统的绝对最少部分。任何系统、应用程序或个人都不应该拥有对生产系统中所有内容的 100% 完整访问权限。

这种策略被称为最小特权原则，是所有现代云原生应用程序都应遵守的重要操作安全要求。

最小特权原则

什么是最小特权原则？最小权限原则 (PoLP) 是一种信息安全概念，即为用户提供执行其工作职责所需的最小权限等级或许可。

最小权限原则被广泛认为是网络安全的最佳实践，也是保护高价值数据和资产的特权访问的基本方式。

描述它的最简单方法是举一个实例。我们假设有一个由三个服务组成的简单应用程序：

其中两个服务使用它们之间的消息队列相互通信。服务 A 将消息插入队列，服务 B 从队列中读取和删除消息。服务 C 执行一些与服务 A 和 B 无关的其他操作。

在这种情况下，服务 A 负责将消息推入队列，服务 B 负责将消息从队列中拉出。因此，永远不会有服务 A 需要从队列中读取的情况，服务 B 也永远不需要将消息推送到队列中。此外，服务 C 永远不需要出于任何原因访问队列。

如果构成应用程序的所有服务都可以访问队列，那么服务 C 就可以访问队列，虽然它不需要访问权限。一般情况看来这似乎可以接受。毕竟，服务 C 是应用程序的一部分。为什么要花精力限制服务 C 访问队列呢？

但是，如果攻击者获得了服务 C 的访问权限会怎样？他可以访问服务 C，可以修改服务，让它在队列中插入虚假消息，假装它们来自服务 A。而服务 B 没有意识到这个问题，会读取错误消息。现在服务 B 也受到损害，很快攻击就会传播开来。

这里得到的经验是，由于服务 C 不需要访问队列，因此应该明确阻止它访问队列。在云原生应用程序中，这通常意味着需要将安全策略放在队列上以防止服务 C 访问队列

如果此应用程序部署在云中，则可以使用某些消息队列服务（例如 Amazon SQS 服务）轻松实现队列。无需额外处理如何限制队列。

最小特权原则的好处

减少了网络攻击面。 当今，大多数高级攻击都依赖于利用特权凭证。通过限制超级用户和管理员权限（使 IT 管理员可以不受限制地访问目标系统），最小权限执行有助于减少总体网络攻击面。
阻止了恶意软件的传播。 通过在端点上执行最小权限，恶意软件攻击（例如 SQL 注入攻击）将无法使用提升的特权来增加访问权限并横向移动以安装或执行恶意软件或损坏计算机。
提高了最终用户的生产率。移除业务用户的本地管理员权限有助于降低风险，但是基于策略启用即时特权提升有助于保持用户的工作效率并尽量减少 IT 服务台呼叫。
有助于简化合规性和审核。许多内部政策和法规要求都要求组织对特权帐户实施最低特权原则，以防止对关键系统的恶意或意外损坏。最小权限执行可以帮助组织证明对特权活动的完整审核跟踪的合规性。

将最小特权原则应用于 Kubernetes

Kubernetes 处理容器编排工作负载。它为组织和开发人员提供了一个自动部署、管理和扩展容器化应用程序的平台。这意味着各种开发、运营和 IT 团队成员在创建或维护已部署的应用程序时需要访问 Kubernetes 环境。

为了确保最佳的安全性和资源保护，组织在使用 Kubernetes 时需要在最小特权原则上运行，而不管当前的生产阶段如何。幸运的是，Kubernetes 提供了身份验证和授权来启用访问控制。在与 Kubernetes API 交互时，团队应该明确定义谁可以访问哪些操作资源和权限。此外，组织应禁用未经身份验证的访问，无论是通过人工还是服务帐户。

在使用 Kubernetes 的时候，Kubernetes 提供了基于角色的访问控制 (RBAC) ，用于根据环境中个人的角色定义资源权限。Kubernetes 设计了一套非常完整且健全的 RBAC 机制，使我们能够配置权限，以指定用户或用户组如何与集群中的任何 Kubernetes 对象交互。使用 RBAC 框架是在 Kubernetes 环境中实践最小特权原则的重要一步。

最小特权的 RBAC 实践

理想情况下，分配给用户和服务帐户的 RBAC 权限应该是最小的。仅应使用操作明确需要的权限，虽然每个集群会有所不同，但可以应用的一些常规规则：

尽可能在命名空间级别分配权限。授予用户在特定命名空间中的权限时使用 RoleBinding 而不是 ClusterRoleBinding。
尽可能避免通过通配符设置权限，尤其是对所有资源的权限。由于 Kubernetes 是一个可扩展的系统，因此通过通配符来授予访问权限不仅会授予集群中当前的所有对象类型，还包含所有未来被创建的所有对象类型。
管理员不应使用 cluster-admin 账号，除非特别需要。为低特权帐户提供伪装权限可以避免意外修改集群资源。
避免将用户添加到 system:masters 组。任何属于此组成员的用户都会绕过所有 RBAC 权限检查，始终具有不受限制的超级用户访问权限，并且不能通过删除 RoleBinding 或 ClusterRoleBinding 来取消其权限。顺便说一句，如果集群使用 Webhook 鉴权，此组的成员身份也会绕过该 Webhook（来自属于该组成员的用户的请求永远不会发送到 Webhook）。