行业新闻与博客

越来越多的已部署容器意味着不断发展和扩展的生态系统。对于组织来说，这也意味着更多的挑战和安全考虑。我们将剖析其中一些挑战，并为您提供可以使用的解决方案   

许多组织正在转向软件容器以促进其数字化转型。根据 Docker 的定义，容器是将应用程序代码及其所有依赖项打包在一起的软件单元。容器确保一致性；根据设计，它们具有特定版本的编程语言，软件库以及其应用程序需要运行的所有其他资源，而与基础主机基础结构或操作系统版本无关。这些软件单元还可以在 OS 级别进行虚拟化，这一特性使它们轻巧，启动更快，维护成本更低。

意识到这些好处，组织部署越来越多的容器就不足为奇了。在云计算原住民基金会（CNCF）在 2019 调查得知的运行 250+ 容器组织的比例已经由 28％，是自上年同期增长，例如发现。那是第一年，一半以上的接受调查的组织告诉 CNCF 他们正在运行这么多容器。

但是，组织在使用这些类型的容器时遇到的三个最常见的安全挑战是什么？您的企业可以采取哪些措施来缓解这种情况？

让我们将其散列出来。

容器编排和 Kubernetes

大量的容器带来了一个挑战：运行所有这些工作负载和服务所需的操作工作。组织无法手动执行该工作。这样做将无谓地浪费时间和金钱，而花费很少的钱就可以实现自动化。

这就是容器编排背后的理念：通过推动部署，供应，网络和容器生命周期的其他元素，容器编排简化了组织在管理容器方面必须付出的努力。VMware 指出，它还可以帮助组织扩展其容器化的工作负载，从而提高这些容器所支持的应用程序的弹性。

CNCF 发现，大多数组织（78％）专门使用 Kubernetes 来满足其容器编排需求。Kubernetes 是一个开放源代码，可扩展的平台，使组织可以使用声明式配置和自动化来管理其容器。它通过以下方式做到这一点：

• 使用负载平衡来分发容器网络流量，并通过
• 使组织能够为 Kubernetes 中已部署的容器描述所需的状态。

然后，平台将状态变为实际状态，并将环境的实际状态调整回受控状态，同时重新启动发生故障的容器和 / 或杀死对用户定义的运行状况检查没有响应的容器。

安全问题

只有一个问题：Kubernetes 安全事件正在上升。在 2020年秋季的“容器和 Kubernetes 安全状态”报告中，StackRox 发现 90％的受访者在上一年中经历了涉及其容器和 Kubernetes 环境的安全事件。他们带来的这些经历和安全问题促使接近一半（44％）的调查参与者推迟了将其应用程序投入生产的过程。

让我们以另一种方式来构造这些调查结果：许多组织由于与 Kubernetes 相关的安全问题而推迟了其业务目标。那是一种无法支持的工作方式。组织需要让 Kubernetes 为他们工作，以便他们可以继续发展业务。他们不能允许安全性将它们放回原处。

可持续发展的唯一方法是组织积极应对一些最常见的 Kubernetes 安全挑战。这篇博客文章将讨论 Kubernetes 的三个常见安全挑战，并提供组织可以用来解决这些挑战的最佳实践。（这些挑战没有排名，而是按字母顺序列出。）

挑战 1：沟通

整个 Kubernetes 平台归结为 Pod 或一组一个或多个容器。根据平台的文档，Pod 是组织可以在 Kubernetes 中创建和管理的最小可部署单元。因此，组织的 Kubernetes 安全性工作应该在这里开始是合适的。

首先，存在豆荚通讯的问题。Kubernetes 的文档在其他地方指出，默认情况下所有 pod 都是非隔离的，并且可以接受来自任何来源的流量。就访问控制而言，这是一个问题。确实，恶意行为者可以滥用这一事实来破坏 Pod，然后使用其通信属性移动到同一名称空间中的所有其他 Pod。

了解网络策略的用途

组织需要使用网络策略来塑造 Pod 通信流的方式。通过这些以应用程序为中心的构造，组织可以指定允许其 pod 与哪些网络实体进行通信。此过程涉及三个标识符的使用：

1. 允许与选定的 Pod 通信的其他 Pod 的列表；
2. 允许哪些虚拟集群或“名称空间”；和
3. 哪些 IP 地址被阻止。

在选择器的帮助下，组织可以指定允许从某个 Pod 或一组 Pod 进出的流量。这使网络策略“选择”那些资源并拒绝从标识的名称空间外部发出的任何连接。这样，网络策略会将它们与其他名称空间中的其他 Pod 隔离开来。

