如何加固 Kubernetes 集群、增强事件响应能力以及实施纵深防御措施？在此处了解。
译自 Guide to Kubernetes Security Posture Management (KSPM)，作者 Jimmy Mesta。
Kubernetes 安全态势管理 (KSPM) 是一种评估实践，它提供了一个稳健的框架，用于防御常见的攻击媒介、响应事件，并通过纵深防御策略确保深层次的防御。但是，您如何强化 Kubernetes 集群、增强事件响应能力并实施纵深防御措施？
KSPM 从实施“网络卫生”实践开始，以防御您的集群免受常见的攻击媒介的侵害。这包括保护 Kubernetes 控制平面以防止潜在攻击。限制外部访问、保护身份验证和使用基于角色的访问控制 (RBAC) 等措施是至关重要的第一步。
由于配置错误、工具差距或培训不足导致的安全能力“紧张”，不良的安全态势会影响您响应新出现的威胁的能力。安全态势管理可以应用于您组织的技术环境的不同领域，包括云安全态势管理 (CSPM) 和 KSPM。
以下是按照“爬、走、跑”成熟度模型改善态势的建议。
一种经常被忽视的 Kubernetes 安全措施是保护控制平面，它通常在托管 Kubernetes 服务中公开。阻止对控制平面和 API 的外部访问会立即提高针对控制平面漏洞的利用的安全性。然后，攻击者必须利用公开的工作负载或破坏内部控制平面访问，这两者都需要额外的安全措施。保护控制平面就像锁门一样——一个坚定的窃贼可能会找到办法进入，但大多数人不会费心。您仍然需要访问您的集群，因此您需要一种方法在控制平面离线时进入。以下是选项：
- 爬：使用堡垒主机——与您的集群位于同一私有网络中但未加入作为节点的互联网可访问服务器——作为您集群的网关。理想情况下，您可以在需要时启动堡垒，然后在不需要时将其关闭，以最大程度地减少其暴露。
- 行：使用云提供商服务来促进安全连接。例如，AWS 客户可以使用系统管理器 (SSM) 连接到集群中的节点，而无需公共 IP。这使用 AWS 的 IAM 服务来处理身份验证和授权。
- 跑：使用身份感知代理来代理对您网络中节点的访问，而无需向公共互联网公开它们。然后，这可以与您现有的身份提供商和授权系统联系起来。
连接到您的集群后，下一步是进行身份验证以承担角色。Kubernetes 将身份验证委托给外部系统。由于 Kubernetes 不会撤销身份验证材料，因此提供商必须设置到期时间，将身份验证安全性的责任放在您选择的外部系统上。
身份验证后，授权通过 Kubernetes RBAC 本机处理。Kubernetes 接受 x509 证书和持有者令牌作为有效的身份验证材料，为您提供了生成和保护必要材料的几种方法。
- 爬：如果您使用的是托管 Kubernetes 服务，您的云提供商可能有一种方法可以将其本机身份验证协议转换为 Kubernetes 身份验证的持有者令牌。这将问题向后移动一步：现在您需要保护对云提供商的身份验证（理想情况下使用现有 IdP 的 SSO）。
- 走：Kubernetes 支持 OIDC 进行身份验证，因此，如果您的 IdP 是 OIDC 提供商，您可以使用它直接向集群进行身份验证（而不是使用它向云提供商进行身份验证，然后使用云提供商向集群进行身份验证）。
- 跑：零信任架构通过身份感知代理代理访问。如果您已将集群节点配置为仅可通过零信任访问，那么您在连接到这些节点时已经建立了身份。您可以使用相同的零信任架构为集群本身建立您的身份。
RBAC 遵循最小权限原则，这意味着角色和高权限组应限制分配和使用。强大的角色（如 admin）和组（如 system:masters）应限制给特定用户，并且仅在必要时使用。System:masters 应保留在其他集群访问方法不可用时的紧急情况下使用。
- 爬：限制对组的特权访问。这是 RBAC 的精髓；特权访问仅限于需要它的人员。
- 走：让特权访问组的成员养成使用较低权限帐户的习惯，除非他们需要较高的权限。这要求他们使用更高级别的帐户重新进行身份验证。这带来了两个好处：首先，为特权访问增加了保护层，其次，为所有特权活动提供了更清晰的审计跟踪。
- 跑：仅将特权访问限制为紧急情况：这与 GitOps 部署和管理系统特别匹配（请参见下一项）。从本质上讲，不要授予对管理员或其他特权帐户的访问权限——将它们的凭据保存在安全的地方，仅在紧急情况下使用。
GitOps 通过 Git 中的代码即配置 (CaC) 管理所有集群更改，从而消除了手动集群修改。此方法符合最小权限原则，并提供了超出安全性的好处。GitOps 确保了部署的可预测性、稳定性和管理员对集群状态的了解，防止了配置漂移并维护了测试和生产集群的一致性。此外，它减少了具有写入访问权限的用户数量，从而增强了安全性。
- 爬：当您的管道获得批准并且您合并到主管道时，运行一个简单的“helm upgrade”作业。这很容易实现，但需要为您的持续集成和部署 ( CI/CD ) 系统在您的集群中至少提供一个相当特权的帐户（可能更多，具体取决于您的 CaC 是如何组织的）。
- 走：使用 GitOps 运营商。此方法不是直接从您的 CI/CD 推出更改，而是使用集群中的运营商拉取更改，该运营商会监视您的 git 存储库中的更改。现在，您不是授予 CI 工具对集群的凭据，而是授予已在集群中运行的单个运营商对相关 CaC 存储库的读取访问权限。
- 跑：一旦您的 GitOps 工作流顺利进行，就不需要在可以进行手动更改的生产集群中使用用户角色。开发、测试和（可能）登台集群可能永远不会达到这种“成熟”级别，因为这些集群的一部分是尝试新事物。
Kubernetes 生命周期涉及以容器形式运行的工作负载，这些工作负载在具有基于主机用户和容器声明用户的权限的主机上进行处理。要限制权限，请在主机上和容器内使用非 root 用户运行容器。专注于容器的非 root 用户至关重要，因为它最大程度地减少了容器逃逸的机会，并使容器逃逸更具挑战性。
- 爬：审计您的容器。第一步是了解您在特权模式下运行的内容。然后，您可以开始从不需要它的工作负载中删除权限。
- 走：使用准入控制器规则开始对特权容器实施限制，以防止在特权模式下运行的容器运行。
- 跑：在 CI/CD 期间检查权限。在您的 CI/CD 管道中评估容器是否使用 root 用户，以便开发人员可以在尝试部署之前修复权限。
Kubernetes 中可能存在的许多错误配置突出了 KSPM 在大幅减少攻击面的重要性。由于 Kubernetes 既跨越构建又跨越运行时，因此任何有关 KSPM 的讨论都必须包括事件响应。
除了加固之外，KSPM 还通过使用 Kubernetes 机制和外部工具专注于 Kubernetes 集群中的事件响应。这包括实施集群日志记录和实时监控，以检测和分析潜在安全漏洞的异常活动。准入控制器在部署期间强制执行安全策略，遵循 OWASP Kubernetes 十大最佳实践，以防止不兼容或恶意资源部署并增强主动防御。
您如何在集群中处理事件？识别和遏制它们对于安全响应至关重要。这建立在基本的网络卫生实践之上。对于严重事件，您可能需要使用 Kubernetes RBAC 中的紧急情况角色。Kubernetes 姿势中的其他安全措施增强了事件检测和响应能力。
Kubernetes 日志记录具有双重目的：通过为错误修复和新版本提供有价值的反馈来支持 DevOps，并帮助 SRE 团队诊断中断并与开发人员协作。对于安全性而言，日志对于跟踪和评估事件至关重要。Kubernetes 本地收集默认系统和容器日志，但将它们聚合起来以方便监控和搜索是理想的。
-
爬：使用 Kubernetes 默认值。Kubernetes 默认在节点的本地文件系统上收集许多重要日志。您可以使用
kubectl logs命令搜索这些日志。 - 走：部署日志记录代理，它允许您 (a) 收集更多日志，(b) 根据您的优先级对这些日志进行排序和筛选，以及 (c) 将日志聚合到一个公共存储存档中以进行搜索和分析。
- 跑：如果您正在将日志收集到单个存储存档中，下一步是将它们推送到 安全信息和事件管理(SIEM) 解决方案中。这将使您能够更轻松地组织、索引和跨它们进行搜索。
人工日志分析对于回顾性审查安全事件至关重要。但是，实时监控和关联对于最初检测事件至关重要。虽然仪表板和警报等 SIEM 解决方案等手动方法可能有效，但它们需要大量时间和精力来提取相关数据。对于响应式安全方法，自动化是及时监控、分析和响应事件的关键。
- 爬：第一步是部署一个检测和响应工具，该工具能够分析集群中的活动并对其所见内容进行实时判断。仅使用其默认检测态势部署该工具就是一项胜利。
- 走：根据您的集群开始调整检测。任何实时检测和响应工具都必须根据某些已知因素的存在做出判断。如果您的集群具有该工具以前从未见过的内部应用程序、可能不会以最 Kubernetes“正常”方式运行的提升和转移遗留软件或其他可能“异常”的功能，那么您将获得大量误报。下一步是根据您的实际集群调整检测，以便您获得更好的信噪比。
- 跑：使用实时 KSPM 主动监控。检测和响应工具通常被配置为在发现它认为异常的情况时生成警报。下一步是主动监控这些警报以及工具提供的任何其他遥测，以尽可能减少您的响应时间。确保您在 Kubernetes 中看到的错误配置与 Kubernetes 生命周期实时关联，而不是轮询间隔，以便您拥有完整的历史背景。
并非所有 KSPM 解决方案都提供准入控制，但它对于 Kubernetes 部署中的安全性至关重要。遵循 Kubernetes 的 OWASP 前 10 名 有助于定义基本策略。准入控制器在部署期间强制执行这些策略，拒绝不符合要求的对象。它可以阻止具有 root 权限的容器、验证工件签名或拒绝“已知不良”的映像。某些控制器还可以检查和修复现有集群资源以确保合规性。这种响应性阻止了不符合要求的资源，并允许进行规则调整，从而随着时间的推移加强安全性并有效应对威胁。
- 爬：使用其默认规则集部署准入控制器。这将立即提供一定程度的保护，并让您有机会了解该工具。
- 走：添加集群评估组件，以在不中断现有工作负载的情况下根据准入控制器规则扫描它们。这有助于识别不符合要求的工作负载，从而根据需要进行手动修复。
- 跑：编写您自己的规则，并在强制执行之前进行试运行。根据您的特定安全要求调整准入控制器的现有规则集，并确保您和您的工程团队在强制执行准入控制策略之前了解其影响。
尽管 KSPM 主要关注集群强化而不是事件响应，但它仍然提供配置来预防、响应和历史地了解事件。实时功能和灵活的准入控制对于有效的事件管理至关重要。
深度防御源自军事战略，涉及创建多层防御以阻碍攻击者并增加其攻击成本。在网络安全中，目标是让对手为每次攻击付出艰苦的努力，从而减缓其攻击速度，以增强检测和响应。此处讨论的策略旨在阻碍对手并增强防御者的有效响应能力。
虽然 Kubernetes 集群是一个安全边界，但将其视为对主机和网络拓扑的抽象至关重要。这将攻击面扩展到工作负载接口和 Kubernetes API 之外，包括底层主机和网络，从而创建潜在的访问点和横向移动的机会。服务网格可以通过加密流量、相互认证服务和限制通信来显著减小此攻击面，从而增强安全性并提高对集群中横向移动尝试的可见性。
- 爬：服务网格的基本部署通常会立即为您带来加密的东西向流量和相互认证。这并不像点击部署那么简单：集群上运行的服务可能需要进行一些调整才能与服务网格配合良好，但网格本身无需任何修改即可为您带来这些好处。
- 走：收集服务网格日志。服务网格为您的集群提供网络日志可见性。这在实时检测和调查事件中都非常宝贵。
- 跑：要求应用程序定义/限制网络连接。服务网格的深度防御优势在于它能够逐个应用程序或逐个服务限制网络连接。这将受感染的服务限制为仅连接到指定的服务，从而减少攻击者的影响和横向移动的机会。它还通过为攻击者创造错误机会并在未经授权的访问尝试中产生噪音来增加检测机会。
Kubernetes 通过将所需状态 API 对象列表与实际集群状态进行比较来管理工作负载。它编排容器运行时和网络等系统以与此所需状态保持一致。保护控制平面和工作节点上的配置文件对于防止攻击者提升权限或更改集群的预期行为至关重要。建议将对这些文件的写访问权限限制为 root 用户以进行深度防御。
- 爬：手动加固关键文件。您可以在每个节点上手动执行此操作，也可以使用 Ansible 等配置管理系统在整个集群中应用此加固。
- 走：使用加固的节点映像。通过将关键文件的加固纳入您的映像生成过程，将这些文件的加固过程向后移动一层。这可确保在部署新节点时从一开始就加固文件。
- 跑：设置监视以尝试修改关键文件。笨拙的攻击者试图修改这些文件应该很容易被检测到。更聪明的攻击者会首先注意到受限的权限，然后尝试升级到 root。理想情况下，基于主机的检测系统（即端点检测和响应系统）将检测到其中任何一种。
驾驭 KSPM 的复杂性需要一种战略性的、分层的方法，该方法涵盖基本加固技术、增强的事件响应策略和全面的深度防御框架。