你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

AKS 的安全性

本文将引导你完成Azure Kubernetes 服务（AKS）安全治理的各个方面，在实现任何解决方案之前要考虑。

本文重点介绍如何使用 Azure 和开源软件实现解决方案。 创建企业规模登陆区域时做出的决策可以部分预定义治理。 若要了解治理原则，请参阅 企业规模的安全治理和合规性。

攻击面

为 Kubernetes 群集创建安全策略时，请考虑以下五个攻击面：

• 生成
• 注册表
• 群集
• 节点
• 应用程序

对于每个类别，我们将讨论要考虑的主要风险，并对这些风险采取对策。

生成安全性

生成安全性是关于正确使用 DevSecOps 和容器镜像。

主要风险

映像配置不佳可能会导致管道出现安全漏洞。 例如，你可能具有比所需权限更大的容器运行。 还可将容器配置为允许某些网络访问，这可能会使系统处于风险之中。 不限制对容器安全操作所需的调用的系统调用可能会增加受入侵容器的风险。

另一个漏洞可能是允许容器访问主机的敏感目录，或者允许容器更改控制主机基本功能的位置。

恶意容器是环境中的计划外容器。 他们可能是开发人员在测试环境中测试代码的结果。 这些容器可能尚未经过严格的漏洞扫描或正确配置。 这些漏洞可能会为攻击者打开一个入口点。

使用基础映像不是来自受信任的源，或者不是最新的安全更新，也可能导致它们用来生成的容器中的漏洞。

风险对策

生成安全性是关于实现 DevSecOps 以将安全性向左转移并在大多数问题开始沿管道向下移动之前对其进行补救。 这不是将所有所有权都交给开发人员，而是与操作共享所有权。 然后，开发人员可以查看并修复他们可以实际解决的漏洞和合规性问题。

你可以构建一个管道来扫描生成并在管道出现 1 个或 10 个严重漏洞时使生成失败。 更好的方法是向下查看下一层。 你可以开始根据供应商状态细分责任点。

在漏洞的状态层设置阈值。 任何状态为 “打开”、“ 不会修复”或 “延迟 ”的任何内容都会继续流向管道，SecOps 可在其中访问风险，就像他们今天所做的那样。 供应商修复状态的漏洞是开发人员可以解决的一项漏洞。 使用宽限期可让开发人员有时间修正漏洞。

除了漏洞评估之外，还有合规性评估。 例如，允许映像 以根 身份运行或公开 SSH 会破坏大多数企业的符合性状况。 在生成期间而不是部署期间解决此问题。

通常，针对 Docker CIS 基准扫描映像。 使用这些类型的流时，你不会因为引入安全补救而中断开发，但你可采用整体内联的方式改进企业的安全状况。

使用支持这些功能的工具对于有效地为企业实现正确的策略至关重要。 传统工具通常无法检测容器中的漏洞，这可能会导致虚假的安全感。 需要考虑基于管道的生成方法和容器技术的不可变和声明性性质的工具，才能正确保护容器生态系统。

这些工具应具有以下属性：

• 从生成过程开始到注册表到运行时的整个映像生存期集成。
• 了解映像的所有层（包括映像的基本层）、应用程序框架和自定义软件中的漏洞。
• 策略驱动的强制实施具有适当粒度级别，使组织能够在生成和部署过程的每个阶段创建质量入口。

注册表安全性

注册表安全性的内容：

• 从生成偏移控件。
• 防止推送/拉取受污染的图像。
• 映像签名。

主要风险

映像通常包含专有信息，包括组织的源代码。 如果与注册表的连接不安全，则图像的内容可能会带来与组织内传输的任何其他形式的数据一样严重的机密性风险。 注册表中具有易受攻击的过时版本的过时映像在意外部署时可能会增加安全风险。

另一个安全漏洞可能包括容器注册表的身份验证和授权限制不足。 这些注册表可能会在映像中容纳敏感的专有资产。

