通过

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

Azure Kubernetes 服务上的 DevSecOps （AKS）

Azure Boards
Azure DevOps
Azure Monitor
Azure Pipelines
Azure Policy

DevSecOps 也称为 Secure DevOps，基于 DevOps 的做法，在传统 DevOps 生命周期的不同阶段整合安全性。 在 DevOps 实践中构建安全性的一些好处包括：

  • 通过提供安全威胁的可见性并防止漏洞到达已部署的环境，使应用程序和系统更加安全
  • 通过开发和运营团队提高安全意识
  • 将自动化安全流程合并到软件开发生命周期中
  • 通过在开发和设计阶段尽早发现安全问题来降低成本进行修正

将 DevSecOps 应用于 Azure Kubernetes 服务（AKS）时，不同的组织角色可以有不同的注意事项来实现安全性。 这些不同组织角色的示例包括：

  • 构建在 AKS 上运行的安全应用程序的开发人员
  • 云工程师构建安全的 AKS 基础结构
  • 可能管理群集或监视安全问题的各种作团队

本文分为不同的 DevOps 生命周期阶段，其中包含嵌入安全控件和安全最佳做法的注意事项和建议。 本指南包括用于纳入持续集成和持续交付（CI/CD）管道的常见流程和工具，选择在可用的情况下使用易于使用的内置工具。

作为本文的先决条件，建议 使用 DevOps 和 GitOps 在 AKS 上查看生成和部署应用。

流程流

体系结构图显示了从开发人员到最终用户的流，以及可在 AKS 上使用 DevSecOps 的位置。

下载此体系结构的 Visio 文件。

注释

虽然本文引用 AKS 和 GitHub，但这些建议适用于任何容器业务流程或 CI/CD 平台。 虽然实现详细信息可能有所不同，但每个阶段中提到的大多数概念和做法仍然相关且适用。

  1. Microsoft Entra ID 配置为 GitHub 的标识提供者。 配置多重身份验证（MFA），以帮助提供额外的身份验证安全性。
  2. 开发人员使用启用了安全扩展插件的 Visual Studio Code 或 Visual Studio 主动分析其代码是否存在安全漏洞。
  3. 开发人员将应用程序代码提交到公司拥有和管理的 GitHub Enterprise 存储库。
  4. GitHub Enterprise 通过 GitHub 高级安全性集成自动安全性和依赖项扫描。
  5. 拉取请求通过 GitHub Actions 触发持续集成（CI）生成和自动化测试。
  6. 通过 GitHub Actions 生成 CI 生成工作流会生成一个存储在 Azure 容器注册表中的 Docker 容器映像。
  7. 可以在 GitHub Actions 中持续交付（CD）工作流中为特定环境（例如生产）部署引入手动审批。
  8. GitHub Actions 支持 CD 到 AKS。 使用 GitHub 高级安全性检测应用程序源和配置文件中的机密、凭据和其他敏感信息。
  9. Microsoft Defender 用于扫描 Azure 容器注册表、AKS 群集和 Azure Key Vault 中的安全漏洞。
    1. Microsoft Defender for Containers 在将容器映像上传到容器注册表时扫描容器映像中的已知安全漏洞。
    2. 还可以使用 Defender for Containers 对 AKS 环境执行扫描，并为 AKS 群集提供运行时威胁防护。
    3. Microsoft Defender for Key Vault 可检测访问密钥保管库帐户的有害和异常的可疑尝试。
  10. 可将 Azure Policy 应用于容器注册表和 Azure Kubernetes 服务（AKS），以便实施策略合规性和强制实施。 容器注册表和 AKS 的常见安全策略内置于快速启用中。
  11. Azure Key Vault 用于在运行时安全地将机密和凭据注入应用程序，将敏感信息与开发人员分开。
  12. AKS 网络策略引擎配置为使用 Kubernetes 网络策略帮助保护应用程序 Pod 之间的流量。
  13. 可以使用 Azure Monitor 和 容器见解 来引入性能指标并分析应用程序和安全日志来设置 AKS 群集的持续监视。
    1. 容器见解检索性能指标和应用程序和群集日志。
    2. 诊断日志和应用程序日志会提取到 Azure Log Analytics 工作区中，以运行日志查询。
  14. Microsoft Sentinel 是一种安全信息和事件管理（SIEM）解决方案，可用于根据定义的模式和规则引入和进一步分析 AKS 群集日志中是否存在任何安全威胁。
  15. Open-Source 工具（例如 Zed 攻击代理（ZAP）（ZAP）可用于对 Web 应用程序和服务执行渗透测试。
  16. Defender for DevOps 是 Defender for Cloud 中提供的一项服务，可让安全团队跨多管道环境（包括 GitHub 和 Azure DevOps）管理 DevOps 安全性。

