通过

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

已启用 Azure Arc 的 Kubernetes 的治理、安全性和合规性基线

  • 项目

本文提供在生成已启用 Azure Arc 的 Kubernetes 部署时应使用的安全性、治理和合规性的关键设计注意事项和最佳做法。 虽然企业级登陆区域文档将治理和安全性作为单独的主题进行介绍，但这些关键设计领域合并到了已启用 Azure Arc 的 Kubernetes 的单个主题中。

Azure Policy 和 Microsoft Defender for Cloud 是云原生的工具，可让你以自动化方式大规模执行防护、控制、报告、警报和修正任务。 通过将它们与已启用 Azure Arc 的 Kubernetes 相结合，可将治理策略和安全检查扩展到本地和/或多云环境中的任何 Kubernetes 群集。

体系结构

下图显示了一个概念参考体系结构，其中描绘了已启用 Azure Arc 的 Kubernetes 的安全性、合规性和治理设计领域：

显示已启用 Azure Arc 的 Kubernetes 的企业级安全性、治理和合规性的图。

设计注意事项

随着混合资源和多云资源成为 Azure 资源管理器的一部分，你可以从 Azure 管理和治理它们。 本部分包含规划已启用 Azure Arc 的 Kubernetes 群集资源的安全性和治理时应记住的设计注意事项。

查看 Azure 登陆区域的安全性和治理设计领域，以评估已启用 Azure Arc 的 Kubernetes 对整体治理和安全模型的影响。

代理预配

定义有关预配已启用 Azure Arc 的 Kubernetes 代理的策略，并在创建加入服务主体时使用最低特权原则。 考虑使用自动化进行批量注册。

代理管理

已启用 Azure Arc 的 Kubernetes 代理在已启用 Azure Arc 的 Kubernetes 群集的混合操作中发挥着关键作用，因为它们可让你从 Azure 管理群集。 实施用于跟踪代理连接状态的解决方案。 确保定义一个用于升级已启用 Azure Arc 的 Kubernetes 代理的过程。

基于角色的访问控制 (RBAC)

在组织中定义负责处理混合群集中的日常操作的管理、操作和开发人员角色。 将每个团队映射到操作和职责可以确定 Azure 基于角色的访问控制 (RBAC) 角色以及 Kubernetes ClusterRoleBinding 和 RoleBinding。

考虑使用 RACI 矩阵来支持这项工作，并将控制措施内置到根据资源一致性和清单管理指导定义的管理范围层次结构中。

有关详细信息，请参阅已启用 Azure Arc 的 Kubernetes 的标识和访问管理。

机密和证书管理

通过容器存储接口 (CSI)，在已启用 Azure Arc 的 kubernetes 群集中使用 Azure 密钥保管库并部署其扩展来保护机密和证书。

数据驻留

考虑你要在哪个 Azure 区域中预配已启用 Azure Arc 的 Kubernetes 群集。 了解会从资源中收集哪些数据，并根据组织的数据驻留要求做出相应的规划。

启用和保护 GitOps 配置

GitOps 配置强制实施所需的系统状态，是用于跟踪已启用 Arc 的 Kubernetes 群集合规性的重要工具。 使用 GitOps 配置时，请考虑通过适当的网络和访问控制来保护对源代码管理系统的访问。

策略管理和报告

为混合 Kubernetes 群集定义一个治理计划，该计划将转化为 Azure 策略，以大规模审核和强制实施组织标准。 例如，可以对 Kubernetes 群集强制实施 sourceControlConfiguration 策略，以确保群集从定义的 Git 存储库中获取工作负载和配置的事实来源，并使用 Azure Policy 跟踪合规性。

日志管理策略

查看管理规程关键设计领域设计注意事项和建议，并计划将混合资源中的指标和日志收集到 Log Analytics 工作区中，以供进一步分析和审核。

威胁防护和云安全态势管理

强制实施威胁防护并引入控制措施以检测错误的安全配置和跟踪合规性。 使用 Azure 的智能功能保护混合工作负载免受威胁。 通过启用 Microsoft Defender for Containers，为所有包含已启用 Azure Arc 的 Kubernetes 的订阅启用安全基线监视、安全态势管理和威胁防护。

安全群集访问

规划保护对 Kubernetes API 的访问。 已启用 Azure Arc 的 Kubernetes 群集连接功能提供与 API 服务器的连接，而无需启用任何入站端口。

改善微服务的可观测性和安全性

服务网格的实现有助于改善基于微服务的应用程序的身份验证、授权、安全性和可见性。 已启用 Azure Arc 的 Kubernetes 简化了将 Open Service Mesh (OSM) 部署为扩展的过程。

设计建议

本部分包含规划已启用 Azure Arc 的 Kubernetes 群集资源的安全性和治理时应遵循的设计建议。

