怎么在 2022 年加强 Kubernetes 的安全性
发布时间：2022-08-03 13:34:28 所属栏目：云计算 来源：互联网
导读：Kubernetes 现在是最流行的容器编排平台。世界上的 Mesoses 和 Docker Swarms 几乎消失了，老实说，我不会想念他们的。但其市场主导地位的不利之处在于，Kubernetes 也成为想要损害其安全性的不良行为者的严重目标。 一些可悲的事实：容器安全处于糟糕的状态
|
Kubernetes 现在是最流行的容器编排平台。世界上的 Mesoses 和 Docker Swarms 几乎消失了，老实说，我不会想念他们的。但其市场主导地位的不利之处在于，Kubernetes 也成为想要损害其安全性的不良行为者的严重目标。 一些可悲的事实：容器安全处于糟糕的状态 目前有 56% 的开发人员甚至没有扫描他们的容器！ Gartner 预计，到 2023 年，超过70% 的公司将运行容器化应用程序。 根据红帽 2022 年的一份报告，错误配置占所有 Kubernetes 安全事件的 59% 。 作为一个社区，我们需要为此做点什么！ 2022 NSA/CISA Kubernetes 强化指南总结 最初于 2021/8/3 日发布，然后由 NSA 和 CISA 于 2022 年 3 月 15 日更新的技术报告“Kubernetes 强化指南”在这里为您提供帮助！对于依赖 Kubernetes 作为容器平台的组织来说，这是一份非常好的文档。它提供了有关如何保护平台的详细信息和动手示例。 我将在此总结技术报告的主要要点，并根据我在云安全方面的个人经验提供额外的见解。 扫描容器和 Pod 以查找漏洞或错误配置 为什么我们喜欢容器是因为镜像是一个软件及其所有依赖项的不可变包。不变性是一种资产，因为同一个容器可以接受质量保证流程，并从开发升级到生产，而无需任何更改。但这也是一种负担，因为容器镜像是软件时间胶囊：它们不会在发现新漏洞时自动获取更新。 扫描容器镜像中的已知漏洞是一种安全最佳实践（尽管只有 44% 的开发人员这样做）。但大多数只是在最初将镜像推送到注册表时扫描图像。这就产生了一个问题。因为应用程序越稳定，它更新的频率就越低，从而无法经常被推送到注册表。 具有讽刺意味的是，稳定性使得容器镜像更容易在更新之间变得脆弱。 作为缓解措施，NSA/CISA 报告建议使用 Kubernetes 准入控制器，该控制器将在 Pod 部署时请求扫描。但是仔细想想，这会遇到同样的问题：如果长时间部署不经常更新的应用程序，那么这种额外的部署时检查将无法适当地保护长时间运行的应用程序。 这就是为什么我强烈建议建立一个流程来定期确定哪些容器部署到您的集群，并定期扫描这些镜像。只需安排每天循环一次 Pod 并让注册表扫描其中的容器映像。这样，您的扫描结果是最新且准确的。 以尽可能少的权限运行容器和 Pod 从第一天开始，Kubernetes 和容器运行时的默认安全状态就非常松懈。而在一个2/3 的内部威胁是由疏忽造成的世界中，让软件或用户拥有过于广泛的权限，无疑是疏忽大意！ 容器中的默认用户是系统管理员 root 用户。您必须手动选择退出。Kubernetes 对容器化应用程序的功能几乎没有任何额外限制。因此，如果针对 Kubernetes 容器平台中的应用程序的网络攻击成功，则授予参与者的权限和权限集非常广泛。 为降低风险，应制定政策以确保并强制执行： 容器不会以“root”用户身份运行（如果可能，容器运行时本身也不会——默认用户会这样做），以限制应用程序的权限，从而限制黑客攻击的行为； 容器文件系统是不可变的，以防止不良行为者擦除其攻击轨迹； 最严格的 Pod 安全策略（Kubernetes v1.21 以上）或 Pod 安全标准（Kubernetes v1.22+）用于，例如，以非 root 用户身份运行，并禁止特权升级以本质上成为 root 用户，以及访问容器主机操作系统； 默认服务帐户令牌不需要对 Pod 进行访问，因为它们可能会比您预期的更多地访问 Kubernetes 集群的 API。您的应用程序可能甚至不需要这个，那么为什么默认情况下它存在呢？ 我认为这些基线政策应该始终到位是不言而喻的。但是您可能也有更多的政策。那些对您的组织来说是特别的。为此，我全心全意地推荐使用 Kubernetes 中可用的配置以及Open Policy Agent (OPA)。通过受官方库或第三方政策启发的配置，它可以根据每个请求强制执行所有政策事项。 使用网络分离来控制妥协可能造成的损害程度 Kubernetes 中的默认网络设置允许 Pod 自由地相互连接，而不管它们部署在哪个命名空间中。这种免费的网络方法意味着不良行为者只需进入单个 Pod 即可获得不受限制的访问给其他人。因此，整个平台仅与最不安全的组件一样安全，而坏人所要做的就是通过您最不安全的组件进入。然后，剩下的就是历史了。 Kubernetes 网络策略对网络施加了可配置的限制。这些实现方式因使用的容器网络接口 (CNI)提供程序而异，但本质上变成了 Kubernetes 资源感知防火墙规则。这可以很容易地指定只有“后端组件”才能调用“数据库”，而不是其他任何东西。因此，API 网关的弱点并不意味着可以轻松地对平台中的任何组件发起攻击。 使用防火墙限制不必要的网络连接和加密以保护机密性 Kubernetes 容器平台由一个控制平面和一组工作节点组成。控制平面节点托管控制整个集群的组件。因此，设法控制控制平面的不良行为者因此可以进行任意后续攻击并完全命令集群进行欺骗。 通过防火墙的网络外围防御可以帮助缓解来自（外部）恶意威胁参与者的此类攻击。控制平面的任何组件（Kubernetes API、etcd、控制器管理器等）的暴露程度都不应超过满足组织需求的绝对必要程度。 另请注意，Kubernetes 集群内的网络流量通常未加密。这意味着敏感信息可能会被不法分子设法放置在容器平台中的软件获取和利用。为了防止此类攻击，可以对集群中的所有流量进行加密。如果集群使用提供加密作为配置选项的 CNI 提供程序，这是一个相当微不足道且完全透明的更改。例如，Calico 可以通过利用 WireGuard 来做到这一点。如果您不能充分信任底层网络以满足您的信息安全需求，建议您这样做。 使用强身份验证和授权来限制用户和管理员访问以及限制攻击面 Kubernetes 容器平台在其 API 服务器中具有基于角色的访问控制功能。但是，出于某种原因，这些必须显式激活。此外，典型的 Kubernetes 安装为安装集群的人提供了一个永不过期的系统管理员“令牌”。使用此令牌可提供对集群的完全且永久的访问权限。猜猜我对此有何感想？ 尽管默认情况下未启用，但 Kubernetes 支持通过各种方法进行身份验证。有各种各样的，但我强烈建议使用 OpenID Connect 令牌。您可以与许多身份提供者服务集成，并且大多数支持发出此类令牌。它们还可以包含有关用户所在组的信息，因此可以在组级别设置基于角色的访问控制规则。对于那些不这样做的人，Keycloak或Dex IdP可能可以与它们集成。 并且希望（并且慷慨地）被视为易于使用的错误尝试，Kubernetes 默认还支持匿名请求。这应该毫无疑问地被关闭。 应该启用和配置基于角色的访问控制以遵守最小权限原则。就像这样，只应向软件和用户授予最小的特权集，并且应根据请求审查任何额外的特权请求。 如您所知，我确实建议 (a) 禁用管理员令牌，(b) 启用 OpenID Connect，(b) 禁用匿名访问，以及 (d) 启用基于角色的访问控制。并且，（e）您实际上尽可能地限制权限。 开启日志审计，以便管理员可以监控活动并提醒潜在的恶意活动 Kubernetes 控制平面内置了审计日志记录功能。但是，同样（注意这里的主题？），它们必须通过配置显式启用。就像 Kubernetes Hardening Guidance 技术报告一样，我当然也建议启用这些，这样操作员就可以深入了解他们集群中发生的事情。 然而，仅仅启用一个非常频繁的日志流（所有针对 Kubernetes API 的自动请求也会留下审计线索）只是提供了大海捞针。大海捞针需要实际解析和使用这些日志。这可以通过在您的日志存储解决方案（例如 Opensearch、Splunk 或 DataDog）中过滤表达式来完成，也可以通过自动化系统（例如CNCF 项目 Falco ）的自动和策略感知解析来完成。它可以与日志处理服务一起充当自动化安全事件和事件管理 (SIEM) 系统。 定期检查所有 Kubernetes 设置并使用漏洞扫描来确保适当考虑风险并应用安全补丁 Kubernetes每年大约发布 3 次新版本的容器平台。仅针对当前版本和之前的两个版本提供安全更新。因此，为了保持最新的安全性，运营商必须每年至少安装一次新版本。最好他们会遵循每个新版本，因为我会亲切地称之为过去相当幼稚的安全功能正在逐渐改进。 我希望我现在已经说清楚了：默认情况下，Kubernetes 并不安全。禁用的安全功能的数量表明，默认情况下有意不考虑安全性。新的安全威胁不断出现。因此，强烈建议使用整个平台的自动漏洞扫描，包括控制平面和工作节点本身。发现问题，立马告警。 不过，有一个问题。自动化测试能抓住一切吗？不，绝对不是。但它确实捕获了一些更明显的错误，如果被不良行为者发现，则表明该平台也可能在其他方面配置不当。以我的经验，即使不照顾低垂的果实也是一个巨大的“欢迎”标志。 自动化漏洞工具是否足够？ 许多工具承诺自动扫描容器镜像以及 Kubernetes 集群的配置或其中管理的资源的漏洞。这些提供了一个吸引人的产品，因为它们将突出错误配置。但它们的范围和功能有限。它们没有（技术上也不能）涵盖 NSA/CISA Kubernetes 强化指南建议的所有内容。 安全公司 ARMO 发布了Kubescape。它声称是第一个根据 NSA/CISA 技术报告中的最佳实践验证集群的工具。事实上，在撰写本文时，它确实包含一组很好的自动化测试。 它使用 Kubernetes API，现在，截至 2022 年，它还使用主机级检查功能来执行检查。这使它可以访问大量可以检查的配置。但是，存在限制：一般情况下无法验证，例如容器注册表中的容器镜像漏洞扫描策略是否生效，审计日志是否自动审核，节点之间是否有防火墙，或者是否有最严格的权限限制您的组织在虚拟机或云级别上就位。所有这些都需要对组织政策和流程有更多的了解，而不是期望一个工具拥有它是合理的。 自 Kubescape 成立以来，2022 年的最新更新大大扩展了 Kubescape 的范围，例如拥有自己的镜像扫描功能、RBAC 可视化器和调查器、辅助修复等等。它还与谷歌云集成，因此可以从那里收集信息。鉴于 ARMO 在 2022 年 4 月成功筹集了 3000 万美元的 A 轮融资，Kubescape 可以做的广度和深度似乎只会显着增加。 Aqua Security 也同样发布了kube-bench。它可以通过检查控制平面主机上正在运行的进程来检查控制平面的配置方式。不幸的是，它无法检查不属于 Kubernetes 配置的安全功能。 因此答案是“否”。一个人不能仅仅运行自动检查并声称拥有完美（甚至是良好）的安全态势。还需要对安全策略的实际理解，以及不仅仅是集群本身，而是更广阔的视野。 超越 NSA/CISA Kubernetes 强化指南 防止配置错误，不要只检查它 基于角色的访问控制 (RBAC) 可以确定谁可以在什么情况下做什么。但仅仅因为一条规则说 Lars 可以在“生产环境”中“更新配置”，并不意味着他可以无限制地访问——还必须防止 Lars 犯错误。毕竟，三分之二的内部威胁是由于疏忽造成的。 与大多数云系统一样，Kubernetes 仅附带一个系统来强制执行 RBAC，但没有强制执行限制用户实际操作的合理策略。 事后检查错误配置是某些系统提供的功能；AWS Config现在看到了一些用于此目的的牵引力。 但我更希望有一个完全防止错误配置的系统。策略应以自动可执行的形式编码。CNCF 项目开放策略代理(OPA) 可以做到这一点。它可以充当Kubernetes 准入控制器，因此可以确保不会违反策略。OPA 用途广泛；您可以从官方图书馆学习或从其他现成的政策中进行选择，并以此为基础。 给予应用程序的任何权限也会给予不良行为者 如果不良行为者设法破坏您的应用程序，他们将拥有与应用程序完全相同的权限。也许这看起来很明显。但我的经验告诉我，这在实践中并没有被认真对待。坏人将拥有 Kubernetes 容器平台、网络、云、第三方 SaaS 集成、连接 VPN 的后台位置中的所有功能——所有功能。 毕竟，这就是像勒索软件这样的坏东西设法传播的方式。它们只感染网络应用程序中的一个点，然后继续传播。链条的强度实际上取决于其最薄弱的环节。 如果我们真的考虑到这一点，那么您的 REST API 组件应该拥有任何权限，除了处理请求和发回响应之外，应该没有任何其它权限。  （编辑：开发网_郴州站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
浙公网安备 33038102330466号