团队成员概述和职责

考虑在基于 Kubernetes 的解决方案部署上管理 DevSecOps 的复杂性，作为关注点分离。 企业环境中的哪个团队应该关注部署的各个方面？ 团队应采用哪些工具和流程来最好地实现其目标？ 在本部分中，我们将介绍开发人员、应用程序作员（站点可靠性工程师）、群集作员和安全团队的共同角色。

开发人员

开发人员负责编写应用程序代码。 他们还负责将代码提交到指定的存储库。 开发人员的重要职责之一还包括创作和运行用于自动测试的脚本，以确保其代码按预期工作，并与应用程序的其余部分无缝集成。 他们还将容器映像的生成定义为自动化管道的一部分并编写脚本。

应用程序作员（站点可靠性工程师）

使用容器和 Kubernetes 在云上构建应用程序可以简化应用程序开发、部署和可伸缩性。 但这些开发方法也创造了日益分散的环境，使管理复杂化。 站点可靠性工程师构建解决方案，以自动监督大型软件系统。 它们充当开发和群集运营商团队之间的桥梁，有助于建立和监视服务级别目标和错误预算。 通过这种方式，它们有助于管理应用程序部署，并经常编写 Kubernetes 清单 （YAML） 文件。

群集运算符

群集作员负责配置和管理群集基础结构。 它们通常使用基础结构即代码（IaC）最佳做法和框架（如 GitOps ）来预配和维护其群集。 它们使用各种监视工具（例如 Azure Monitor 容器见解和 Prometheus/Grafana）来监视整体群集运行状况。 它们负责修补、群集升级、权限和群集上基于角色的访问控制。 在 DevSecOps 团队中，他们确保群集满足团队的安全要求，并与安全团队合作创建这些标准。

安全团队

安全团队负责制定安全标准并强制执行这些标准。 某些团队可能负责创建并选择在包含群集的订阅和资源组中强制执行的 Azure Policy。 它们监视安全问题，与其他团队一起，确保安全在 DevSecOps 过程的每一步中都处于最前沿。

DevSecOps 生命周期阶段

安全控制在软件开发生命周期（SDLC）的每个阶段实施。 此实现是 DevSecOps 策略和 Shift-left 方法的关键部分。

体系结构图显示了从开发人员到最终用户的流，以及可在 AKS 上使用 DevSecOps 的位置。

下载此体系结构的 Visio 文件。

计划阶段

计划阶段通常具有最少的自动化，但它具有重要的安全影响，这严重影响了 DevOps 生命周期的后续阶段。 此阶段涉及安全、开发和运营团队之间的协作。 在此设计和规划阶段包括安全利益干系人，可确保适当考虑或缓解安全要求和安全问题。

最佳做法 - 设计更安全的应用程序平台

构建更安全的 AKS 托管平台是帮助确保从平台本身开始在每个层系统中内置安全性的重要步骤。 平台可以包括群集内部的组件（例如运行时安全和策略代理）以及 AKS 外部的组件（例如网络防火墙和容器注册表）。 有关详细信息，请参阅 应用程序登陆区域中的 AKS，其中包括安全、标识和网络拓扑等关键设计区域。