生成和部署内容时，此内容的分发是许多攻击途径之一。 如何确保暂存分发的内容与传递到预期终结点的内容相同？

风险对策

设置部署过程，以确保仅通过加密通道将开发工具、网络和容器运行时连接到注册表。 此外，请确保内容来自受信任的源。 若要降低使用过时图像的风险，

• 删除不应再从容器注册表中使用的不安全、易受攻击的映像。
• 使用指定要使用的映像的特定版本的不可变名称强制访问映像。 可以使用最新标记或映像的特定版本来实现此配置。 标记不保证新鲜度。 因此，请制定一个过程，以确保 Kubernetes 业务流程协调程序使用最新的唯一数字，或者 最新 标记表示最新版本。

访问包含敏感映像的注册表需要身份验证和授权。 所有写入访问权限也应要求进行身份验证。 例如，策略可能只允许开发人员将映像推送到他们负责的特定存储库。

应联合访问这些注册表，并利用业务线级访问策略。 例如，可以将 CI/CD 管道配置为仅在映像通过漏洞扫描合规性评估和质量控制测试后才能将映像推送到存储库。

容器注册表现在被视为项目注册表正成为部署任何内容类型的主要手段，而不仅仅是容器映像。 每个云都提供一个注册表，其中包含开放源代码项目和供应商产品，这些项目和供应商产品可用于云提供商内的本地或专用托管。 从初始生成到生产部署，内容会在注册表内和注册表之间进行推广。

如何确保进入注册表的内容的完整性与注册表中的内容相同？ 采用映像签名解决方案可确保部署仅来自受信任的注册表，并且部署受信任的内容。

群集安全性

群集安全性内容：

• 身份验证和授权。
• 网络安全。
• 漏洞和合规性管理。

主要风险

有时，单个 Kubernetes 群集可用于运行由具有不同访问级别要求的不同团队管理的不同应用程序。 如果向个人提供访问权限时不加以限制，或者仅为了满足其需求，则恶意或粗心用户可能会危及他们有权访问的工作负载和群集上的其他资产。

群集自己的用户目录管理授权和身份验证时，可能会发生另一个安全漏洞。 组织身份验证目录通常更严格地控制。 由于这些帐户是高度特权的，而且通常是孤立的，因此泄露帐户的可能性会增加。

此方案可能会导致群集甚至系统范围的漏洞。 容器卷存储的数据由业务流程协调程序管理，无论托管在哪个节点上，它都必须有权访问数据。

由于网络覆盖旨在加密传输中的数据，传统的网络筛选器可能会有安全盲目。 这种设计使得难以监视群集内的流量，因此可能需要特殊预配来监视 Kubernetes 群集。

来自共享同一群集的不同应用程序的流量可能具有不同的敏感级别，例如面向公众的网站和运行关键敏感业务流程的内部应用程序。 在群集内共享同一虚拟网络可能会导致敏感数据被泄露。 例如，攻击者可能会使用向 Internet 公开的共享网络来攻击内部应用程序。

保护运行群集本身的组件免受漏洞和合规性问题的影响。 请确保在 Kubernetes 的最新版本上运行，以利用修正。

风险对策

Kubernetes 群集用户访问应使用最低特权访问模型。 仅授予用户完成其工作所需的访问权限，例如在特定主机、容器和映像上执行特定操作。 测试团队成员对生产中的容器的访问权限应有限或无权访问生产中的容器。 应严格控制并谨慎使用具有群集范围的访问的用户帐户。

使用强身份验证方法（如多重身份验证）来保护对这些帐户的访问。 组织用户目录应用于通过单一登录来管理群集，而不是可能具有相同级别的策略和控制的特定于群集的用户帐户。

使用允许容器正确访问运行容器的任何主机的数据的加密方法。 这些加密工具应防止其他容器未经授权访问数据，即使在不应访问它们的同一节点内也是如此。

