Azure Kubernetes Service (AKS) 受监管工作负载的基线集群

此参考实施演示了受监管合规要求（如PCI）的 AKS 集群 的推荐起点（基线）基础设施架构。该实施直接基于 AKS 基线集群参考实施，并在此基础上增加了在受监管环境中比典型的"公共云"消费模式更常见的额外实施点。

合规性

Azure 和 AKS 能够为您提供必要的工具，并允许您建立流程，以帮助您实现合规的托管基础设施。实施细节可能很复杂，整个合规过程也是如此。我们以相当详细的方式介绍部署过程，以帮助您理解此架构的每个组成部分，向您讲解每一层，并为您提供将其应用于您独特的合规范围工作负载所需的知识。

即使您不在受监管环境中，这种基础设施也展示了一个比 AKS 基线中呈现的通用集群具有更高安全态势的 AKS 集群。您可能会发现从这里选择一些概念并将其应用于非受监管的工作负载很有用（但要权衡增加的复杂性和托管成本）。

Azure 架构中心指南

本项目有一系列配套文章，描述了设计用于托管落入 PCI-DSS 3.2.1 范围内的工作负载的 AKS 集群所面临的挑战、设计模式和最佳实践。您可以在 Azure 架构中心找到这篇文章：Azure Kubernetes Service (AKS) 用于 PCI-DSS 3.2.1 的受监管集群。如果您还没有阅读过，我们建议您阅读它；因为它将为本实施中应用的考虑因素提供额外的背景。本存储库主要关注部署问题，而合规问题主要在上面链接的文章系列中讨论。

架构

这个参考实施更侧重于基础设施，而不是工作负载。它集中处理 AKS 集群本身。这个实施会涉及工作负载问题，但不包含关于范围内工作负载架构、容器安全性或隔离的端到端指导。这里展示了一些良好实践并讨论了其他实践，但并不详尽。

这里呈现的实施是大多数落入合规范围的 AKS 集群的最小起点。这个实施与 Azure 服务集成，将提供可观察性，提供支持公共流量隔离的网络拓扑，并保持集群内流量的安全。这种架构应被视为托管受监管工作负载的集群在预生产和生产阶段的架构起点。

这里的材料相对密集。我们强烈建议您先阅读上面链接的 Azure 架构中心指南，然后至少花四个小时仔细阅读这些说明，带着学习的心态。您不会在这里找到任何"一键式"部署。然而，一旦您理解了涉及的组件，并确定了您的团队与更大的 IT 组织之间的共同责任，我们鼓励您围绕最终的基础设施建立可审核的部署流程。

最后，这个实施使用一个小型自定义应用程序作为示例工作负载。这个工作负载并不特别有趣，因为它仅用于帮助您体验基础设施并说明现有的网络和安全控制。工作负载及其部署并不代表受监管工作负载的任何"最佳实践"。

核心架构组件

Azure 平台

• AKS v1.27
  • 系统和用户节点池分离
  • AKS 管理的 Microsoft Entra ID
  • kubelet 和控制平面的托管身份
  • Azure CNI
  • Azure Monitor for containers
  • 私有集群（Kubernetes API 服务器）
  • Azure Workload Identity
• Azure 虚拟网络（中心辐射型）
  • Azure 防火墙管理的出口
  • 中心代理 DNS
  • 自带无公共 DNS 表示的 AKS 私有 DNS 区域
• Azure 应用程序网关（WAF - OWASP 3.2）
• AKS 管理的内部负载均衡器
• 用于维护访问的 Azure Bastion
• 启用 Private Link 的 Key Vault 和 Azure 容器注册表
• 私有 Azure 容器注册表任务运行器

集群内开源软件组件

• Azure Workload Identity [AKS 管理的插件]
• Flux GitOps Operator [AKS 管理的扩展]
• Falco
• Kubernetes Reboot Daemon
• Secrets Store CSI Driver for Kubernetes [AKS 管理的插件]
• NGINX Ingress Controller
• Open Service Mesh

网络拓扑

工作负载 HTTPS 请求流

部署参考实施

AKS 托管工作负载的部署通常在身份和安全组管理、主机网络、集群基础设施以及最终工作负载本身等方面经历职责分离和生命周期管理。在此参考实施中，您将跨这些不同角色工作。受监管环境要求强有力的、有文档记录的关注点分离；但最终您将决定每个边界应该在哪里。

另外，请记住这项工作的主要目的是说明此集群中的拓扑和决策。一个引导式的"逐步"流程将帮助您了解解决方案的各个部分，并让您深入了解它们之间的关系。对基础设施、其供应链和"第二天"工作流程的深入理解对于合规性问题至关重要。如果您无法解释每个决策点和理由，审核对话可能很快变得不舒服。

最终，集群、其依赖项和工作负载的生命周期/SDLC 管理将取决于您的具体情况。您需要考虑团队角色、集中和分散的 IT 角色、组织标准、行业期望以及合规审核员的具体要求。

从准备订阅部分开始这个学习之旅。 如果您一直跟随到最后，您将在自己的 Azure 订阅中安装我们推荐的受监管行业基线集群，并运行一个示例工作负载供您参考。

1. :rocket: 准备订阅

