导语

疫情过后经济处在缓慢复苏的阶段，对于企业应该优先考虑数字化转型，因为它可以促进增长和创新。不可避免地，当今的数字化转型计划依赖于云的可扩展性和灵活性。虽然在云中启动应用程序和服务带来了许多机遇，但也带来了新的挑战。当许多组织将生产工作负载转移到 Kubernetes 时，管理安全性可能会很困难。在 Kubernetes 这样复杂的新环境中，很难快速弄清楚如何保护开源容器编排系统的所有方面。随着时间的推移跟踪和监控工作负载安全性可能会带来额外的挑战。

在最近的一份 CNCF 报告中，96% 的受访者表示他们正在使用或评估 Kubernetes，这清楚地表明采用率正在上升。然而，与任何其他新技术一样，与最佳实践保持一致可能很困难。不幸的是，这种不一致会带来一些问题：

安全风险增加
不受监控和不受管理的云成本
降低云应用程序和服务的可靠性

Kubernetes 的许多设置配置中安全性正朝着错误的方向发展，基于《kubernetes benchmark report 2023》我们来看看一些重要风险隐患。

使用不安全的功能运行

我们经常听到“默认安全”这个词，以至于一些开发人员可能已经开始期待在更新的技术中使用它。对于 Kubernetes，默认情况下它是不安全的。例如，默认情况下，某些 Linux 功能会为 Kubernetes 工作负载启用，即使这些工作负载不需要这些功能。基准数据表明，组织并没有像以前那样限制这些能力。 2021 年，42% 的组织针对大多数工作负载关闭了这些功能（仅影响 0-10% 的工作负载）。在过去的一年里，这一数字下降到 10% 的组织。

允许可写文件系统

您可以使用安全设置 readOnlyRootFilesystem 来防止容器写入其文件系统。启用此设置后，攻击者无法篡改应用程序或将外部可执行文件写入磁盘。默认情况下，此安全设置在 Kubernetes 工作负载上未设置为 true，因此明确更改设置以确保尽可能安全的配置至关重要。在 2022 年的基准测试中，只有 23% 的组织没有为 71%-100% 的工作负载覆盖不安全的默认设置。 56% 的组织未能在 2022 年实现这一超越。

允许特权升级

有一些配置允许容器提升它们的权限。将 allowPrivilegeEscalation 设置为 false 以在容器进程上设置 no_new_privs 标志。这可以防止 setuid 二进制文件更改有效用户 ID。使用 runAsNonRoot 时更改该设置至关重要。同样，您必须有意更改此设置以提高 Kubernetes 工作负载的安全性。最新报告显示，只有 10% 的组织锁定了大部分工作负载，而 2021 年这一比例为 42%。

启用特权模式

使用 privileged 命令判断 Pod 中的容器是否可以启用特权模式。虽然默认情况下容器可能无法访问主机，但特权容器可以访问主机。如果您启用了此功能，则容器与主机上运行的进程具有（几乎）相同级别的访问权限。当容器需要使用 Linux 功能（例如访问设备或操纵网络堆栈）时，该功能可能很有用。默认情况下，特权标志是关闭的。不出所料，到 2022 年，87% 的组织正在运行关闭特权标志的工作负载。

允许以根用户身份运行

根据基准报告，许多工作负载都允许使用此功能。不幸的是，到 2022 年，允许以 root 身份运行的工作负载数量有所增加。分析显示，44% 的组织正在运行 71% 或更多的工作负载允许 root 访问，而 2021 年这一比例为 22%。

使用易受攻击的镜像

容器是由软件组成的，新的常见漏洞和暴露（CVE）经常被披露。如果您没有定期扫描容器镜像中的漏洞，它们很可能存在于您的容器镜像和已部署的容器中。到 2021 年，40% 的组织受到镜像漏洞影响的工作负载不到 10%，而到 2022 年，这一比例仅为 12%。恶意行为者的一种常见攻击媒介是已知漏洞，因此识别和修复这些漏洞是对 Kubernetes 工作负载安全很重要。

过时的 Helm 图表和容器镜像

过时的 Helm 图表是许多组织的常见问题。基准报告显示，到 2022 年，46% 的组织有 50% 或更多的工作负载受到从过时的 Helm 图表运行工作负载的影响。跟上 Helm 图表的更新可能具有挑战性，因为发布周期可能无法预测。

2022 年将过时的容器映像添加到基准测试中。该数据显示 59% 的工作负载仅受到 0-10% 的影响，这很好——但 33% 的工作负载受到 91-100% 的影响。这留下了很多过时的容器镜像。使容器保持最新有助于最大程度地减少包含漏洞的容器数量，因此了解您的容器映像是否是最新的非常重要。

弃用的 API 版本

大多数组织只有少数工作负载具有已弃用的 API 版本。基准数据显示，2022 年，74% 的组织为其大部分工作负载更新了 API 版本，而 2021 年这一比例为 82%。查找和更新或删除已弃用的 API 是降低 Kubernetes 升级期间风险的关键步骤。

总结

毫无疑问，Kubernetes 安全配置仍然是一个挑战，，向容器和 Kubernetes 的转变为组织带来了巨大的价值。今天的挑战是许多组织正在迅速采用 Kubernetes并向 Kubernetes 部署更多的应用程序，但与此同时，许多组织还不了解许多可用的配置以及如何适当地设置它们。使用 Kubernetes benchmark了解 Kubernetes 在默认情况下不安全的地方，如何进行更改以使您的 Kubernetes 工作负载更安全。