将 Kubernetes 群集配置为按敏感度级别将网络流量分成离散虚拟网络或子网。 还可以按应用程序分段，但通过敏感度级别定义网络可能已足够。 例如，应至少实现面向客户的应用程序的虚拟网络，这些应用程序与那些为具有敏感流量的内部应用程序提供服务的应用程序分开。

可以使用污点和容错按敏感度级别将部署隔离到特定节点集。 避免在与低敏感度工作负荷相同的节点中托管高度敏感的工作负荷。 建议使用单独的托管群集，这样会更安全。

按目的、敏感度和线程状况对容器进行分段，为敏感工作负荷提供额外的保护。 通过这种方式对容器进行分段，攻击者更难访问一个段来获取对其他段的访问权限。 此配置具有确保残差数据（如缓存或卷装载）被敏感度级别隔离的附加优势。

Kubernetes 群集应配置为：

• 为在它们上运行的应用程序提供安全的环境。
• 确保将节点安全地添加到群集。
• 具有持久性标识，以帮助确保其整个生命周期的安全性。
• 提供有关群集状态的实时、准确的信息，包括网络和其中的节点。

在不影响群集性能的情况下，必须能够轻松地隔离和删除不可信节点。 可借助 AKS 轻松实现这一点。

定义容器运行时配置标准，以自动确保符合性。 Azure 中有许多策略使此过程变得简单，用户也可以创建自己的策略。 使用 Azure 安全功能在整个环境中持续评估配置设置并主动实施这些设置。

自动确保解决 Kubernetes 组件的漏洞。 使用单独的环境进行开发、测试和生产，每个环境都有自己的控件和基于角色的访问控制（RBAC）进行容器管理。 将所有容器创建与单个用户标识相关联，应记录用于审核。 此配置有助于降低恶意容器的风险。

节点安全性

节点安全性的内容：

• 运行时保护。
• 漏洞和合规性管理。

主要风险

工作器节点有权访问节点上的所有组件。 攻击者可以使用任何网络可访问的服务作为入口点，因此，从多个点提供对主机的访问可能会严重增加其攻击面。 攻击面越大，攻击者获取节点及其操作系统访问权限的机会就越大。

此外，像 AKS 节点中使用的容器特定操作系统具有较小的攻击面，因为它们不包含使常规操作系统能够直接运行数据库和 Web 服务器的库。 使用共享内核会导致在与单独虚拟机中的容器在同一环境中运行的容器的受攻击面更大。 即使 AKS 节点上运行的特定于容器的操作系统正在使用，也是如此。

主机操作系统提供的基础系统组件可能存在漏洞和合规风险。 由于它们是低级别组件，因此其漏洞和配置可能会影响托管的所有容器。 AKS 通过确保通过 AKS 上运行的节点上的常规 OS 更新来保护用户，并维护工作器节点的符合性状况。

当用户直接登录到节点以管理容器而不是通过 AKS 控制平面时，不当的用户访问权限也可能导致安全风险。 直接登录可以允许用户对他们本无权访问的应用程序进行更改。

此外，恶意容器可能会导致主机 OS 文件系统被篡改。 例如，如果允许容器在主机 OS 中装载敏感目录，该容器可能会更改文件。 这些更改可能会影响主机上运行的其他容器的安全性。

风险对策

通过限制 SSH 访问来限制节点访问。

在 AKS 节点中使用特定于容器的 OS 通常会减少攻击面，因为禁用了其他服务和功能。 它们还具有只读文件系统，并默认采用其他群集强化做法。

Azure 平台会在夜间自动将 OS 安全修补程序应用于 Linux 和 Windows 节点。 如果 Linux OS 安全更新需要重启主机，它不会自动执行重启操作。 AKS 提供了重新启动以应用这些特定修补程序的机制。

Microsoft Defender for Servers 不适用于 AKS Linux 和 Windows 节点，因为Microsoft管理其 OS。 如果部署 AKS 的订阅中没有其他虚拟机，则可以安全地禁用 Microsoft Defender for Servers。

如果已部署环境（包括 建议的企业规模登陆区域 Azure 策略），则可以在管理组中配置对策略分配的排除，该分配会自动启用 Microsoft Defender for Servers 以避免不必要的成本。

