閱讀英文

共用方式為

在 Azure Kubernetes 服务 (AKS) 中的 Pod 安全性最佳做法

  • 發行項
  • 2025/05/23

在 Azure Kubernetes 服务（AKS）中开发和运行应用程序时，Pod 的安全性是一个关键考虑因素。 应用程序应按照最低权限原则进行设计。 确保私人数据安全是客户的首要考虑事项。 你不希望凭据（如数据库连接字符串、密钥或机密和证书）暴露在外部世界，攻击者可以利用这些机密进行恶意目的。 不要将它们添加到代码或将其嵌入到容器映像中。 此方法将给曝光带来风险，并限制轮换这些凭据的能力，因为需要重新生成容器映像。

这篇最佳实践文章重点介绍在 AKS 中如何确保 Pod 的安全。 你将学会如何：

  • 使用 Pod 安全上下文限制对进程和服务的访问或阻止特权提升
  • 使用 Microsoft Entra 工作负荷 ID 对其他 Azure 资源进行身份验证
  • 从数字保管库（例如 Azure Key Vault）请求和检索凭据

还可以阅读群集安全性和容器映像管理的最佳做法。

确保 Pod 对资源的访问

最佳做法指南 - 若要以其他用户或组身份运行并限制对基础节点进程和服务的访问权限，请定义 Pod 安全上下文设置。 分配所需的最小权限数。

若要使应用程序正常运行，pod 应作为定义的用户或组运行，而不应作为 root 运行。 在 Pod securityContext 或容器中，您可以定义诸如 runAsUser 或 fsGroup 的设置，以获得适当的权限。 仅分配所需的用户或组权限，不要将安全上下文用作假定其他权限的方法。 runAsUser、特权提升和其他 Linux 功能设置仅在 Linux 节点和 Pod 上可用。

以非根用户身份运行时，容器无法绑定到 1024 下的特权端口。 在此方案中，Kubernetes 服务可用于掩盖应用在特定端口上运行的事实。

Pod 安全上下文还可以定义用于访问进程和服务的其他功能或权限。 可以设置以下常见安全上下文定义：

  • allowPrivilegeEscalation 定义 Pod 是否可以获取 root 权限。 设计应用程序，使此设置始终设置为 false。
  • Linux 功能 允许 Pod 访问基础节点进程。 请小心分配这些功能。 分配所需的最小权限数。 有关详细信息，请参阅 Linux 功能。
  • SELinux 标签 是一个 Linux 内核安全模块，可用于定义服务、进程和文件系统访问的访问策略。 同样，请分配所需的最小权限数。 有关详细信息，请参阅 Kubernetes 中的 SELinux 选项

以下示例 Pod YAML 清单定义了安全上下文设置：

  • Pod 作为用户 ID 1000 和组 ID 2000 的一部分运行
  • 无法提升权限来使用 root
  • 允许 Linux 功能访问网络接口和主机的实时（硬件）时钟
apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    fsGroup: 2000
  containers:
    - name: security-context-demo
      image: mcr.azk8s.cn/oss/nginx/nginx:1.15.5-alpine
      securityContext:
        runAsUser: 1000
        allowPrivilegeEscalation: false
        capabilities:
          add: ["NET_ADMIN", "SYS_TIME"]

与群集作员协作，确定所需的安全上下文设置。 尽量设计应用程序，以尽可能减少 Pod 所需的额外权限和访问。 使用 AppArmor 和 seccomp（安全计算）限制访问的其他安全功能可由群集作员实现。 有关详细信息，请参阅保护容器对资源的访问。

限制凭据公开

最佳做法指南 - 不要在应用程序代码中定义凭据。 使用 Azure 资源的托管标识让 Pod 请求访问其他资源。 数字保管库（如 Azure Key Vault）还应该用于存储和检索数字密钥和凭据。 Pod 托管标识仅适用于 Linux pod 和容器镜像。

若要限制应用程序代码中公开凭据的风险，请避免使用固定凭据或共享凭据。 凭据或密钥不应直接包含在代码中。 如果公开了这些凭据，则需要更新和重新部署应用程序。 更好的方法是为 Pod 提供自己的标识和身份验证方式，或者从数字保管库自动检索凭据。

使用 Microsoft Entra 工作负载 ID

工作负荷标识是 Pod 上运行的应用程序使用的标识，可针对支持它的其他 Azure 服务（例如存储或 SQL）对自身进行身份验证。 它与 Kubernetes 本机功能集成，以便与外部标识提供者联合。 在此安全模型中，AKS 群集充当令牌颁发者，Microsoft Entra ID 使用 OpenID Connect 发现公共签名密钥，并在交换服务帐户令牌之前验证服务帐户令牌的真实性，然后再将其交换为 Microsoft Entra 令牌。 工作负荷可以使用 Azure SDK 或 Microsoft身份验证库 （MSAL）通过 Azure 标识客户端库交换投影到其卷的服务帐户令牌，以获取 Microsoft Entra 令牌。

有关工作负荷标识的详细信息，请参阅 配置 AKS 群集以将 Microsoft Entra 工作负荷 ID 与应用程序配合使用

将 Azure Key Vault 与机密存储 CSI 驱动程序配合使用

使用 Microsoft Entra 工作负荷 ID 可以针对支持 Azure 服务进行身份验证。 对于没有 Azure 资源的托管标识的自己的服务或应用程序，仍可使用凭据或密钥进行身份验证。 数字保管库可用于存储这些机密内容。

当应用程序需要凭据时，它们与数字保管库通信，检索最新的机密内容，然后连接到所需的服务。 Azure Key Vault 可以是此数字保管库。 下图显示了使用 Pod 托管标识从 Azure Key Vault 检索凭据的简化工作流：

使用 Pod 托管标识从 Key Vault 检索凭据的简化工作流

使用 Key Vault，可以存储和定期轮换机密，例如凭据、存储帐户密钥或证书。 可以使用 适用于机密存储 CSI 驱动程序的 Azure Key Vault 提供程序将 Azure Key Vault 与 AKS 群集集成。 机密存储 CSI 驱动程序使 AKS 群集能够本机检索 Key Vault 中的机密内容，并安全地将其提供给请求的 Pod。 与群集作员协作，将机密存储 CSI 驱动程序部署到 AKS 工作器节点上。 可以使用 Microsoft Entra 工作负荷 ID 请求访问 Key Vault，并通过机密存储 CSI 驱动程序检索所需的机密内容。

后续步骤

本文重点介绍如何确保容器组安全。 若要实现其中一些领域，请参阅以下文章：