在开始部署集群之前，必须解决一些考虑因素。我在订阅和 Microsoft Entra 租户中是否有足够的权限来进行这么大规模的部署？这些工作有多少将由我的团队直接处理，又有多少将由另一个团队负责？

• 首先确保您安装并满足先决条件。
• 获取所需的TLS证书。
• 规划您的Microsoft Entra集成。
• 对目标订阅应用Azure策略和Microsoft Defender for Cloud配置。

2. 构建区域网络中心

这个参考实现基于传统的中心辐射模型构建，通常存在于您组织的连接订阅中。中心将包含Azure防火墙、DNS转发器和Azure Bastion服务。

• 构建区域中心以控制和监控辐射流量。

3. 规划Kubernetes API服务器访问

由于AKS服务器是一个"私有集群"，控制平面不会暴露在互联网上。现在管理只能在与AKS暴露的私有端点有网络视线的情况下执行。在这种情况下，您将构建一个由Azure Bastion前端的跳板机。

• 在隔离的网络辐射中构建集群操作VM镜像。
• 为操作VM镜像构建cloud-init配置。

4. 部署集群

这是本参考实现指导的核心；与先前的网络拓扑指导配套。在这里，您将为集群部署Azure资源以及相邻服务，如Azure应用程序网关WAF、Azure Monitor、Azure容器注册表和Azure Key Vault。这也是您将验证集群是否引导的地方。

• 部署目标网络辐射，集群将安置在其中。
• 通过部署和填充Azure容器注册表和Azure Key Vault为集群引导做准备。这包括将集群镜像通过隔离。
• 部署AKS集群和支持服务。
• 验证集群访问和引导。

5. 部署您的工作负载

一个由四个相互连接的服务组成的简单工作负载被手动部署在两个命名空间中，以说明诸如节点池放置、零信任网络策略以及应用的NSG和Azure防火墙规则提供的外部基础设施保护等概念。

• 部署工作负载。

6. :checkered_flag: 验证

现在集群和示例工作负载已部署；现在是时候看看集群如何运作了。

• 执行端到端部署验证。
• 查看资源日志和Microsoft Defender for Cloud数据

7. :broom: 清理资源

在前面步骤中部署的大多数Azure资源如果不删除将持续产生账单影响。

• 清理所有资源

职责分离

所有处于合规范围内的工作负载通常需要一个文档化的职责/关注点分离实施计划。Kubernetes提出了一个有趣的挑战，因为它涉及IT组织中通常发现的大量角色。网络、身份、安全运营、治理、工作负载团队、集群运营、部署管道等等。如果您正在寻找如何考虑划分与AKS集群相邻的角色的起点，请考虑查看我们作为本参考实现一部分提供的Microsoft Entra角色指南。

:notebook: 有关更多信息，请参阅Azure架构中心关于AKS中PCI-DSS 3.2.1要求7、8和9的指导。

就这些吗，那...呢!?

是的，确实存在一些超出本实现合理演示范围的考虑因素。这个参考实现努力使大多数人都能够接受，而不对用于此演练的订阅施加不当负担。这意味着选择具有相对较大默认配额的SKU，不使用区域可用性非常有限的功能，不要求学习者被"自带加密密钥"等服务选项所困扰等。这一切都是为了希望更多人能够完成此演练，而不会中断或需要与订阅或管理组所有者过度协调。

对于您的实现，将此起点作为基础，并添加整个演练和Azure架构中心指南中讨论的但未直接实现的其他安全措施。例如，启用JIT和条件访问策略，如果适用于您的工作负载，请使用加密主机功能等。

有关您架构的其他考虑事项列表，请参阅我们的附加考虑事项文档。

成本

这个参考实现在前30天内空闲时每天大约需要95美元；随着时间的推移，您可以预期它会增加，因为一些Microsoft Defender for Cloud工具有免费试用期，日志也会继续累积。起始成本的最大贡献者是Azure防火墙、AKS节点池（虚拟机规模集）和Log Analytics。虽然一些成本通常是集群操作员成本，如节点池VMSS、Log Analytics、增量Microsoft Defender for Cloud成本；其他成本可能会在多个业务单位或应用程序之间分摊，如Azure防火墙。

一些客户会选择通过在其组织内托管多租户集群来分摊集群成本，通过工作负载多样性最大化密度。对于受监管的工作负载，不建议这样做。受监管的环境通常会优先考虑合规性和安全性（隔离）而不是成本（多样化密度）。

最后的想法

Kubernetes是一个非常灵活的平台，为基础设施和应用程序操作员提供了许多选择来实现其业务和技术目标。在您的旅程中的某些点上，您需要考虑何时依赖Azure平台功能、CNCF OSS解决方案、ISV解决方案、支持渠道，以及需要哪些操作流程。我们鼓励将此参考实现作为您在自己团队内开始架构对话的地方；根据您的具体要求进行调整，并最终提供一个让您的客户和审计员都满意的解决方案。

相关文档

• Azure Kubernetes Service基线架构
• Azure Kubernetes Service文档
• Microsoft Azure架构良好的框架
• AKS上的微服务架构

贡献

请查看我们的贡献指南。

本项目采用了Microsoft开源行为准则。有关更多信息，请参阅行为准则常见问题或联系opencode@microsoft.com获取任何其他问题或意见。

来自Microsoft模式与实践，Azure架构中心的 :heart:。