最佳做法 - 将威胁建模构建到流程中

  • 威胁建模通常是涉及安全和开发团队的手动活动。 它用于在系统中建模和查找威胁，以便在任何代码开发或更改系统之前解决漏洞。 威胁建模可能在不同时间发生，由重大软件更改、解决方案体系结构更改或安全事件等事件触发。
  • 建议使用 STRIDE 威胁模型。 此方法从数据流关系图开始，并使用 STRIDE 助记（欺骗、篡改、信息泄露、拒绝、拒绝、拒绝服务和特权提升）威胁类别，使团队能够识别、缓解和验证风险。 它还包括用于表示和可视化系统组件、数据流和安全边界的 建模工具 。 在 SDLC 流程中构建威胁建模引入了新流程，并且为维护更新的威胁模型而做更多工作。 但它有助于确保安全提前到位，这有助于降低处理后续 SDLC 阶段发现的安全问题的潜在成本。

最佳做法 - 应用 Azure Well Architect Framework （WAF）

  • 应用 WAF 安全支柱 最佳做法，为标识管理、应用程序安全性、基础结构保护、日期安全性和 DevOps 等内容提供指南，因为它适用于云原生环境。
  • 应用 WAF作 最佳做法，因为它适用于 DevSecOps 并监视生产环境。

开发阶段

“向左转移”是 DevSecOps 思维模式的关键租户。 此过程在代码甚至提交到存储库并通过管道部署之前开始。 采用安全编码最佳做法，并在开发阶段使用 IDE 工具和插件进行代码分析，有助于在开发生命周期早期更轻松地解决安全问题。

最佳做法 - 强制实施安全编码标准

  • 通过使用已建立的安全编码最佳做法和清单，可帮助保护代码免受常见漏洞（如注入和不安全设计）的保护。 OWASP 基础发布在编写代码时应采用的行业标准安全编码建议。 开发面向公众的 Web 应用程序或服务时，这些准则尤为重要。
  • 除了一般安全最佳做法外，还应了解特定编程语言运行时（如 Java 和 .NET）的安全编码做法。
  • 可以强制实施日志记录标准，防止敏感信息泄露到应用程序日志中。 最常见的日志记录框架（如 log4j 和 log4net）提供筛选器和插件来屏蔽敏感信息，例如帐户号或个人数据。

最佳做法 - 使用 IDE 工具和插件自动执行安全检查

最常见的 IDE（如 Visual Studio、Visual Studio Code、IntelliJ IDEA 和 Eclipse）支持可用于获取在编写应用程序代码时可能引入的潜在安全问题的即时反馈和建议。

  • SonarLint 是一个 IDE 插件，适用于最常用的语言和开发人员环境。 SonarLint 提供有价值的反馈，并自动扫描代码中常见的编程错误和潜在的安全问题。
  • 其他免费和商业插件侧重于安全特定项，例如 OWASP 前 10 个常见漏洞。 例如， Synk 插件还会扫描应用程序源和第三方依赖项，并在发现任何漏洞时发出警报。
  • Visual Studio 和 Visual Studio Code 的 静态分析结果交换格式 （SARIF） 插件使你能够以直观且易于阅读的方式轻松查看常用静态应用程序安全测试（SAST）工具中的漏洞，而不是解释原始 JSON 输出文件中的结果。

最佳做法 - 在源代码存储库上建立控件

  • 建立分支方法，以便在整个企业中一致地使用分支。 发布流和 GitHub 流等方法具有有关如何使用分支来支持团队和并行开发的结构化指南。 这些方法可帮助团队建立代码提交和合并到 CI/CD 工作流的标准和控制。
  • 某些分支（例如 main）是持久分支，可保留应用程序源代码的完整性。 这些分支应已建立合并策略，然后才能将更改合并或提交到其中。 一些最佳做法包括：
    • 阻止其他开发人员将代码直接提交到主分支。
    • 建立对等评审过程，在将更改合并到主分支之前，需要最少数量的审批。 可以使用 GitHub 轻松配置和强制实施这些控件。 GitHub 还允许你根据需要为封闭环境指定授权审批者组。
  • 使用 预提交挂钩 检查应用程序源代码中的敏感信息，并在发现安全问题时防止提交发生。
    • 使用 GitHub 提供的内置预提交挂钩，可以轻松地为特定项目配置挂钩。 例如，有预先构建的挂钩用于扫描机密、私钥和凭据，并在发现这些问题时阻止提交。
  • 在版本控制系统中建立基于角色的访问控制。
    • 使用最小特权原则创建定义良好的角色。 CI/CD 管道是用于生产部署的供应链。
    • 在组织中应用已建立的用户或组 角色 。 必须创建管理员、开发人员、安全管理员和作员等角色，以便根据个人的特定角色和功能对 CI/CD 工作流进行分组。
  • 启用对工作流的 审核 ，以便针对 CI/CD 管道的配置和其他更改提供透明度和可跟踪性。

