你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
DevSecOps 也称为 Secure DevOps，基于 DevOps 的做法，在传统 DevOps 生命周期的不同阶段整合安全性。 将安全性构建到 DevOps 实践中，以便：
使应用程序和系统更安全，提供安全威胁的可见性，并防止漏洞到达已部署的环境。
提高开发和运营团队的安全意识。
将自动化安全流程纳入软件开发生命周期（SDLC）。
通过在开发和设计阶段尽早发现安全问题来降低修正成本。
将 DevSecOps 应用到 Azure Kubernetes 服务（AKS）时，每个组织角色都有特定的安全注意事项：
开发人员生成在 AKS 上运行的安全应用程序。
云工程师构建安全的 AKS 基础结构。
运营团队可能会管理群集或监视安全问题。
本文按 DevOps 生命周期阶段组织指南，并提供有关安全控件和最佳做法的建议。 它涵盖了用于持续集成和持续交付（CI/CD）管道的常见流程和工具，重点介绍内置工具。
流程流
下载此体系结构的 Visio 文件。
注释
本文引用 AKS 和 GitHub，但可以将这些建议应用于任何容器业务流程或 CI/CD 平台。 实现详细信息可能会有所不同，但每个阶段的大多数概念和做法仍适用。
Microsoft Entra ID被配置为GitHub的身份提供者。 配置多重身份验证（MFA），以帮助提供额外的身份验证安全性。
开发人员使用启用了安全扩展插件的 Visual Studio Code 或 Visual Studio 主动分析其代码是否存在安全漏洞。
开发人员将应用程序代码提交到公司拥有和管理的 GitHub Enterprise 存储库。
GitHub Enterprise 通过 GitHub 高级安全性集成自动安全性和依赖项扫描。
拉取请求通过 GitHub Actions 触发持续集成（CI）生成和自动化测试。
通过 GitHub Actions 的 CI 生成工作流将生成 Docker 容器映像并将其存储在 Azure 容器注册表中。
可以将部署的手动审批添加到特定环境（如生产），作为 GitHub Actions 中持续交付（CD）工作流的一部分。
GitHub Actions 支持 AKS 的 CD。 使用GitHub高级安全性检测应用程序源和配置文件中的机密、凭据和其他敏感信息。
Microsoft Defender 扫描容器注册表、AKS 群集和 Azure Key Vault 中的安全漏洞。
Microsoft Defender for Containers 在 GitHub Actions 将容器映像上传到容器注册表时扫描容器映像中的已知安全漏洞。
Defender for Containers 还可以扫描 AKS 环境并为 AKS 群集提供运行时威胁防护。
Microsoft Defender for Key Vault 检测到访问密钥保管库帐户的异常和可疑尝试。
可以将 Azure Policy 应用到容器注册表和 AKS，以强制实施策略符合性。 Azure Policy 包括容器注册表和 AKS 的内置安全策略。
Key Vault 在运行时安全地将机密和凭据注入应用程序，而无需向开发人员公开机密和凭据。
AKS 网络策略引擎配置为使用 Kubernetes 网络策略帮助保护应用程序 Pod 之间的流量。 建议 使用由 Cilium 提供支持的 Azure CNI 作为网络策略引擎。 它提供基于 eBPF 的扩展 Berkeley 数据包过滤器的强制执行、七层策略以及完全限定域名 (FQDN) 筛选。
可以使用 Azure Monitor 收集 Prometheus 指标、容器日志和 Kubernetes 事件来设置 AKS 群集的持续监视。 使用 Azure 托管 Grafana 仪表板进行可视化，使用 Log Analytics 进行基于查询的警报。
Azure Monitor 通过托管 Prometheus 收集性能指标，并通过容器日志收集系统收集应用程序和群集日志。
Log Analytics 工作区存储诊断日志和应用程序日志以运行日志查询。
使用 Microsoft Sentinel 作为集中式安全信息和事件管理（SIEM），将 AKS 遥测与来自 Microsoft Defender for Cloud、Microsoft Entra ID 和网络资源的信号相关联。 Microsoft Sentinel 在整个 AKS 环境中提供对安全事件的检测、调查和自动响应。
Zed 攻击代理（ZAP）等开源工具可以为 Web 应用程序和服务执行渗透测试。
Defender for DevOps 是 Defender for Cloud 中提供的一项服务，可让安全团队跨多pipeline 环境（包括 GitHub 和 Azure DevOps）管理 DevOps 安全性。
团队成员概述和职责
考虑在基于 Kubernetes 的解决方案部署上管理 DevSecOps 复杂性，方法是在团队之间划分职责。 本部分介绍开发人员、应用程序操作员（如站点可靠性工程师、群集操作员和安全团队）的角色和职责。
Developers
开发人员编写应用程序代码并将其提交到指定的存储库。 他们创作并运行脚本进行自动测试，以确保其代码按预期工作，并与应用程序的其余部分集成。 开发人员还将容器映像的生成定义为自动化管道的一部分并编写脚本。
应用程序作员（站点可靠性工程师）
使用容器和 Kubernetes 生成应用程序可以简化应用程序开发、部署和可伸缩性。 但这些开发方法也创造了日益分散的环境，使管理复杂化。
站点可靠性工程师构建解决方案，自动化团队如何监督大型软件系统。 它们充当开发和群集运营商团队之间的桥梁。 它们有助于建立和监视服务级别目标（SLO）和错误预算。 站点可靠性工程师还有助于管理应用程序部署和写入 Kubernetes 清单 （YAML） 文件。
群集管理器
群集操作员配置和管理群集基础结构。 它们通常使用基础结构即代码（IaC）最佳做法和框架（如 GitOps ）来预配和维护其群集。 它们使用适用于 Prometheus 和 Azure Managed Grafana 的 Azure Monitor 托管服务等监视工具监视整体群集运行状况。 他们负责群集的修补、升级、以及权限和基于角色的访问控制（RBAC）的管理。 在 DevSecOps 团队中，群集操作员与安全团队协作，建立安全标准并确保群集满足这些要求。
安全团队
安全团队开发和强制执行安全标准。 某些团队可能会创建并选择跨包含群集的订阅和资源组强制实施的 Azure Policy 定义。 安全团队监视安全问题，并与其他团队合作，在整个 DevSecOps 过程中确定安全性的优先级。
DevSecOps 生命周期阶段
SDLC 的每个阶段都实现了安全控制。 这些安全控制是 DevSecOps 和 Shift-left 做法的核心。
下载此体系结构的 Visio 文件。
计划阶段
计划阶段通常具有最少的自动化，但它具有影响后续 DevOps 生命周期阶段的重要安全影响。 此阶段涉及安全、开发和运营团队之间的协作。 若要确保考虑或缓解安全要求和安全问题，请在此阶段包括安全利益干系人。
最佳做法：设计安全的应用程序平台
若要构建安全的 AKS 托管工作负载，必须从平台本身开始，在每个层将安全性纳入系统。 该平台可以包括群集内部的组件，例如运行时安全和策略代理，以及 AKS 外部的组件，例如网络防火墙和容器注册表。
最佳做法：将威胁建模构建到流程中
威胁建模通常是涉及安全和开发团队的手动活动。 可以在开发代码或进行更改之前在系统中建模和查找威胁以解决漏洞。 团队会在响应重大软件更改、解决方案架构更改或安全事件时进行威胁建模。
建议 使用 STRIDE 威胁模型。 此方法从数据流关系图开始，并使用 STRIDE 助记法对威胁进行分类：欺骗、篡改、拒绝、信息泄露、拒绝服务和特权提升。 团队使用这些类别来识别、缓解和验证风险。 建模工具有助于指出和可视化系统组件、数据流和安全边界。
在 SDLC 中生成威胁建模会增加进程开销，并要求你维护更新的威胁模型。 但是，它在开发初期解决了安全性问题，这降低了以后发现的问题的成本。
最佳做法：应用 Azure Well-Architected 框架
开发阶段
向左移动 是 DevSecOps 思维模式的关键原则。 此过程在将代码提交到存储库之前开始，并通过管道部署它。 若要解决开发生命周期前面的安全问题，请采用安全编码最佳做法，并在开发阶段使用集成开发环境（IDE）工具和插件进行代码分析。
最佳做法：强制实施安全编码标准
使用已建立的安全编码最佳做法和清单来帮助保护代码免受常见漏洞（如注入和不安全设计）的保护。 Open Worldwide Application Security Project （OWASP） 基础发布在编写代码时应采用的行业标准安全编码建议。 开发面向公众的 Web 应用程序或服务时，这些准则尤为重要。
查看特定编程语言运行时（如 Java 和 .NET）的安全编码做法。
强制实施日志记录标准，防止敏感信息泄露到应用程序日志中。 最常见的日志记录框架（如 Apache Log4j 和 Apache log4net）提供筛选器和插件来屏蔽敏感信息，例如帐户号或个人数据。
最佳做法：使用 IDE 工具和插件自动执行安全检查
最常用的 IDE（如 Visual Studio、VS Code、IntelliJ IDEA 和 Eclipse）支持扩展，可用于获取即时反馈和建议，了解在编写应用程序代码时引入的潜在安全问题。
SonarQube for IDE 是适用于最常用的语言和开发人员环境的 IDE 插件。 SonarQube for IDE 提供反馈，并自动扫描代码中常见的编程错误和潜在的安全问题。
其他免费和商业插件侧重于特定于安全的项目，例如 OWASP 前 10 个常见漏洞。 如果发现漏洞， Snyk 插件还会扫描应用程序源和外部依赖项，并发出警报。
Visual Studio 和 VS Code 的 静态分析结果交换格式 （SARIF） 插件可让你轻松查看常用静态应用程序安全测试 （SAST） 工具中的漏洞，而不是解释原始 JSON 输出文件的结果。
最佳做法：在源代码存储库上建立控件
建立一套适用于整个企业的一致性分支方法。 发布流和 GitHub 流等方法具有有关如何使用分支来支持团队和并行开发的结构化指南。 这些方法可帮助团队建立代码提交和合并到 CI/CD 工作流的标准和控制。
某些分支（例如 main）是持久分支，可保留应用程序源代码的完整性。 在提交或合并更改之前，请为这些分支建立合并策略。 例如，您可以：
阻止其他开发人员将代码直接提交到主分支。
建立对等评审过程，在将更改合并到主分支之前，需要最少数量的审批。 使用 GitHub 配置并强制实施这些控件。 如有必要，请使用 GitHub 为封闭环境指定授权审批者组。
使用 预提交挂钩 检查应用程序源代码中的敏感信息，并在检测到安全问题时阻止提交。
- 使用 GitHub 提供的内置预提交钩子。 轻松为特定项目配置它们。 例如，某些预生成的挂钩会扫描机密、私钥和凭据，并在发现这些问题时阻止提交。
在版本控制系统中建立 RBAC。
使用最低特权原则创建定义良好的角色。 CI/CD 管道就像生产部署的供应链一样运作。
在组织中应用已建立的用户或组 角色 。 若要根据他们在 CI/CD 工作流中的特定角色和功能对个人进行分组，请创建管理员、开发人员、安全管理员和操作员等角色。
启用工作流 审核 ，为配置和其他更改添加对 CI/CD 管道的透明度和可跟踪性。
最佳做法：保护容器映像
使用占用最小操作系统空间的轻量级映像来减少整体攻击面。 考虑使用最小化镜像，例如仅包含应用程序及其关联运行时的 Alpine 或无发行版的镜像。
生成容器时，仅使用受信任的基础映像。 从您经常扫描漏洞的专用镜像库中检索这些基础映像。
使用开发人员工具在本地评估图像漏洞。 Trivy 是一种开源工具，用于分析容器映像中的安全漏洞。
阻止图像的根用户访问或上下文。 默认情况下，容器以根身份运行。
对于需要增强安全性的容器，请考虑在 Kubernetes 群集中使用 AppArmor 或 seccomp 配置文件，以进一步帮助强制实施正在运行的容器的安全性。
生成阶段
在生成阶段，开发人员与站点可靠性工程师和安全团队协作，在 CI 生成管道中集成应用程序源的自动扫描。 Teams 将管道配置为使用 CI/CD 平台的安全工具和扩展，以增强安全实践。 这些做法包括 SAST、软件组合分析（SCA）和机密扫描。
最佳做法：执行 SAST 以查找应用程序源代码中的潜在漏洞
使用 GitHub Advanced Security 的扫描功能来进行代码扫描和 CodeQL 分析。
代码扫描 是一项功能，用于分析 GitHub 存储库中的代码，以查找安全漏洞和编码错误。 它显示 GitHub Enterprise Cloud 中的问题。
如果代码扫描在代码中发现潜在的漏洞或错误，GitHub 会在存储库中显示警报。
可以为 所需的状态检查配置分支规则。 例如，在合并新代码之前，可以要求这些功能分支与基分支保持同步。 此规定可确保用最新代码测试你的分支。
启用 Copilot Autofix 以接收针对代码扫描警报的 AI 生成的修复建议。 Copilot Autofix 在拉取请求中直接提出修正，这有助于开发人员快速解决安全发现问题。
使用 kube 分数 等工具分析 Kubernetes 部署对象。 此工具对 Kubernetes 对象定义执行静态代码分析。 它输出建议列表，使应用程序更安全且具有复原能力。
最佳做法：使用机密扫描来检测意外提交的机密
为存储库启用 机密扫描 时，GitHub 会扫描代码中是否存在与许多服务提供商使用的机密匹配的模式。
GitHub 定期对存储库中的现有内容运行完整的 git 历史记录扫描，并发送警报通知。
对于 Azure DevOps，Defender for Cloud 使用机密扫描来检测源代码中的凭据、机密、证书和其他敏感内容，并生成输出。
可以在 Microsoft 安全 DevOps 的 Azure DevOps 扩展中运行机密扫描。
最佳做法：使用 SCA 工具跟踪代码库中的开源组件并检测依赖项中的漏洞
依赖项评审 允许在将依赖项引入环境之前捕获不安全的依赖项。 它还提供有关许可证、依赖关系，以及依赖关系存在时间的信息。 它在拉取请求的文件更改选项卡上，通过详细差异显示依赖项更改。
Dependabot 执行扫描以检测不安全的依赖项，并在将新的公告添加到 GitHub 顾问数据库或存储库依赖项关系图更改时发送 Dependabot 警报。
最佳做法：为容器映像生成 SBOM
软件材料清单（SBOM）提供构成容器映像的组件、库和依赖项的完整清单。 在 CI 生成期间使用 sBOM 生成工具（如 Microsoft sbom-tool 或 Syft ）生成 SPDX 或 CycloneDX 清单。
将 SBOM 附加到容器 注册表 中存储的容器映像，以在整个供应链中启用下游漏洞扫描和许可证符合性跟踪。
最佳做法：扫描 IaC 模板以检测部署前的错误配置
在整个开发生命周期内主动监视云资源配置。
Microsoft Defender for DevOps 同时支持 GitHub 和 Azure DevOps 存储库，并且可以扫描 IaC 模板以识别 IaC 漏洞。
最佳做法：扫描容器注册表中的工作负荷映像以识别已知漏洞
Defender for Containers 扫描容器注册表和 Amazon ECR 中的容器，以通知您镜像中的已知漏洞。
可以让 Azure Policy 对容器注册表中存储的映像执行漏洞评估，并提供有关每个发现的详细信息。
最佳做法：在基础映像更新上自动生成新映像
- 容器注册表任务 在生成容器映像时动态发现基础映像依赖项。 当它检测到对应用程序映像的基础映像的更新时，可以配置生成任务以自动重新生成引用该基础映像的应用程序映像。
最佳做法：使用容器注册表、Key Vault 和表示法对容器映像进行数字签名，并将 AKS 群集配置为仅允许验证的映像
Key Vault 存储 表示法 工具使用的签名密钥。 Key Vault 插件（azure-kv）访问这些密钥来对容器映像和其他制品进行签名及验证。 可以使用 Azure CLI 命令将这些签名附加到容器注册表映像。
签名的容器确保部署过程来自受信任的源，并且工件在创建后不会被篡改。 签名的项目可确保在用户将项目拉入任何环境之前的完整性和真实性，这有助于避免攻击。
部署阶段
在部署阶段，开发人员、应用程序操作员和群集操作员团队协同工作，为 CD 管道建立适当的安全控制。 这些控件有助于以安全且自动化的方式将代码部署到生产环境。
最佳做法：控制部署管道的访问和工作流
可以通过设置分支保护规则 来保护 重要分支。 这些规则定义协作者是否可以删除或强制推送到分支。 他们还设置了推送到分支的要求，例如状态检查必须通过，或者使用线性提交历史记录。
使用 环境 进行部署以配置保护规则和机密。
最佳做法：保护部署凭据
OpenID Connect（OIDC） 允许 GitHub Action 工作流访问 Azure 中的资源，而无需将 Azure 凭据存储为长期存在的 GitHub 机密。
使用拉取策略将 CI/CD 与 GitOps 配合使用，将安全凭据转移至 Kubernetes 集群中。 此方法通过从外部 CI 工具中删除凭据来降低安全性和风险面。 还可以减少允许的入站连接，并限制对 Kubernetes 群集的管理级访问。
最佳做法：运行 DAST 以查找正在运行的应用程序中的漏洞
最佳做法：仅从受信任的注册表部署容器映像
使用 Defender for Containers 为 Kubernetes 启用 Azure Policy 加载项。
配置适用于 Kubernetes 的 Azure Policy，以将容器映像部署限制为受信任的注册表。
运行阶段
在此阶段，执行操作监视和安全监视任务，主动监视、分析和警报潜在安全事件。 使用 Azure Monitor 和 Microsoft Sentinel 等生产可观测性工具监视并确保符合企业安全标准。
最佳做法：使用 Defender for Cloud 自动扫描和监视生产配置
运行持续扫描以检测应用程序漏洞状态的偏移，并实现修补和替换易受攻击映像的过程。
为操作系统实现自动化配置监控。
使用 Defender for Cloud 中的容器建议（在 计算和应用下）为 AKS 群集执行基线扫描。 Defender for Cloud 在其仪表板中显示任何配置问题或漏洞。
使用 Defender for Cloud 并遵循其网络保护建议来帮助 保护 AKS 群集的网络资源。
对容器注册表中存储的映像执行漏洞评估。
- 通过启用Defender for Containers，为容器注册表中的运行映像实现连续扫描。
最佳做法：使 Kubernetes 群集保持更新
Kubernetes 经常发布新版本。 维护生命周期管理策略，以确保您的群集得到支持并保持更新。 AKS 提供用于管理群集升级的工具。 使用 AKS 计划内维护功能来控制维护时段和升级的时间。
升级 AKS 工作器节点频繁。 Azure 每周发布 OS 和运行时更新。 通过无人参与模式自动应用这些更新，或通过 Azure CLI 手动应用这些更新以获得更多控制。
最佳做法：使用 Azure Policy 保护和管理 AKS 群集
为 AKS 安装 Azure Policy 加载项后，可以将单个策略定义或策略定义组（称为计划或策略集）应用到群集。
对常见方案（例如阻止特权容器运行或将外部 IP 地址限制为允许列表）使用 内置 Azure 策略 。 还可以针对特定用例创建自定义策略。
将策略定义应用到群集，并验证 Azure Policy 是否强制实施这些分配。
使用 Gatekeeper 配置一个准入控制器，该控制器根据指定规则允许或拒绝部署。 Azure Policy扩展了 Gatekeeper。
在 AKS 中使用网络策略保护工作负荷 Pod 之间的流量。
- 使用 由 Cilium 提供支持的 Azure CNI 作为网络策略引擎。 Cilium 使用基于 eBPF 的数据平面，并支持 Kubernetes 原生策略、第 7 层策略和 FQDN 过滤。
最佳做法：使用 Azure Monitor 进行持续监视和警报
使用 Azure Monitor 从 AKS 收集日志和指标。 通过 Azure Monitor 托管服务收集 Prometheus 指标、 Log Analytics 中的查询容器和平台日志，并通过 Azure 托管 Grafana 仪表板可视化群集运行状况。
Azure Monitor 将持续监视扩展到发布管道。 使用监视数据批准或回滚发布。 Azure Monitor 还会引入有关可疑活动的安全日志和警报。
将 AKS 实例加入 Azure Monitor 并为群集配置诊断设置。
有关详细信息，请参阅 AKS 的 Azure 安全基线。
最佳做法：使用 Defender for Cloud 进行主动威胁监视
Defender for Cloud 为节点级别（VM 威胁）和群集工作负载的 AKS 提供主动威胁监视。
使用 Defender for DevOps 获得对所有 CI/CD 管道的全面可见性。 它为安全和操作员团队提供集中式仪表板。 当你使用多管道平台（如 Azure DevOps 和 GitHub）或跨公有云运行管道时，尤其受益于这种集中可见性。
Defender for Key Vault 检测到访问密钥保管库帐户的异常和可疑尝试，并且可以根据配置向管理员发送警报。
Defender for Containers 可以针对容器注册表中存储的容器映像中发现的漏洞发出警报。
最佳做法：启用集中式日志监视并使用 SIEM 产品监视实时安全威胁
- 将 AKS 诊断日志连接到 Microsoft Sentinel，以便基于模式和规则集中进行安全监视。 Microsoft Sentinel 允许通过 数据连接器进行此访问。
最佳做法：启用审核日志记录以监视生产群集上的活动
使用活动日志监视 AKS 资源上的操作，以查看所有活动及其状态。 确定谁对资源执行了哪些操作。
通过在 CoreDNS 自定义 ConfigMap 中应用文档化的配置来启用 域名系统（DNS）查询日志记录。
监视访问已停用凭据的尝试。
将 AKS 的用户身份验证与 Microsoft Entra ID 集成。 为 Microsoft Entra ID 创建诊断设置，并将 审核日志和登录日志发送到 Log Analytics 工作区。 在 Log Analytics 工作区中，为安全事件配置警报，例如已停用帐户的登录尝试。
最佳做法：对 Azure 资源启用诊断
- 在所有工作负荷的资源中启用 Azure 诊断，以访问提供详细诊断和审核信息的平台日志。 可以将这些日志引入 Log Analytics 或 SIEM 解决方案，例如 Microsoft Sentinel，以便进行安全监视和警报。
供稿人
Microsoft维护本文。 以下贡献者撰写了本文。
主要作者：
- Adnan Khan |云解决方案架构师
其他参与者：
- Ayobami Ayodeji |项目经理 2
- 艾哈迈德·巴姆 |云解决方案架构师
- 查德·基特尔 |首席软件工程师 - Azure 模式和做法
- John Poole |云解决方案架构师
- Bahram Rushenas |高级解决方案架构师
- Abed Sau |云解决方案架构师
若要查看非公开的LinkedIn个人资料，请登录LinkedIn。