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 组件应该拥有任何权限，除了处理请求和发回响应之外，应该没有任何其它权限。
牢记云资源
我们都看到了头条新闻。无论是被错误配置为允许匿名访问的 S3 存储桶，还是允许访问任何客户数据库的 Microsoft Azure CosmosDB 的主密钥，信息都很明确。每当我们使用云资源时，我们必须始终牢记它们及其配置。
Kubernetes 生态系统中有各种控制器使云集成变得简单，简单就是伟大的！但绝不允许简单性损害安全性。因此，您必须确保这些控制器不会将幼稚的安全设置放在它们管理的资源上。您应该彻底拒绝那些没有明确宣传它们如何管理安全性的工具。包括没有指定他们需要哪些 IAM 权限的工具，以及那些没有公开配置他们将实施哪些权限的方法的工具。
您的应用程序是否无意中在云中拥有权限？
您是否授予云服务器访问权限以修改您的云资源？AWS称为实例配置文件（其他云提供商在不同名称下具有相同概念）授予虚拟机修改云资源的权限。通过在该虚拟机中运行，容器化应用程序也可以拥有它。它所需要做的只是对云的元数据服务进行一系列网络调用，并且它具有与您为服务器提供的相同级别的访问权限。因为它在服务器上运行，所以云将其视为“服务器”。
我一遍又一遍地看到人们会在这里和那里向服务器的实例配置文件添加一些权限，以使他们想做的任何事情都能正常工作。创建负载均衡器，更新一些 DNS 记录，修改自动伸缩组；之类的东西。但他们这样做只是为了支持他们的预期用例，而不是意识到所有非预期用例都将具有相同的权限。
定期扫描所有已部署的容器镜像
许多容器镜像仓库支持在推送镜像时扫描镜像。这很棒！NSA/CISA Kubernetes 强化指南建议准入控制器在部署时请求扫描。
但是，如果由于软件稳定而使镜像保持部署数周或数月怎么办？几周前的初始扫描可能是干净的，但今天的新扫描会显示漏洞。
相反，我坚决支持定期扫描主动部署到 Kubernetes 容器平台的所有容器镜像。通过确定所有已部署的容器映像版本并每天扫描它们来自动执行此检查。
这意味着您可以获得最新漏洞数据库的优势，以对抗不经常更新的稳定软件的旧容器镜像。如果扫描发现依赖项存在问题，您可以使用更新的依赖项重新构建镜像，并使用（希望）很少或没有其他更改来部署它，因为代码本身没有更改。
定期安全测试您的整个系统
您的软件工程师有一些外部威胁没有的东西：访问源代码。如果您还为他们提供时间和祝福来对您的系统进行安全测试，那么奇迹就会发生。
在过去的一个项目中，我深情地记得发现以自动化方式创建某种类型的资源会使整个系统戛然而止。一台笔记本电脑可以成功地对整个系统发起拒绝服务攻击，而不会做任何明显恶意的事情。
即使您的工程师本身可能没有接受过安全培训，主要思想是灌输安全第一的心态。这可能是一帆风顺和安全灾难之间的区别。
制定灾难恢复 (DR) 计划并进行实践
与我交谈过的公司数量之多，他们认为灾难恢复仅意味着“备份”，这令人震惊。提示：真的不是。备份是必要的，但还不够。
从灾难中恢复意味着能够在特定时间范围内在其他地方站起来整个技术堆栈。虽然通常认为灾难意味着整个云区域的中断，但我认为安全事件绝对算作灾难！由于您不再信任已部署的应用程序，因此您需要回答以下问题：您可以多快破坏整个基础架构并恢复到事件发生前的状态？
当被问到这个令人不安的问题时，仍然认为 DR 就等于“备份”的公司通常会承认，他们甚至不会定期尝试从这些备份中恢复。如果信息技术是您工作的核心，请认真对待这方面。
使用入侵检测系统 (IDS) 和安全信息和事件管理 (SIEM) 系统
Kubernetes Hardening Guidance 提到了这些，但实际上并没有告诉您如何处理它们或如何使用它们。
IDS 记录和监控应用程序的正常行为，并根据这些基线不断检查活动。如果应用程序开始以新的方式运行，则可能表明它已被不良行为者利用。例如，如果它开始尝试读取或写入文件，而它通常不这样做，这是一个非常好的迹象——它不像它自己开始那样做！
CNCF项目 Falco也可以帮助您遵循本指南。指定规则当然很麻烦，但提供应用程序需要的防护栏是必不可少的。您可以从社区提供的服务开始。
Falco 可以与例如 Elasticsearch 结合使用，检查您的（审计）日志，并以这种方式充当 SIEM。我也建议以这种方式使用它。如果您已经有一个不同的系统，那么一定要使用它。但是用点东西。由于当今的许多法规要求您通知用户有关数据泄露的信息，因此您确实需要一个有助于管理安全信息和事件的系统。安全日志数据量太大而无法手动处理，尤其是当您当前受到攻击时。
信息安全不是一次性的，它是一个持续的过程。威胁在不断演变，因此应对措施也必须如此。通过在我们的平台上设置护栏并不断努力为我们的应用程序和服务器提供最少的权限，我们可以减少我们的攻击面。
云的固有复杂性和动态特性为不良行为者提供了许多实施攻击和隐藏的场所。我们有责任限制这些机会。
结束的想法
Kubernetes 默认不安全，本身也不安全。您绝对可以而且必须加强其配置。云提供商提供的所谓“托管 Kubernetes 服务”几乎没有为您提供本文中包含的建议（如果有的话）。他们当然不会添加任何其他深度安全所需的工具。他们也没有兴趣这样做，根据他们的“责任共担模型”，他们负责云的安全，但您负责云中的安全。
