通过

保护工作负荷

确保您的工作负载安全涉及生成、部署和运行容器，以有助于降低风险并符合行业标准要求。 本文提供有关容器安全性、Pod 安全标准和工作负荷标识的指导，帮助你保护应用程序免受供应链风险、未经授权的访问以及群集内外的运行时威胁。

获取、编录和生成容器时，请遵循安全的容器生命周期

获取、编录和生成工作负载时，请遵循 Microsoft容器安全供应链框架 。 此框架可帮助你更好地防范不受信任的源、避免泄露的依赖项和扫描漏洞。

通过获取或生成软件物料清单（SBOM）来跟踪代码来源。 还可以配置 Microsoft Defender for Containers 以帮助执行对容器注册表中映像的漏洞评估 - 请参阅支持矩阵以了解支持哪些注册表及其支持级别（预览版或正式版）。

更通常，建议在开发工作负荷应用程序软件时遵循 安全开发生命周期 。

另请参阅 我们关于如何 在部署和运行工作负荷时遵循安全供应链框架的指导。

参考文献

为增强安全性的 Kubernetes 环境准备容器映像

为了帮助提升在运行时以最低权限执行容器镜像，请编制容器镜像以支持工作负载以非root用户身份执行。

使用可窄地满足所需运行时组件的无发行版容器映像和专用容器映像。 可以从信誉良好的供应商（例如 Microsoft 工件注册表）中为工作负载选择基础映像。 缩小运行时依赖项有助于减少辅助组件的潜在攻击面，以及安全更新和 bug 修复导致的维护负担。 使用多阶段生成进一步减少运行时映像的占用空间。

使用 容器签名 来帮助确保工作负荷映像不会被意外或恶意篡改。 Azure Pipelines 和 GitHub Actions 提供了各种工具来支持容器签名。 可以将容器签名与所选的公钥基础结构（PKI）集成。

参考文献

遵循 Pod 安全标准

请遵循 Pod 的 Kubernetes Pod 安全标准 ，尽可能针对受限策略级别，否则遵循基线级别。 例如，您的容器应以非 root 用户身份运行，并且不应挂载主机卷，除非这对其运行来说绝对必要。 请参阅 我们的建议 ，了解如何帮助实施这些标准。 并非所有由 Microsoft 提供的扩展程序都能够满足最严格的策略限制，因为它们执行特权操作。 部署时，可能需要允许额外的功能。

此外，请考虑为每个 Pod 设置内存限制和 CPU 请求（尽管不是可能导致不良的限速的 CPU 限制）。 另请考虑每个命名空间的资源配额。 这些限制和配额可能会阻止来自遭到入侵或行为不当的容器的更广泛的拒绝服务（DoS）攻击。

参考文献

强制实施额外的 Linux 安全标准

请考虑使用提供进一步保护 的额外 Linux 安全强化框架 。 SELinux 或 AppArmor 要求并强制每个工作负载对特定资源（如文件和端口）进行更精确的访问声明。 这些声明超出了标准 Linux 权限模型。 此外， seccomp 会限制每个工作负荷可以发出的系统调用，并且 Pod 安全标准的受限级别需要默认的 seccomp 配置文件。 所有这些安全强化功能都附带了默认设置，但通常可以进一步定制特定应用程序。 例如，您可以定义一个自定义 seccomp 安全配置文件，该配置文件仅允许 Pod 所需的精确系统调用（syscalls）。

参考文献

使用工作负荷标识访问 Azure 资源

工作负荷应使用 工作负荷标识联合 来帮助安全地访问 Azure 中的资源，例如存储帐户。 此方法有助于避免创建和分发单独的机密，以对用于使用 Azure RBAC 进行授权的 Entra ID 标识进行身份验证。 相反，这种联合方法允许你直接从 Kubernetes 服务帐户令牌获取云中 Entra ID 标识的令牌。 （服务帐户是 Kubernetes 的工作负载内置标识。

群集的服务帐户令牌颁发者创建并对这些服务帐户令牌进行签名。 因此，颁发者的私钥是一个基本机密。 对它的访问应受到限制，并且应定期轮换它。

如果您在 Azure Local 上通过 Azure Arc 启用了 AKS，则此访问控制会自动处理。 只有运行 API 服务器的控制平面节点（包括令牌颁发者）才能访问密钥。 密钥在 90 天后过期，并且每 45 天自动轮换一次。