最佳做法 - 保护容器映像

  • 使用具有最小 OS 占用空间的轻量映像来减少整体外围攻击区域。 考虑仅包含应用程序及其关联运行时的最小图像（例如 Alpine 甚至无发行版图像）。 Microsoft开源 Linux 分发版的 Mariner 是一种轻型强化分发版，专为 AKS 托管容器化工作负载而设计。
  • 生成容器时，仅使用受信任的基础映像。 应从经常扫描漏洞的专用注册表中检索这些基本映像。
  • 使用开发人员工具在本地评估图像漏洞。
    • Trivy 是一个开源工具示例，可用于分析容器映像中的安全漏洞。
  • 阻止图像的根用户访问/上下文。 默认情况下，容器以根身份运行。
    • 对于需要增强安全性的容器，请考虑在 Kubernetes 群集中使用 AppArmor 配置文件进一步帮助强制实施正在运行的容器的安全性。

生成阶段

在生成阶段，开发人员与站点可靠性工程师和安全团队协作，在 CI 生成管道中集成应用程序源的自动扫描。 管道配置为使用 CI/CD 平台的安全工具和扩展启用安全做法，例如 SAST、SCA 和机密扫描。

最佳做法 - 执行静态代码分析（SAST），以查找应用程序源代码中的潜在漏洞

  • 使用 GitHub 高级安全扫描功能进行代码扫描和 CodeQL。
    • 代码扫描 是一项功能，可用于分析 GitHub 存储库中的代码，以查找安全漏洞和编码错误。 分析确定的任何问题都显示在 GitHub Enterprise Cloud 中。
    • 如果代码扫描在代码中发现潜在的漏洞或错误，GitHub 会在存储库中显示警报。
    • 还可以为 所需的状态检查配置分支规则，例如，在合并任何新代码之前，强制功能分支与基分支保持最新状态。 这种做法可确保分支始终使用最新代码进行测试。
  • 使用 kube 分数 等工具分析 Kubernetes 部署对象。
    • kube-score 是一种工具，用于对 Kubernetes 对象定义执行静态代码分析。
    • 输出是一系列建议，其中列出了可改进的内容，以帮助提高应用程序的安全性和复原能力。

最佳做法 - 执行机密扫描以防止意外使用存储库的机密的欺诈性

  • 为存储库启用 机密扫描 后，GitHub 会扫描代码中是否存在与许多服务提供商使用的机密匹配的模式。
  • GitHub 还会定期运行存储库中现有内容的完整 git 历史记录扫描，并发送警报通知。
    • 对于 Azure DevOps，Defender for Cloud 使用机密扫描来检测源代码和生成输出中的凭据、机密、证书和其他敏感内容。
    • 机密扫描可以作为 azure DevOps 扩展Microsoft安全 DevOps 的一部分运行。

最佳做法 - 使用软件组合分析 （SCA） 工具跟踪代码库中的开源组件，并检测依赖项中的任何漏洞

  • 依赖项评审 允许在将依赖项引入环境之前捕获不安全的依赖项，并提供有关许可证、依赖项和依赖项年龄的信息。 它在拉取请求的“文件已更改”选项卡上提供了一个易于理解的依赖项更改可视化效果。
  • Dependabot 执行扫描以检测不安全的依赖项，并在将新公告添加到 GitHub 顾问数据库或存储库依赖项关系图更改时发送 Dependabot 警报。

最佳做法 - 启用基础结构即代码 （IaC） 模板的安全扫描，以最大程度地减少到达生产环境的云配置错误

  • 在整个开发生命周期内主动监视云资源配置。
  • Microsoft Defender for DevOps 支持 GitHub 和 Azure DevOps 存储库。

最佳做法 - 扫描容器注册表中的工作负荷映像以识别已知漏洞

  • Defender for Containers 会扫描容器注册表和 Amazon AWS 弹性容器注册表（ECR）中的容器，以便在映像中存在已知漏洞时通知你。
  • Azure Policy 可以启用对容器注册表中存储的所有映像执行漏洞评估，并提供有关每个发现的详细信息。