应用程序安全性

应用程序安全性的内容：

• 运行时保护。
• 漏洞和合规性管理。

主要风险

映像是包含运行应用程序所需的所有组件的文件。 当这些组件的最新版本用于创建映像时，它们可能暂时没有已知的漏洞，但它们可以快速更改。

必须使这些文件与最新版本保持最新，因为包开发人员会定期识别安全漏洞。 通过更新用于创建容器的映像来进一步向上游更新容器，这与通常在主机上更新的传统应用程序不同。

恶意文件也可以嵌入到映像中，然后可用于攻击系统的其他容器或组件。 第三方容器可以是可能的攻击途径。 特定详细信息可能未知，它们可能会泄露数据。 也许容器尚未与所需的安全更新保持最新状态。

另一种攻击途径是使用直接在映像文件系统中嵌入密码和连接字符串等机密。 这种做法可能会导致安全风险，因为有权访问映像的任何人都可以访问机密。

应用程序本身可能存在瑕疵，如易受站点脚本或 SQL 注入攻击的应用程序。 当存在缺陷时，该漏洞可能被用于未经授权访问其他容器甚至主机 OS 中的敏感信息。

使用 Azure 上提供的各种安全工具，AKS 容器运行时可以轻松监视漏洞。 有关详细信息，请参阅 Microsoft Defender for Kubernetes 简介。

还应控制发送到容器的出口网络流量，以确保容器无法跨不同敏感级别的网络（例如托管安全数据的环境或 Internet）发送流量。 Azure 借助其各种网络和 AKS 安全功能使这种控制变得容易。

默认情况下，Kubernetes 计划程序致力于驱动在节点上运行的工作负载的规模和最大化密度。 它们可能会将不同敏感度级别的 Pod 放置在同一节点中，因为该主机具有最可用的资源。 当攻击者使用对面向公众的工作负载的访问权限攻击在同一主机上运行更敏感进程的容器时，此方案可能会导致安全事件。 也可使用不可信容器来扫描网络，以发现攻击者可以利用的其他漏洞。

风险对策

请勿将机密存储在应用程序代码或文件系统中。 机密应存储在密钥存储中，并根据需要在运行时提供给容器。 AKS 可确保只有需要访问某些密钥的容器才能访问它们，并且这些机密不会保留在磁盘上。 例如，Azure Key Vault 可以安全地存储这些机密并根据需要将它们提供给 AKS 群集。 确保这些机密在存储和传输过程中都被加密也很简单。

避免使用不受信任的映像和注册表，并确保只允许来自受信任集的映像在其群集中运行。 对于多层方法：

• 集中控制受信任的映像和注册表。
• 通过加密签名单独标识每个映像。
• 制定适当的策略，确保所有主机仅运行来自已批准集的映像。
• 在执行之前验证这些签名。
• 当漏洞和配置要求发生变化时，监视和更新这些映像和注册表。

安全计算配置文件应用于约束容器，并在运行时分配。 可以创建自定义配置文件并将其传递给容器运行时以进一步限制其功能。 至少请确保使用默认配置文件运行容器。 请考虑对运行高风险应用程序的容器使用自定义的受限配置文件。

工具可以使用行为学习和检测异常来自动分析应用程序。 可以使用第三方解决方案在运行时检测异常。 异常可能包括如下事件：

• 无效或意外的进程执行或系统调用。
• 对受保护的配置文件和二进制文件的更改。
• 写入意外的位置和文件类型。
• 创建意外的网络侦听器。
• 发送到意外网络目标的流量。
• 恶意软件存储和执行。

Microsoft Defender for Kubernetes 目前正在这一领域进行投资。

容器应以只读模式运行其根文件系统，以隔离对已定义目录的写入，这些工具可以轻松监视这些目录。 此配置使容器更具复原能力，因为可以隔离对这些特定位置的篡改。 它们可以轻松地与应用程序的其余部分分开。

