AKS 的安全性

本文逐步讲解在实现任何解决方案之前要考虑的 Azure Kubernetes 服务（AKS）安全治理的各个方面。

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

攻击面

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

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

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

构建安全

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

主要风险

映像配置不佳可能会导致管道出现安全漏洞。 例如，你可能以超出需求的权限运行容器。 还可以将容器配置为允许某些网络访问，这可能会使系统面临风险。 不限制系统调用，只允许容器安全操作所需的调用，可能会增加因容器被入侵而带来的风险。

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

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

使用不来自受信任来源或未包含最新安全更新的基础映像，也可能导致它们用于构建的容器中出现漏洞。

风险对策

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

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

在漏洞的状态层设置阈值。 任何状态为“打开”、“不会修复”或“延期”的事件都会继续沿着管道流动，而 SecOps 可能会在管道中访问有风险的功能，正如他们现在所做的那样。 状态为“有可用的供应商修复措施”的漏洞是开发人员可以解决的问题。 使用宽限期可让开发人员有时间修正漏洞。

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

通常，您会根据 Docker CIS 基准对映像进行扫描。 使用这些类型的流时，引入安全修正不会破坏开发，而能够整体上提升企业的安全状况。

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

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

• 与映像整个生命周期的集成，从构建过程到注册表，再到运行时。
• 了解映像的所有层的漏洞，包括映像的基础层、应用程序框架和自定义软件。
• 策略驱动的执行具有适当的粒度水平，使组织能够在构建和部署过程的每个阶段创建质量门槛。

注册表安全性

注册表安全性的内容包括：

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

主要风险

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

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

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

风险对策

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

• 从容器注册表中移除那些不再应使用的不安全和易受攻击的映像。
• 使用不可变的名称强制访问映像，这些名称指定了要使用的映像的特定版本。 可以使用 最新 标记或映像的特定版本来实现此配置。 标记不能保证新鲜度。 因此，应制定一个流程来确保 Kubernetes 业务流程协调程序使用最新的唯一编号，或者确保“最新”标记代表最新版本。

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

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

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

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

群集安全性

群集安全性是关于：

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

主要风险

有时，单个 Kubernetes 群集可用于运行由具有不同访问级别要求的不同团队管理的不同应用程序。 如果对没有限制或仅根据自身需求提供对个人的访问权限，恶意或粗心的用户可能会损害他们有权访问的工作负荷以及群集上的其他资产。

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

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

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

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

保护运行群集本身的组件免受漏洞和符合性问题。 请确保您正在运行 Kubernetes 的尽可能最新版本，以充分利用补救措施。

风险对策

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

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

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

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

可以使用污点和容差按敏感度级别将部署隔离到特定节点集。 避免在与低敏感度工作负荷相同的节点中托管高度敏感的工作负荷。 使用单独的托管群集是一个更安全的选项。

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

应将 Kubernetes 群集配置为：

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

在不影响群集性能的情况下，要从群集中隔离和删除已泄露的节点，这一点必须很容易。 AKS 使这一点变得简单。

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

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

节点安全性

节点安全性是关于：

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

主要风险

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

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

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

当用户直接登录到节点以管理容器而不是通过 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 策略，该策略要求群集为专用群集。 有关详细信息，请参阅 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 Workload ID 与 AKS 和机密存储 CSI 驱动程序的 Azure 密钥保管库提供程序来保护机密、证书和连接字符串。
• 使用 AKS 节点映像升级 来更新 AKS 群集节点映像，如果可能的话；或者在应用更新后，使用 kured 自动执行节点重启。
• 使用 适用于 Kubernetes 的 Azure Policy 加载项监视和强制实施配置。 在根据企业规模登陆区域最佳做法部署的订阅中，此配置通过管理组级别部署的 Azure Policy 自动执行。
• 在 Microsoft Defender for Cloud 中查看 AKS 建议。
• 使用 Microsoft Defender for Containers（云原生解决方案）改进、监视和维护群集、容器及其应用程序的安全性。
• 将 Azure 容器注册表的专用和私有实例部署到每个登陆区域订阅。
• 使用 容器注册表的专用链接 将其连接到 AKS。
• 使用 Microsoft Defender 漏洞管理或任何其他映像扫描解决方案扫描你的映像是否存在漏洞。

重要

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