如果通过已启用 Arc 的 Kubernetes 连接自己的群集，则评估供应商的产品是否提供类似的功能。 检查它们是否限制对服务帐户令牌颁发者密钥的访问，以及是否定期轮换它。

在/到/从工作负荷中配置 TLS 加密和身份验证

对工作负荷在群集内外进行的所有连接使用 TLS。 使用 TLS 可能需要生成证书并分发信任捆绑包，以便在建立这些连接时使用。

对于群集中的 TLS 连接，可以考虑使用服务网格（例如 Istio）来为您维护 TLS 连接。 服务网格（如 Istio）或应用程序运行时（如 DAPR）可以帮助生成自己的自签名工作负荷证书。 为了获得额外的安全性，请考虑 配置群集本地中间 CA 以用于对这些工作负荷证书进行签名。 如果这样做，请考虑使用公钥基础结构（PKI）为此中间 CA 颁发证书，其中根证书本身在脱机 HSM 支持的保管库中仍然受到保护。

对于进入群集的入口 TLS 连接，请使用许多产品之一（例如负载均衡器和入口/网关控制器）进行评估，这些控制器可帮助你安全地管理传入流量。 可能需要为这些终结点生成自己的证书才能使用。 你还可能需要将这些证书的信任捆绑分发给外部客户端，这些客户端需要验证其连接到群集的连接。 请再次考虑从您的 PKI 颁发这些证书。 可以使用 证书管理器 请求这些证书：下面是 此请求 适用于 NGINX 入口控制器的方式。 可以使用 信任管理器 来帮助分配信任。 或者，如果只需要几个证书，则可以在 Azure Key Vault 中手动创建和轮换它们，并使用 适用于 Kubernetes 的 Azure Key Vault 机密存储扩展（预览版） （“SSE”）将其同步为 Kubernetes 机密。

生成后，这些证书和随附的私钥将作为机密存储在 Kubernetes 机密存储中。 请参阅有关 保护这些机密的本指南。

还可以将服务帐户令牌用于 TLS，而不是用于 mTLS 的证书，以便对群集中的连接进行客户端身份验证。 如果是这样，我们建议避免为每个命名空间使用“默认”服务帐户。 而是为每个单独的工作负荷或组件创建专用服务帐户标识。 这样做会启用最小特权原则，因为为服务或通过使用 Kubernetes RBAC为 API 服务器配置授权规则。

参考文献

配置用于访问工作负荷/服务的授权规则

旨在通过设置授权规则来控制工作负载之间的流量，这些规则规定了哪些工作负载可以向您的 Kubernetes 工作负载（服务）发出请求。

如果使用服务网格（如 Istio），则它可以自动向每个工作负荷颁发标识凭据。 然后，可以在 配置授权策略 时使用这些标识，以帮助将对 Kubernetes 服务的访问权限限制为仅对指定的调用工作负荷的访问。

或者，如果不使用服务网格，则可以配置自己的凭据（证书或服务帐户令牌），并部署专用授权引擎，例如 OPA。 OPA 可与 Envoy 插件 一起使用，以避免需要修改工作负荷。

另 请考虑在网络层强制实施流量限制。

维护和监视工作负荷遥测数据并将其插入安全管理（SIEM）解决方案

考虑将工作负荷遥测数据发送到监视解决方案，可以在其中分析潜在安全问题（以及产品性能或调试问题）。

可以将 Azure Monitor 扩展 部署到边缘群集。 这些扩展会自动将 Prometheus 指标发送到 Azure Monitor 工作区和/或 Container Insights 日志，并将其发送到 Log Analytics 工作区。 可以使用 Grafana 仪表板大规模收集和分析 Prometheus 指标。 可以使用预生成的视图和工作簿收集和分析容器见解日志和性能数据。 设置此分析时，请注意有关监视群集以涵盖可靠性、成本优化、性能和安全性的最佳做法。

此外，适用于边缘（预览版）的 Azure Monitor 管道扩展为边缘群集中的遥测收集提供了其他灵活的选项。 其功能包括从边缘到云的可缩放路由、本地数据缓存和延迟的云同步，这有助于确保在网络分段或脱机环境中进行可靠的监视。 它还可以使用 OpenTelemetry 协议（OTLP）和 syslog 格式从更广泛的远程源和其他代理接收遥测数据。

将日志流入 Log Analytics 工作区后，还可以启用 Microsoft Sentinel 进行网络威胁检测、调查、响应和主动搜寻。

参考文献

后续步骤