最佳做法 - 在基础映像更新上自动生成新映像

  • Azure 容器注册表任务 在生成容器映像时动态发现基础映像依赖项。 因此，它可以检测应用程序映像的基础映像何时更新。 使用一个预配置生成任务，容器注册表任务可以自动重新生成引用基础映像的每个应用程序映像。

最佳做法 - 使用容器注册表、Azure Key Vault 和表示法对容器映像进行数字签名，并将 AKS 群集配置为仅允许验证的映像

  • Azure Key Vault 存储签名密钥，可通过表示法 Key Vault 插件（azure-kv）进行 表示 法来 签名 和验证容器映像和其他项目。 容器注册表允许使用 Azure CLI 命令附加这些签名。
  • 签名的容器允许用户确保从受信任的实体生成部署，并验证项目自创建以来未被篡改。 签名的项目可确保在用户将项目拉入任何环境之前的完整性和真实性，这有助于避免攻击。
    • 批准 允许 Kubernetes 群集在部署之前验证项目安全元数据，并仅允许部署符合所创建的允许策略的项目安全元数据。

部署阶段

在部署阶段，开发人员、应用程序作员和群集作员团队共同为持续部署（CD）管道建立正确的安全控制，以更安全、更自动化的方式将代码部署到生产环境。

最佳做法 - 控制部署管道的访问和工作流

  • 可以通过设置分支保护规则 来保护 重要分支。 这些规则定义协作者是否可以删除或强制推送到分支。 他们还设置对向分支的任何推送的要求，例如传递状态检查或线性提交历史记录。
  • 通过使用 环境 进行部署，可以配置具有保护规则和机密的环境。
  • 可以利用 审批 和 入口 功能来控制部署管道的工作流。 例如，在部署到生产环境之前，可以要求安全团队或运营团队进行手动批准。

最佳做法 - 安全部署凭据

  • OpenID Connect（OIDC） 允许 GitHub Action 工作流访问 Azure 中的资源，而无需将 Azure 凭据存储为长期存在的 GitHub 机密。
  • 通过使用环境进行部署，可以配置具有保护规则和机密的环境。
    • 使用 GitOps 通过基于 CI/CD 的拉取方法，可以将安全凭据转移到 Kubernetes 群集，从而通过删除凭据并将其存储在外部 CI 工具中来降低安全性和风险面。 还可以减少允许的入站连接，并限制对 Kubernetes 群集的管理级访问。

最佳做法 - 运行动态应用程序安全测试（DAST），以查找正在运行的应用程序中的漏洞

  • 在部署工作流中使用 GitHub Actions 运行动态应用程序安全测试（DAST）测试。
  • 使用开源工具（如 ZAP ）对常见的 Web 应用程序漏洞执行渗透测试。

最佳做法 - 仅从受信任的注册表部署容器映像

  • 使用 Defender for Containers 为 Kubernetes 启用 Azure Policy 加载项。
  • 启用 Azure Policy，以便只能从受信任的注册表部署容器映像。

作阶段

在此阶段，将执行作监视和安全监视任务，以主动监视、分析和警报潜在安全事件。 生产可观测性工具（如 Azure Monitor 和 Microsoft Sentinel）用于监视并确保符合企业安全标准。

最佳做法 - 使用 Microsoft Defender for cloud 启用对生产配置的自动扫描和监视

  • 运行持续扫描以检测应用程序漏洞状态的偏移，并实现修补和替换易受攻击映像的过程。
  • 为作系统实现自动化配置监视。
    • 使用 Microsoft Defender for Cloud 容器建议（在 “计算和应用 ”部分下）为 AKS 群集执行基线扫描。 在找到配置问题或漏洞时，在 Microsoft Defender for Cloud 仪表板中收到通知。
    • 使用 Microsoft Defender for Cloud 并遵循其网络保护建议来帮助 保护 AKS 群集使用的网络资源。
  • 对容器注册表中存储的映像执行漏洞评估。