同样重要的是要注意，网络策略不会冲突。它们是添加剂。因此，如果组织为一个以上的网络策略选择一个 Pod，则该 Pod 被允许根据那些策略的并集进行通信。

网络策略的一些常见示例包括：

• 默认拒绝所有入口流量：此类型的网络策略充当所选名称空间中所有 Pod 的默认隔离策略。它可防止入口流量到达它们，即使其他网络策略未选择它们也是如此。名称空间中的默认出口行为保持不变。
• 默认情况下，允许所有入口流量：默认情况下，这种网络策略类型允许名称空间内的所有入口流量。即使组织决定创建其他网络策略来选择该名称空间的某些 pod 并施加隔离它们的条件，这种情况仍将保持。
• 默认拒绝所有出口流量：在这种类型的网络策略下，组织默认情况下会选择名称空间中的所有 Pod，并阻止来自这些 Pod 的出口流量。但是，实施这种类型的网络策略不会更改默认的入口行为。
• 默认允许所有出口流量：组织可以创建默认允许网络策略，默认情况下允许名称空间内的所有出口流量。引入限制某些策略的出口流量的后续网络策略不会更改该默认行为。
• 默认拒绝所有进入和流出所有流量：最后，组织可以创建一个默认网络策略，该策略禁止名称空间内的进入和流出流量。这将防止名称空间的默认网络策略未选择的 Pod 上的入站和出站流量。

挑战 2：配置错误

在之前引用的 StackRox 的调查中，有 67％的受访者表示他们在过去 12 个月内经历了配置错误事件。另有 22％的调查参与者报告了需要修复的主要漏洞。其次是检测到运行时事件的人员（17％）和未通过审核的人员（16％）。

StackRox 在其博客上解释说，这里的问题与网络复杂性有关：

“在一个由数百个不同的开发人员创建的，跨越数十个，数百个甚至数千个节点的几个集群的庞大 Kubernetes 环境中，手动检查配置是不可行的。和所有人一样，开发人员可能会犯错误-特别是考虑到 Kubernetes 配置选项很复杂，并且默认情况下未启用安全功能……。”

复杂性很危险，因为它使攻击者可以选择使用错误配置的设置来建立组织环境中的立足点，并利用其访问权限来获取敏感数据。因此，组织之所以需要注意以符合其安全要求的方式正确配置其 Kubernetes 的原因。使用网络策略限制 Pod 通信是其中的关键部分，但是组织还需要使用 Pod 安全策略（PSP）安全地配置 Pod。

Pod 安全策略如何工作

根据 Kubernetes 的文档，容器安全策略是集群级资源，用于定义允许容器在系统中运行的条件。PSP 封装了所谓的“安全上下文”，即对 Pod 或容器的特权和访问控制的定义。

这些安全性上下文包括 Linux 功能，或者 Pod / 容器是否获得某些特权而不是 root 用户的特权，以及 AllowPrivilegeEscalation，它指定 Pod 或容器能否获得比其父进程更多的特权。

组织可以通过创建与 Pod 中包含的内容相匹配的策略来最好地利用 PSP。为此，他们可以创建三种类型的 PSP：

• 特权：具有特权的 PSP 在允许其他任何 PSP 类型中拥有最多权限的意义上不受限制。特权 PSP 通常针对由受信任用户管理的系统级和基础结构级服务，允许特权升级。组织可以通过不应用任何约束而不是创建特定策略来创建此类策略。
• 基准 / 默认值：属于此类别的 PSP 受到更多限制，阻止特权升级。通常，非关键应用程序的应用程序运营商和开发人员使用这些类型的 PSP。
• 受限：最后但并非最不重要的一点是，受限的 PSP 受到严重限制。他们面向安全性关键应用程序的运营商和开发人员以及低信任度用户。

挑战 3：运行时威胁

最后，组织需要意识到运行时安全威胁。Tripwire 解释说，运行时安全性是实时发生的。随后，受威胁的容器可以执行另一个过程，该过程会影响其他容器或系统（如果不是大型企业网络）。

组织可以通过监视与安全相关的容器活动来应对这些挑战。特别是，他们应注意网络流量，以限制其网络策略所规定的不必要或不安全的通信。然后，他们可以使用发现的内容进一步加强网络策略的条件。

但是他们的工作并没有就此结束。组织可以将此监视和可见性与进程允许列表配合使用，以帮助识别意外运行的容器进程。此外，他们可以监视正在运行的部署中是否存在新漏洞，并扫描容器映像中是否存在现有安全漏洞，以最大程度地减少攻击面。

意识有很长的路要走

正如上面的讨论所表明的那样，Kubernetes 确实承担了相当多的安全挑战。但是，组织可以使用适当的意识和平台的内置功能来面对这些障碍并增强其安全性。