代理预配

  • 定义有关将群集加入 Azure Arc 的策略，包括批量注册的自动化方法。 建立一个正式的计划，在其中考虑到部署范围，并包括目标、选择标准、成功标准、培训计划、回滚和风险。

  • 可以使用服务主体将代理预配集成为持续集成和持续部署 (CI/CD) 管道的一部分。 应该限制此服务主体的权限，并仅分配将 Kubernetes 加入 Azure 所需的角色（“Kubernetes 群集 - Azure Arc 加入”角色），因为此服务主体只能用于加入 Kubernetes，而不能用于撤消过程或删除资源。

代理管理

Azure Arc 代理是已启用 Azure Arc 的 Kubernetes 的关键组件，包含多个在安全性、治理和管理操作中发挥作用的逻辑组件。

如果代理停止向 Azure 发送检测信号、脱机或与 Azure 断开连接，则无法在其上执行操作任务。 制定一个计划，规定在发生这种情况时如何向你发出通知以及组织应如何做出响应。

可以使用 Azure 活动日志设置资源运行状况警报，并随时了解代理的 pod 的当前和历史运行状况。 若要了解如何正确管理代理，请查看管理关键设计领域。

如果服务有 15 分钟未收到代理检测信号，已启用 Azure Arc 的 Kubernetes 群集将显示为脱机。 为确保代理可以安全连接到 Azure Arc 终结点，请查看已启用 Azure Arc 的 Kubernetes 连接关键设计领域。

基于角色的访问控制 (RBAC)

加入 Kubernetes 群集后，可将 Azure RBAC 分配到已启用 Azure Arc 的 Kubernetes 群集资源。

在分配“参与者”或“所有者”等角色时，请遵循最低特权原则，这些角色可以执行部署扩展等操作，从而实现产生群集范围的影响的“ClusterAdmin”等操作。 应慎用这些角色，以限制可能的“冲击范围”或最终被自定义角色取代。

应该对发送到 Azure Monitor Log Analytics 工作区的敏感数据应用相同的 RBAC 原则。 已启用 Azure Arc 的 Kubernetes 提供对 Log Analytics 代理收集的日志数据的 RBAC 访问，这些数据存储在群集注册到的 Log Analytics 工作区中。 若要了解如何实现精细的 Log Analytics 工作区访问，请查看设计 Azure Monitor 日志部署。

将已启用 Azure Arc 的 Kubernetes 群集与 Microsoft Entra ID 集成可让你使用 Azure 角色分配，以便更精细地控制谁有权访问已启用 Azure Arc 的 Kubernetes 群集资源以及有权访问 Azure Arc 的 Kubernetes 群集资源。

注意

此集成本机适用于 Kubernetes ClusterRoleBinding 和 RoleBinding 对象类型，并有效地将授权合并到 Kubernetes 群集，并将 Microsoft Entra ID 用作中心标识和访问管理服务。 通过使用 Microsoft Entra ID，可以全面审核和跟踪群集中所做的更改以及任何授权事件。

与 Microsoft Entra ID 集成还可以访问高级安全功能，你应使用这些功能进行配置：

  • 使用 Microsoft Entra ID 的条件访问。 可以在条件访问概述中找到有关条件访问的详细信息。
  • 需要提升权限的任务的即时 (JIT) 访问规则。 某些用户对 Kubernetes 中的敏感信息或关键网络配置设置拥有长期访问权限，这为入侵帐户或内部威胁活动创造了潜在的途径。 特权访问权限管理可帮助你保护组织遭到入侵，并通过限制对敏感数据的长期访问或对关键配置设置的访问来帮助满足合规性最佳做法。

机密和证书管理

不要将机密或证书存储在应用程序代码或文件系统中。 机密应存储在密钥存储中，并根据需要在运行时提供给容器。

考虑使用 Azure 密钥保管库扩展来管理已启用 Azure Arc 的 Kubernetes 群集上的机密和证书。 使用密钥保管库扩展可以管理 Kubernetes 部署的证书生命周期，如下图所示。

显示已启用 Azure Arc 的 Kubernetes 和密钥保管库集成的图。

启用和保护 GitOps 配置

GitOps 是任何采用全自动化操作方法的 IT 策略的重要组成部分。 GitOps 为任何部署提供缩放、一致性、跟踪和审核功能。

使用 GitOps 可以简化跨群集和环境的多个应用程序的部署，同时使用 Git 以声明方式跟踪和强制实施系统的所需状态。 使用 Git 作为单一事实来源和所有部署的中心工具时，它将成为跟踪群集状态、分析一段时间内的更改和审批、帮助进行故障调查以及跨分布式环境实现自动化的最佳方式。

添加 GitOps 配置时，请确保保护对存储库及其密钥的访问并设置分支权限。 有关详细信息，请查看 GitOps 的关键设计领域。

策略管理和报告

策略驱动的治理是云原生操作和 Azure 的 Microsoft 云采用框架的基本原则。 Azure Policy 提供用于强制实施企业标准和大规模评估合规性的机制。 通过 Azure Policy，可以实施治理措施来实现部署一致性和合规性并控制成本和安全态势。 在其合规性仪表板中，可以看到环境整体状态的大规模聚合视图，并找到群集级别的修正功能。