最佳做法 - 使 Kubernetes 群集保持更新

  • Kubernetes 版本经常推出。 必须制定生命周期管理策略，以确保不会落后和不受支持。 AKS 是一种托管产品/服务，可提供管理此升级过程的工具和灵活性。 可以使用 AKS 平台的计划内维护功能来更好地控制维护时段和升级。
  • 应更频繁 地升级 AKS 工作器节点。 我们提供每周的 OS 和运行时更新，这些更新可以通过无人参与模式或 Azure CLI 自动应用，以便进行更多控制和全面的更新。

最佳做法 - 使用 Azure Policy 保护和管理 AKS 群集

  • 为 AKS 安装 Azure Policy 加载项后，可以将单个策略定义或称为计划（也称为策略集）的策略定义组应用到群集。
  • 对常见方案（例如阻止特权容器运行或仅批准允许列表的外部 IP）使用 内置 Azure 策略 。 还可以针对特定用例创建自定义策略。
  • 将策略定义应用到群集，并验证是否强制实施这些分配。
  • 使用 Gatekeeper 配置允许或拒绝基于指定规则的部署的允许控制器。 Azure Policy 扩展 Gatekeeper。
  • 在 AKS 中使用网络策略保护工作负荷 Pod 之间的流量。
    • 安装网络策略引擎并创建 Kubernetes 网络策略 来控制 AKS 中 Pod 之间的流量流。 网络策略可用于 AKS 中基于 Linux 或基于 Windows 的节点和 Pod。

最佳做法 - 使用 Azure Monitor 进行持续监视和警报

  • 使用 Azure Monitor 从 AKS 收集日志和指标。 你可以深入了解应用程序和基础结构的可用性和性能。 它还允许你访问信号来监视解决方案的运行状况并提前发现异常活动。
    • 使用 Azure Monitor 进行持续监视可以扩展到基于监视数据的入口或回滚发布管道。 Azure Monitor 还会引入安全日志，并可以针对可疑活动发出警报。
    • 将 AKS 实例加入 Azure Monitor 并为群集配置诊断设置。

最佳做法 - 使用 Microsoft Defender for Cloud 进行主动威胁监视

  • Microsoft Defender for Cloud 在节点级别（VM 威胁）和内部的 AKS 上提供主动威胁监视。
  • Defender for DevOps 应用于全面可见性，并为所有 CI/CD 管道提供一个集中式仪表板，为安全和作员团队提供一个仪表板。 如果使用的是 Azure DevOps 和 GitHub 等多管道平台，或者跨公有云运行管道，此功能尤其有用。
  • Defender for Key Vault 可用于检测异常、可疑的访问密钥保管库帐户的尝试，并且可以根据配置向管理员发出警报。
  • Defender for Containers 可以针对容器注册表中存储的容器映像中发现的漏洞发出警报。

最佳做法 - 启用集中式日志监视并使用 SIEM 产品监视实时安全威胁

  • 将 AKS 诊断日志连接到 Microsoft Sentinel，以便基于模式和规则集中进行安全监视。 Sentinel 通过 数据连接器无缝启用此访问。

最佳做法 - 启用审核日志记录以监视生产群集上的活动

  • 使用活动日志监视 AKS 资源上的作，以查看所有活动及其状态。 确定对资源以及由谁执行的作。
  • 通过在 CoreDNS 自定义 ConfigMap 中应用记录的配置来启用 DNS 查询日志记录 。
  • 监视访问已停用凭据的尝试。
    • 将 AKS 的用户身份验证与 Microsoft Entra ID 集成。 为 Microsoft Entra ID 创建诊断设置，将审核日志和登录日志 发送到 Azure Log Analytics 工作区。 在 Azure Log Analytics 工作区中配置所需的警报（例如停用的帐户尝试登录时）。

最佳做法 - 在 Azure 资源上启用诊断

  • 通过跨所有工作负荷的资源启用 Azure 诊断，可以访问提供 Azure 资源的详细诊断和审核信息的平台日志。 这些日志可以引入到 Log Analytics 或 SIEM 解决方案（如 Microsoft Sentinel）中，以便进行安全监视和警报。

供稿人

本文由Microsoft维护。 它最初是由以下贡献者撰写的。

主要作者：

其他参与者：

后续步骤