我对那些间谍电影的唯一印象是美国国家安全局特工窃听美国境外通讯的场景。但这不是国家安全局所做的唯一工作。除此之外，美国国家安全局还为网络安全社区做出了贡献。
\ NSA 制作了最初的SELinux ，Linux 的可选强制访问控制(MAC) 架构。此外，他们还编写了有关在每个人都在远程工作时保护视频会议、测试和协作工具的指南。最近， NSA 更新了Kubernetes 强化指南，因此我想与您分享这些优秀的资源以及其他有关 K8S 安全性的最佳实践。
背景
强化指南的第一版于 2021 年 8 月发布，由美国国家安全局 (NSA) 撰写。该指南还由网络安全和基础设施安全局(CISA) 共同编写，旨在提高用户对关键威胁和配置的认识，以最大程度地降低风险。
\ 2022 年 3 月，NSA 更新了其Kubernetes 强化指南，该指南在今天更有价值。例如， NCC Group对 1.0 版本提出了若干意见。
NCC 发现第一版关于Kubernetes 身份验证的信息“很大程度上不正确”，因为它表示 Kubernetes 默认不提供身份验证方法（事实：K8S 原生支持令牌和证书身份验证。）
为什么要保护 K8S？ 2021 年云原生调查
根据云原生计算基金会(CNCF) 的2021 年云原生调查：
- 96% 的组织现在使用或正在评估 Kubernetes。
- 560 万开发人员正在使用 Kubernetes，约占全球的三分之一。
现在，在大量采用中，您认为有多少正确保护了 Kubernetes？不多。值得注意的是，Kubernetes 在默认配置下不提供“足够安全”。正如红帽指出的：
94% 的受访者承认他们在过去 12 个月中经历过 Kubernetes 和容器环境安全事件。
人为错误或配置错误是一个严重的问题。对手和我们一样都知道，我们现在正在转向容器和 Kubernetes，而且变化很快。正如NSA 所指出的，Kubernetes 集群是网络攻击的主要目标，包括：
- 数据盗窃，
- 计算能力盗窃（例如，用于加密挖掘），以及
- 拒绝服务攻击。 \n NSA 和 CISA 在发布强化指南时的联合公告称：
在 Kubernetes 中运行的应用程序及其第三方依赖项的安全性依赖于开发人员的可信度和开发基础设施的防御。来自第三方的恶意容器或应用程序可以为网络攻击者在集群中提供立足点。
\n目前， 数据盗窃是头号目标，其次是劫持 Kubernetes 集群进行加密挖掘。因此，如果默认保留 Kubernetes 安装，您可能会让黑客访问您在集群内的数据和计算能力。
漏洞——由内而外
与任何大型开源项目一样，Kubernetes 项目也存在多个安全漏洞。因此，了解新漏洞并制定计划在更新快速发布后修补 Kubernetes 至关重要。
:::tip 以下是在 K8S 中发现的已知漏洞列表：
:::
\ NSA 和 CISA 还特别指出了供应链威胁，包括在部署之前可能在供应链中受到损害的软件和硬件依赖关系——即使是最微小的错误也可能破坏系统。
一个值得注意的例子是最近导致严重故障的 Log4j 漏洞。 Log4j 实际上不是 K8S 中的一个组件，而是 Java，它在应用程序中被广泛采用。如您所见，重点不仅在于 K8S 本身的漏洞，还在于集群内部的所有组件。
Kubernetes 周围没有那么容易
我知道这些是基础知识，但这并不意味着它们很容易做到。例如，在 Kubernetes 环境中进行修补具有挑战性。除了 Kubernetes，还有许多其他程序在现实世界的应用程序中运行。如果简单的话，就没有使用 K8S 的地方了。它也适用于保护它。
让我们看一下root访问。我们都知道以 root 身份运行应用程序并不好。然而，许多Kubernetes 容器服务默认以 root 权限运行。结果，在其中运行的应用程序作为根继承。这是因为：
root 用户 (UID 0) 是容器内的默认用户。如果您不指定非 root 用户，则容器以 root 身份运行。由于公共存储库中的大多数容器映像都不会换出 root 用户，因此这种情况会持续下去。
强化指导的关键是标准的最佳实践。尽管如此，该报告还深入研究了在复杂环境中使用标准安全缓解措施，通常是在云中。
\
国家安全局的建议
让我们先了解一下基础知识！根据强化指南，在生产 K8S 环境中应该采取一些步骤。
- [ ]扫描容器和 Pod 中的漏洞或错误配置。
- [ ] 在容器和 Pod 中应用最小权限原则。
- [ ] 采用强身份验证和授权来限制用户访问并减少攻击面。
- [ ] 使用网络分段来减少被泄露的风险。
- [ ] 使用防火墙限制过多的网络访问。
- [ ] 使用加密来保护机密性。
- [ ]定期检查所有 Kubernetes 设置并使用漏洞扫描来解决可接受的安全风险。
- [ ] 最后，捕获和监控审计日志以提醒潜在的恶意活动。
这些只是在将容器化应用程序投入生产时获得一些信心的起点。
\
K8S 安全最佳实践
除了 NSA K8S 强化指南之外，NIST 的另一个有用资源是应用程序容器安全指南或 SP 800–190。本文档概述了与容器相关的安全问题并提供了相应的建议。
0# 容器安全
在 CI/CD 管道和容器镜像的整个构建、存储和部署过程中实施安全实践将包括：
- 安全地存储容器图像，
- 容器镜像的漏洞扫描；
- 管理/监控容器运行时的安全性。
但如果我们只考虑 K8S，我们需要更具体的东西。同时，美国国家安全局的指南是一个很好的起点。如果您按照指南进行操作并构建您的 K8S 集群，它将足够公平和有信心将其投入生产。以下是需要强调的其他一些领域。
1# 基于角色的访问控制 (RBAC)
RBAC 是 Kubernetes 的前线防御。它允许用户控制谁可以访问 API 及其权限。虽然默认启用 RBAC，但如果您从旧版本的 Kubernetes 升级，它可能不会启用。此外，应定期检查和审查 RBAC 设置，以确保不会授予不必要的权限。
\ 仅仅启用 RBAC 是不够的。有一些授权策略应该谨慎使用并适当使用。始终以最小权限原则使用 RBAC。
这意味着使用它来限制用户和组只执行他们需要的操作和任务。确认 Kubernetes 服务和其他用户帐户具有所需的最低权限。此外，我们需要确保不授予集群范围的权限，并且除非必要，否则不要授予任何人集群管理员权限。
\
:::tip（更多细节请参考Kubernetes RBAC官方文档。）
:::
2# API 是新的端点
尽管我在 #1 和 #2 中提到了 Kubernetes API 的访问控制和传输安全，但 Kubernetes API 端点是我们应该注意的另一个领域。管理员可以将 Kubernetes 集群的 API 端点配置为私有或公共子网的一部分。
\ 最好将 Kubernetes API 端点默认配置为私有端点。因此，作为控制平面内的 API 端点，无法从公共 Internet 访问的主节点具有私有 IP 地址。这对于没有或公开任何公共 IP 的完全私有集群至关重要。因此，不会有进出互联网的流量进出。
:::tip（更多信息请参考官方文档。）
:::
3# 加密密钥（Kubernetes Secrets）
有不同形式的加密密钥，例如密码、令牌或 SSH 密钥。 Kubernetes Secret 支持工件和 pod 之间的安全初始通信。
例如，当一个 pod 启动时，它需要访问它的秘密。此外，无论何时创建服务帐户，都会动态生成一个包含其授权令牌的 Kubernetes 机密。
\ 另外，Kubernetes 支持静态加密。当备份未加密或攻击者获得对 etcd 的读取权限时，此加密提供了额外的保护级别。
根据官方文档，我们还应该确保在以下通信中应用 SSL/TLS：
- 从 API 服务器到 kubelet，以及
- 用户和 API 服务器。
\ 最后，建议密钥或凭据的生命周期较短，以减少攻击者在丢失时使用它们的时间。为此，请在证书上设置较短的生命周期并自动执行密钥轮换。
4# OS、Nods 和 Pods 安全性
为了强化和保护 K8S，我们不能忽视基础——操作系统、节点和 Pod 安全。首先，K8S节点是运行在可以是虚拟机或物理机的操作系统中的工作节点。节点上运行的服务包括：
- 容器运行时，
- kubelet 和
- kube 代理。
\ 为了保持对 K8S 的关注，互联网安全中心 (CIS) Kubernetes 基准测试是著名的最佳实践指南。服务器上的所有安全实践，包括漏洞管理、反恶意软件、EDR 和补丁管理，都需要针对节点实施。
\ 除了工作负载安全之外，还有关于内部通信的安全风险。如果需要，建议配置网关以在集群外部访问。节点上的网络端口访问应通过网络访问控制列表进行管理。还应考虑限制对节点的安全外壳 (SSH) 访问。
\ 另一方面， Pod是一组在节点上运行的一个或多个容器。因此，最初，我们需要使用网络策略来控制集群内 pod 的通信。为此，我们需要网络插件实现网络策略，并且使用它们可能需要支持策略的网络驱动程序。
\ Pod 级别的网络安全态势可以通过网络策略和访问控制列表的组合来加强到主机级别。此外，K8S 的Pod 安全上下文支持容器和 Pod 的权限和访问控制设置之间的映射。 （有关安全上下文的完整列表，请参阅官方指南 #securitycontext 。
\ 然而，pod 安全的核心应该是让用户控制 pod 的运行时执行属性的Pod 安全策略，即利用主机文件系统、网络和端口将容器作为特权容器运行的能力。
:::tip 更多信息请参考Pod 官方安全策略文档。
:::
最后的话
您的最终安全目标是尽可能地让黑客访问您的系统；安全的 K8S 也是一样。即使发生这种情况，您也应该能够检测到异常活动并采取措施防止其传播。
\ 保护 Kubernetes 可以是一项全职工作。美国国家安全局提到有第三方安全程序可以提供帮助。但是，当然，这些也伴随着安全问题。安全性对于容器至关重要，在使用 Kubernetes 时需要考虑和管理它。
参考：
- https://www.cvedetails.com/product/34016/Kubernetes-Kubernetes.html
- https://www.nsa.gov/Press-Room/News-Highlights/Article/Article/2716980/nsa-cisa-release-kubernetes-hardening-guidance/
- https://kubernetes.io/blog/2016/08/security-best-practices-kubernetes-deployment/
感谢您的阅读。愿 InfoSec 与你同在?。 \n \n \n