已启用 Azure Arc 的 Kubernetes 在 Azure 资源管理层中支持 Azure Policy，它还支持通过扩展 Gatekeeper for Open Policy Agent 来实施群集内策略。 你可以实施任何内置策略，以快速实现合规性和大规模强制执行。 下图演示了 Azure Policy 如何对已启用 Azure Arc 的 Kubernetes 群集应用大规模强制执行和保护措施。

显示已启用 Azure Arc 的 Kubernetes 策略的图。

了解 Azure 策略的范围以及可在何处应用策略（管理组、订阅、资源组或单个资源级别）。 为已启用 Azure Arc 的 Kubernetes 使用 Azure Policy 的内置库。 根据云采用框架企业规模指南中所述的建议做法创建管理组设计。

  • 确定需要哪些 Azure 策略才能大规模满足组织在已启用 Azure Arc 的 Kubernetes 的业务、监管和安全性方面的要求。
  • 强制实施标记并实施修正任务。
  • 使用 Azure Policy 强制实施 GitOps 并大规模应用配置。
  • 了解和评估已启用 Azure Arc 的 Kubernetes 的 Azure Policy 内置定义。
  • Azure Policy 的 DeployIfNotExists 策略以编程方式将扩展/管理服务代理大规模部署到已启用 Arc 的群集，包括 Azure Monitor。
  • 启用 Azure Monitor 容器见解以确保已启用 Azure Arc 的 Kubernetes 群集合规并监视对它的操作。

日志管理策略

设计和规划 Log Analytics 工作区部署，这是收集、聚合并稍后分析数据的存储。 由于 Log Analytics 工作区代表数据的地理位置，因此若要支持数据保留等配置的隔离级别和范围，必须确定所需的工作区数量及其如何映射到组织结构。

使用单个 Azure Monitor Log Analytics 工作区来管理集中式 RBAC、可见性和报告，如云采用框架的管理和监视最佳做法中所述。

有关详细信息，请查看设计 Azure Monitor 日志部署的最佳做法。

威胁防护和云安全态势管理

  • Microsoft Defender for Cloud 提供一个统一的安全管理平台，该平台划分为云安全态势管理 (CSPM) 和云工作负载保护平台 (CWPP)。 为了提高混合登陆区域的安全性，需要保护托管在 Azure 和其他位置的数据和资产。
  • Microsoft Defender for Containers 将 Microsoft Defender for Cloud 的功能扩展到了已启用 Azure Arc 的 Kubernetes。 若要提高混合登陆区域的安全性，请考虑：
    • 使用已启用 Azure Arc 的 Kubernetes 扩展在 Microsoft Defender for Cloud 中加入已启用 Arc 的 Kubernetes 资源。
    • 为所有订阅启用 Microsoft Defender for Containers 计划。 默认情况下，该计划配置为在任何已加入同一订阅的已启用 Arc 的 Kubernetes 群集上自动部署 Defender 扩展。 可以选择性地修改此配置。
    • 验证 Defender 扩展是否部署在群集上。
    • 使用安全信息和事件管理 (SIEM) 与 Microsoft Defender for Cloud 和 Azure Sentinel 的集成。

下图演示了已启用 Azure Arc 的 Kubernetes 群集资源上的 Microsoft Defender for Cloud 的概念参考体系结构。

描绘已启用 Azure Arc 的 Kubernetes 的 Microsoft Defender 的图。

如果使用 Microsoft 容器注册表作为中心专用 Docker 注册表来存储和管理容器映像，则应使用 Microsoft Defender for Containers 来扫描映像中的漏洞。

请务必查看网络拓扑和连接关键设计领域。

安全群集访问

Kubernetes API 接收请求以在群集中执行操作。 由于这是与群集交互和管理群集的集中方式，因此 Kubernetes API 是应予以保护的关键部分。 使用已启用 Azure Arc 的 Kubernetes 群集连接，可以在任何位置安全地连接到已启用 Azure Arc 的 Kubernetes 群集，而无需在防火墙上启用任何入站端口。 访问已启用 Azure Arc 的 Kubernetes 的 API 服务器可获得以下好处：

  • 启用交互式调试和故障排除。
  • 允许使用 Azure Pipelines、GitHub Actions 或任何其他托管 CI/CD 服务的托管代理/运行程序，而无需自承载代理。
  • 向 Azure 服务提供对自定义位置及其上创建的其他资源的群集访问权限。

微服务的可观测性和安全性

实现服务网格可以在服务连接中引入身份验证和授权，从而强制实施最低特权原则并创建更安全的环境。 pod 默认位于平稳的受信任网络上。 服务网格实现中部署了一组充当网络代理的挎斗。 这些挎斗管理东西方向的通信、加密流量以及改善流量的整体可观测性。

服务网格实现可以防止：

  • 未经授权的访问
  • 嗅探攻击
  • 数据泄露
  • 模拟

有关详细信息，请查看 Open Service Mesh 实现关键设计领域。

后续步骤

有关混合云和多云旅程的详细信息，请参阅以下文章。