容器保护的三大挑战

219 阅读6分钟

开启掘金成长之旅!这是我参与「掘金日新计划 · 12 月更文挑战」的第27天,点击查看活动详情

在保护容器和容器化生态系统时存在一些陷阱。这篇文章将详细讨论前三大挑战,以便应对它们。

一种经济高效且不太复杂的虚拟机(容器)替代方案彻底改变了应用程序交付方法。它们显着减少了管理应用程序基础设施的 IT 劳动力和资源。然而,在保护容器和容器化生态系统的同时,软件团队遇到了许多障碍。特别是对于习惯于更传统的网络安全流程和策略的企业团队。我们通常吹捧容器提供更好的安全性,因为它们将应用程序与主机系统以及彼此隔离开来。在某些地方,它听起来像是天生安全,但这个想法有多牵强呢?让我们直接来详细了解。

容器中可能存在的脆弱因素 

  • 外部攻击者试图访问内部。
  • 对生产环境具有一定访问权限的内部攻击者(不一定是管理员)。 
  • 恶意内部因素是有特权的内部用户,比如可以访问部署的开发人员和管理员。
  • 可能意外导致问题的内部因素,例如不小心在容器映像中存储一些密钥或证书。
  • 通过引入一些新的服务或减少等待时间来增强客户体验,公司倾向于在服务器或防火墙中开放一些端口。如果没有彻底的保护,这可能会成为黑客的通道。

可能有多种途径损害你的容器安全性。让我们准确地讨论其中的一些因素。

挑战

一、容器镜像的问题

配置不当的容器镜像可能是引入漏洞的原因。当人们认为他们可以自己动手从云端下载并直接开始使用时,问题就开始了。我们应该知道,每天都会在云上引入新的漏洞。每个容器镜像都需要单独扫描以证明它是安全的。

要避免的一些已知问题

  • 如果映像启动允许未经授权的网络访问的无关守护程序或服务怎么办?
  • 如果它被配置为使用比必要更多的用户权限怎么办?
  • 另一个需要注意的危险是镜像中是否存储了任何密钥或凭证。

Tips:Docker 始终会将其自己的网络优先于你的本地网络。 

建议

  • 从受信任的容器注册表中拉取镜像。通常指的是私有注册中心,但不一定,除非它们是加密的并且具有经过身份验证的连接。这应该包括与现有网络安全控制联合的凭据。
  • 容器注册表应进行频繁的维护测试,以使其不存在任何具有无法消除漏洞的陈旧镜像。
  • 在将它们投入生产之前,软件团队需要通过蓝绿部署或容器更改的回滚来构建共享实践。

2.注意你的编排安全

在解决安全问题时,像 Kubernetes 这样流行的编排工具是不可或缺的。它已成为主要的攻击面。

当 Kubernetes 处理多个容器时,它在某种程度上暴露了一个很大的攻击面。当我们没有保护编排器的生态系统时,遵循全行业实践的字段级令牌化是不够的。因为敏感信息被解码和暴露只是时间问题。

建议

  • 确保 orchestrator 的管理界面被正确加密,这可以包括双因素身份验证和静态数据加密。
  • 将网络流量分离到离散的虚拟网络中。这种隔离应该根据传输的流量的敏感性来完成。(例如,面向公众的 Web 应用程序可以归类为低敏感度工作负载,而像税务报告软件这样的东西可以归类为高敏感度工作负载并将它们分开。这个想法是确保每个主机运行特定安全级别的容器。)
  • 最佳实践可以是坚持对集群节点之间的所有网络流量进行端到端加密,还包括集群成员之间经过身份验证的网络连接。
  • 我们的目标应该是将节点安全地引入集群,在每个节点的整个生命周期中保持一个持久的身份。(在不影响集群安全的情况下隔离/移除受感染的节点)。 

3. 防止“容器逃逸”

流行的容器运行时,如 containerd、CRI-O 和 rkt 可能已经随着时间的推移强化了它们的安全策略,但是,它们仍然有可能包含错误。这是一个需要考虑的重要方面,因为它们可以允许恶作剧代码在容器逃逸中运行到主机上。

在 2019 年,在 runC 中发现了一个名为Runscape的漏洞。

这个错误 ( CVE-2019-5736) 有可能使黑客能够脱离沙盒环境并授予对主机服务器的根访问权限。这导致整个基础设施受到损害。起初,他们假设它可能是一个恶意的 Docker 镜像,因为里面肯定有一个恶意进程。经过所有测试,他们意识到这是 runC 中的一个错误。

安全需要左移

在处理基于微服务的环境时,最佳实践是在每一步都引入自动化部署。如果我们仍然按照每周或每月的节奏手动执行部署,那么我们就不是敏捷的。要在应用程序交付中真正向左移动,我们需要创建一个现代的安全插件工具链及其在整个管道中的扩展。

它是这样工作的:如果镜像中存在任何漏洞,该过程应该在构建阶段就停止。应该对 RBAC 进行定期审计以监控所有访问级别。此外,所有工具和流程都应符合 CIS 基准。

一个好的方法是采用安全即代码实践,将 Kubernetes 原生 YAML 文件的安全清单编写为自定义资源定义。这些是人类可读的,并在运行时声明应用程序的安全状态。现在,可以将其推送到生产环境中并使用零信任模型进行保护。因此,管道外的代码永远不会有任何更改。

总结

如今,跨 CI/CD 管道的自动化安全流程和声明式零信任安全策略已成为当务之急。它们提高了开发人员的工作效率,并且是 DevOps 最佳实践的一部分。