设计注意事项

AKS 具有指向其他 Azure 服务的多个接口，例如Microsoft Entra ID、Azure 存储 和 Azure 虚拟网络。 在规划阶段，使用这些服务需要特别注意。 AKS 还增加了额外的复杂性，要求你考虑应用与其他基础结构环境相同的安全治理和合规性机制与控制。

以下是 AKS 安全治理和合规性的一些其他设计注意事项：

• 如果在根据企业规模登陆区域最佳做法部署的订阅中创建 AKS 群集，请熟悉群集将继承的 Azure 策略。 有关详细信息，请参阅 Azure 登陆区域中包含的策略参考实现。
• 决定是否应通过 Internet 访问群集的控制平面（我们建议使用 IP 限制），这是默认设置，还是仅从 Azure 中的专用网络内部或本地作为专用群集访问。 如果组织遵循企业规模登陆区域最佳做法，则 Corp 管理组具有一个关联的 Azure Policy，该策略强制群集成为专用群集。 有关详细信息，请参阅 Azure 登陆区域中包含的策略参考实现。
• 使用内置的 AppArmor Linux 安全模块进行评估，以限制容器可以执行的操作（例如读取、写入、执行）或系统功能（例如挂载文件系统）。 例如，所有订阅都有 Azure 策略，可阻止所有 AKS 群集中的 Pod 创建特权容器。 有关详细信息，请参阅 Azure 登陆区域中包含的策略参考实现。
• 在进程级别使用seccomp（安全计算）进行评估，以限制容器可以执行的进程调用。 例如，在登陆区域管理组中将 Azure Policy 作为通用企业级登陆区域实现的一部分进行应用，以防止容器通过 Kubernetes 的 Azure 策略使用 seccomp 实现到根的特权提升。
• 确定容器注册表是通过 Internet 访问还是只能在特定虚拟网络中访问。 在容器注册表中禁用 Internet 访问可能会对依赖于公共连接访问它的其他系统产生负面影响。 示例包括持续集成管道或 Microsoft Defender 进行图像扫描。 有关详细信息，请参阅使用 Azure 专用链接 私下连接到容器注册表。
• 确定专用容器注册表是跨多个登陆区域共享的，还是将专用容器注册表部署到每个登陆区域订阅。
• 考虑使用 Microsoft Defender for Kubernetes 等安全解决方案进行威胁检测。
• 考虑扫描容器映像以检查漏洞。
• 如果没有非 AKS 虚拟机，请考虑在 AKS 订阅中禁用 Microsoft Defender for Servers，以避免不必要的成本。

设计建议

• 使用 Azure RBAC 限制对 Kubernetes 群集配置文件 的访问。
• 保护 Pod 对资源的访问权限。 提供最少数量的权限，并避免使用根或特权升级。
• 将 Entra 工作负荷 ID 与 AKS 和用于机密存储 CSI 驱动程序的 Azure 密钥库 提供程序配合使用，以保护机密、证书和连接字符串。
• 如果可能，请使用 AKS 节点映像升级来更新 AKS 群集节点映像，或者在应用更新后自动执行节点重启。
• 使用适用于 Kubernetes 的 Azure Policy 插件监视和强制执行配置。 在根据企业规模登陆区域最佳做法部署的订阅中，此配置通过管理组级别部署的 Azure Policy 自动执行。
• 查看 Microsoft Defender for Cloud 中的 AKS 建议。
• 使用 Microsoft Defender for Containers（云原生解决方案）改进、监视和维护群集、容器及其应用程序的安全性。
• 将 Azure 容器注册表的专用和私有实例部署到每个登录区域订阅。
• 使用容器注册表专用链接将其连接到 AKS。
• 使用Microsoft Defender 漏洞管理或任何其他映像扫描解决方案扫描映像来扫描映像是否存在漏洞。

重要

Microsoft Defender for Cloud 映像扫描与容器注册表终结点不兼容。 有关详细信息，请参阅使用 专用链接私下连接到容器注册表。