DevSecOps（也称为安全 DevOps）通过在传统 DevOps 生命周期的不同阶段整合安全性，扩充了 DevOps 做法。 在 DevOps 做法中生成安全性的一些好处包括：
- 通过提供对安全威胁的可见性并防止漏洞影响已部署环境，提高应用程序和系统的安全性
- 提高开发和操作团队的安全意识
- 将自动化安全流程整合到软件开发生命周期
- 通过在开发和设计阶段及早发现安全问题来降低修复成本
当 DevSecOps 应用于 Azure Kubernetes 服务 (AKS) 时，不同的组织角色对于安全性的实现具有不同的注意事项。 这些不同的组织角色示例如下：
- 生成 AKS 上运行的安全应用程序的开发人员
- 生成安全的 AKS 基础结构的云工程师
- 可能管理群集或监视安全问题的各种操作团队
本文分为不同的 DevOps 生命周期阶段，其中包含有关嵌入安全控制和安全最佳做法的注意事项和建议。 本指南包括可整合到持续集成和持续交付 (CI/CD) 管道的常用流程和工具，并选择易于使用的内置工具（如果可用）。
建议查看使用 DevOps 和 GitOps 在 AKS 上生成和部署应用，这是本文的先决条件。
处理流程
下载此体系结构的 Visio 文件。
注意
尽管本文引用 AKS 和 GitHub，但这些建议适用于任何容器业务流程或 CI/CD 平台。 尽管实现详细信息可能有所不同，但每个阶段中提到的大多数概念和做法仍然相关且适用。
- Microsoft Entra ID 配置为 GitHub 的标识提供者。 配置多重身份验证 (MFA)，提升身份验证安全性。
- 开发人员使用启用了安全扩展的 Visual Studio Code 或 Visual Studio 主动分析其代码是否存在安全漏洞。
- 开发人员将应用程序代码提交到公司拥有和管理的 GitHub Enterprise 存储库。
- GitHub Enterprise 通过 GitHub Advanced Security 集成自动安全性和依赖项扫描。
- 拉取请求通过 GitHub Actions 触发持续集成 (CI) 生成和自动测试。
- 通过 GitHub Actions 的 CI 生成工作流生成存储到 Azure 容器注册表的 Docker 容器映像。
- 你可以为部署到特定环境（如生产环境）引入手动审批，作为 GitHub Actions 中持续交付 (CD) 工作流的一部分。
- GitHub Actions 在 AKS 中启用 CD。 使用 GitHub Advanced Security 检测应用程序源和配置文件中的机密、凭据和其他敏感信息。
- Microsoft Defender 用于扫描 Azure 容器注册表、AKS 群集和 Azure Key Vault 是否存在安全漏洞。
- Microsoft Defender for Containers 在将容器映像上传到容器注册表时扫描其是否存在已知的安全漏洞。
- 你还可以使用 Defender for Containers 来执行 AKS 环境扫描，并为 AKS 群集提供运行时威胁防护。
- 适用于 Key Vault 的 Microsoft Defender 可检测有害的、异常的、可疑的针对密钥保管库帐户的访问尝试。
- Azure Policy 可应用于容器注册表和 Azure Kubernetes 服务 (AKS)，以实现策略合规性和实施策略。 容器注册表和 AKS 的常见安全策略是内置的，以便快速启用。
- Azure Key Vault 用于在运行时将机密和凭据安全地注入应用程序，从而将敏感信息与开发人员隔离开。
- AKS 网络策略引擎配置为使用 Kubernetes 网络策略保护应用程序 pod 之间的流量。
- 可以使用 Azure Monitor 和容器见解设置对 AKS 群集的持续监视，以引入性能指标并分析应用程序和安全日志。
- 容器见解检索性能指标以及应用程序和群集日志。
- 将诊断和应用程序日志拉取到 Azure Log Analytics 工作区，以运行日志查询。
- Microsoft Sentinel 是一种安全信息和事件管理 (SIEM) 解决方案，可用于根据定义的模式和规则引入和进一步分析 AKS 群集日志，以查明是否存在任何安全威胁。
- Zed Attack Proxy (ZAP) (ZAP) 等开源工具可用于对 Web 应用程序和服务执行渗透测试。
- 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 战略和左移方法的关键部分。
下载此体系结构的 Visio 文件。
计划阶段
计划阶段通常自动化程度最低，但与安全性密切相关，会显著影响后续的 DevOps 生命周期阶段。 此阶段涉及安全、开发和操作团队之间的协作。 在设计和规划阶段纳入安全利益干系人可确保安全需求和安全问题得到适当的考虑或缓解。
最佳做法 - 设计更安全的应用程序平台
若要确保系统中从平台本身开始的每一层都具有安全性，请务必生成更安全的 AKS 托管平台。 该平台可以包括群集内部的组件（例如运行时安全和策略代理）和 AKS 外部的组件（例如网络防火墙和容器注册表）。 有关详细信息，请参阅 AKS 登陆区域加速器，其中包括安全、标识和网络拓扑等关键设计领域。
最佳做法 - 将威胁建模生成到流程中
- 威胁建模通常是涉及安全和开发团队的手动活动。 它用于建模和查找系统威胁，以确保在进行任何代码开发或系统更改之前解决漏洞。 威胁建模可能由重大软件更改、解决方案体系结构更改或安全事件等事件触发，在各种时间发生。
- 我们建议你使用 STRIDE 威胁模型。 此方法先使用数据流图，然后使用 STRIDE 助记键（欺骗、篡改、信息泄露、否认、拒绝服务和特权提升）威胁类别来授权团队识别、缓解和验证风险。 它还包含一个建模工具，用于标记和可视化系统组件、数据流和安全边界。 将威胁建模生成到 SDLC 流程中引入了新的流程和更多工作方法来维护更新的威胁模型。 但这有助于确保尽早实现安全性，从而降低处理后续 SDLC 阶段中的安全问题所产生的潜在成本。
最佳做法 - 应用 Azure Well Architected Framework (WAF)
- 应用适用于云原生环境的 WAF 安全核心最佳做法，为标识管理、应用程序安全、基础结构保护、数据安全和 DevOps 等内容提供指导。
- 应用适用于 DevSecOps 和生产环境监视的 WAF 操作最佳做法。
开发阶段
“左移”是 DevSecOps 思维的一个关键租户。 在将代码提交到存储库并通过管道进行部署之前，此过程就已经开始了。 在开发阶段采用安全编码最佳做法并使用 IDE 工具和插件进行代码分析有助于在开发生命周期内提早解决安全问题，在该生命周期内安全问题更容易修复。
最佳做法 - 强制实施安全编码标准
- 通过使用既定的安全编码最佳做法和清单，可以保护代码免受注入和危险设计等常见漏洞的伤害。 OWASP 基金会发布了编写代码时应采用的行业标准安全编码建议。 开发面向公众的 Web 应用或服务时，这些指南尤为重要。
- 除了一般的安全最佳做法，你还应查看针对特定编程语言运行时（例如 Java 和 .NET）的安全编码做法。
- 可以强制执行日志记录标准，以防敏感信息泄露到应用程序日志中。 log4j 和 log4net 等大多数常用的记录框架提供了筛选器和插件来对帐号或个人数据等敏感信息进行掩码操作。
最佳做法 - 使用 IDE 工具和插件自动执行安全检查
大多数常用的 IDE（如 Visual Studio、Visual Studio Code、IntelliJ IDEA 和 Eclipse）都支持扩展，你可以使用这些扩展来获取关于编写应用程序代码时可能引入的潜在安全问题的即时反馈和建议。
- SonarLint 是一个适用于大多数常用语言和开发人员环境的 IDE 插件。 SonarLint 提供有价值的反馈并自动扫描代码，以查找常见的编程错误和潜在的安全问题。
- 其他免费和商业插件专注于安全相关项，例如 OWASP 十大常见漏洞。 例如，Synk 插件还会扫描应用程序源和第三方依赖项，并在发现任何漏洞时发出警报。
- 使用适用于 Visual Studio 和 Visual Studio Code 的静态分析结果交换格式 (SARIF) 插件可以轻松地从常用的静态应用程序安全测试 (SAST) 工具中以直观且易于阅读的方式（而不是通过解释原始 JSON 输出文件的结果）查看漏洞。
最佳做法 - 建立对源代码存储库的控制
- 建立分支方法，以便在整个企业中一致地使用分支。 发布流和 GitHub 流等方法针对如何使用分支来支持团队和实现并行开发提供了结构化指南。 这些方法可以帮助团队针对将代码提交和合并到 CI/CD 工作流中建立标准和控制。
- 某些分支（例如主分支）是持久性分支，可保护应用程序源代码的完整性。 这些分支应具有既定的合并策略，更改才能合并或提交到这些分支。 一些最佳做法包括：
- 防止其他开发人员将代码直接提交到主分支。
- 建立同级评审流程，并规定获得最低数量的批准后才能将更改合并到主分支。 你可以使用 GitHub 轻松配置和实施这些控制。 如果封闭环境需要，还可以使用 GitHub 指定授权审批者组。
- 使用预提交挂钩检查应用程序源代码中是否存在敏感信息，并在发现安全问题时阻止提交。
- 使用 GitHub 提供的、可为特定项目轻松配置的内置预提交挂钩。 例如，预生成的挂钩用于扫描机密、私钥和凭据，并在发现任何问题时阻止提交。
- 在版本控制系统中建立基于角色的访问控制。
- 使用最小特权原则创建明确定义的角色。 CI/CD 管道是用于生产环境部署的供应链。
- 在组织中应用既定的用户或组角色。 必须创建管理员、开发人员、安全管理员和操作员等角色，以根据每个人在 CI/CD 工作流中的特定角色和功能来对其进行分组。
- 启用工作流的审核，以确保 CI/CD 管道的配置和其他更改具有透明度和可追溯性。
最佳做法 - 保护容器映像
- 使用具有最小操作系统占用空间的轻型映像来减少整体面攻击区域。 请考虑只含应用程序及其相关运行时的最小映像，例如 Alpine 或无发行版映像。 Mariner 是 Microsoft 开源 Linux 发行版，是一种轻型强化发行版，专为 AKS 设计以托管容器化工作负载。
- 生成容器时仅使用受信的基础映像。 应从经常扫描是否存在漏洞的专用注册表中检索这些基础映像。
- 使用开发人员工具在本地评估映像漏洞。
- Trivy 是一个开源工具示例，可用于分析容器映像中的安全漏洞。
- 阻止映像的根用户访问权限/上下文。 默认情况下，容器以 root 身份运行。
- 对于需要提高安全性的容器，请考虑在 Kubernetes 群集中使用 AppArmor 配置文件，以增强正在运行的容器的安全性。
生成阶段
在生成阶段，开发人员与站点可靠性工程师和安全团队合作，将应用程序源的自动扫描集成到 CI 生成管道中。 根据配置，这些管道使用 CI/CD 平台的安全工具和扩展来启用 SAST、SCA 和机密扫描等安全做法。
最佳做法 - 执行静态代码分析 (SAST) 以查找应用程序源代码中的潜在漏洞
- 使用 GitHub Advanced Security 扫描功能进行代码扫描和 CodeQL。
- 使用 kube-score 等工具分析 Kubernetes 部署对象。
- kube-score 是一种对 Kubernetes 对象定义进行静态代码分析的工具。
- 输出是一个针对可优化内容的建议列表，以帮助提高应用程序的安全性和复原能力。
最佳做法 - 执行机密扫描以防意外提交到存储库的机密用于欺诈
- 为存储库启用机密扫描后，GitHub 会扫描代码，以查找与许多服务提供商所用机密相匹配的模式。
- GitHub 还定期对存储库中的现有内容运行完整的 git 历史记录扫描，并发送警报通知。
- 对于 Azure DevOps，Defender for Cloud 使用机密扫描来检测源代码和生成输出中的凭据、机密、证书和其他敏感内容。
- 机密扫描可以作为 Microsoft Security DevOps Azure DevOps 扩展的一部分运行。
最佳做法 - 使用软件组成分析 (SCA) 工具跟踪代码库中的开源组件并检测依赖项中的任何漏洞
- 依赖项审查可让你在将有不安全的依赖项引入你的环境之前找到它们，并提供关于许可证、依赖项和依赖项存在时间的信息。 它提供了一个易于理解的依赖项变化视图，多差异显示在拉取请求的“Files Changed（更改的文件）”选项卡上。
- 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 命令附加这些签名。
- 签名的容器使用户能够确保从受信任的实体生成部署，并验证项目自创建以来未被篡改过。 在用户将项目拉取到任何环境之前，签名的项目可确保完整性和真实性并避免攻击。
- Ratify 允许 Kubernetes 群集在部署之前验证项目安全元数据，并且只允许符合你创建的准入策略的人员进行部署。
部署阶段
在部署阶段，开发人员、应用程序操作员和群集操作员团队协同为持续部署 (CD) 管道建立正确的安全控制，从而以更安全和更自动化的方式将代码部署到生产环境。
最佳做法 - 控制部署管道的访问和工作流
- 可以通过设置分支保护规则来保护重要分支。 这些规则定义协作者是否可以删除推送或将推送强制发送到分支。 这些规则还针对发送到分支的所有推送设置了要求，例如传递状态检查或线性提交历史记录。
- 使用环境进行部署时，可以使用保护规则和机密配置环境。
- 你可以利用审批和入口功能来控制部署管道的工作流。 例如，你可能需要获得安全团队或操作团队的手动批准，才能部署到生产环境。
最佳做法 - 保护部署凭据
- OpenID Connect (OIDC) 允许 GitHub Action 工作流访问 Azure 中的资源，且无需将 Azure 凭据存储为长期存在的 GitHub 机密。
- 使用环境进行部署时，可以使用保护规则和机密配置环境。
- 使用 GitOps 的基于拉取的 CI/CD 方法让你可以将安全凭据转移到 Kubernetes 群集，这样，通过避免将凭据存储在外部 CI 工具中，就会减小安全和风险面。 你还可以减少允许的入站连接数，并限制对 Kubernetes 群集的管理员级访问。
最佳做法 - 运行动态应用程序安全测试 (DAST)，以查找正在运行的应用程序中的漏洞
最佳做法 - 仅从受信的注册表部署容器映像
- 使用 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 群集正在使用的网络资源。
- 对容器注册表中存储的映像进行漏洞评估。
- 通过启用 Defender for Containers，对容器注册表中正在运行的映像实现连续扫描。
最佳做法 - 随时更新 Kubernetes 群集
- Kubernetes 的新版本发布频率很频繁。 务必制定生命周期管理策略，确保版本不会落后和失去支持。 AKS 是一种可提供多种工具的托管产品/服务，使用它可以灵活地管理此升级过程。 你可以使用 AKS 平台的计划内维护功能来更好地控制维护时段和升级。
- 应更频繁地升级 AKS 工作器节点。 我们每周提供 OS 和运行时更新，这些更新可以通过无人参与模式或通过 Azure CLI 自动应用，以实现更多控制和全面更新。
最佳做法 - 使用 Azure Policy 保护和管理 AKS 群集
- 安装适用于 AKS 的 Azure Policy 加载项后，可以将单个策略定义或名为“计划”的策略定义组（又名为“策略集”）应用到群集。
- 将内置 Azure 策略用于常见方案，例如阻止特权容器运行或仅批准列入允许列表的外部 IP。 你还可以为特定用例创建自定义策略。
- 将策略定义应用于群集，并验证是否在强制执行这些分配。
- 使用 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-custom ConfigMap 中应用文档化配置来启用 DNS 查询日志记录。
- 监视尝试访问已停用凭据的行为。
- 将 AKS 的用户身份验证与 Microsoft Entra ID 集成。 为 Microsoft Entra ID 创建诊断设置，将审核和登录日志发送到 Azure Log Analytics 工作区。 在 Azure log Analytics 工作区中配置所需的警报（例如，当停用的帐户尝试登录时）。
最佳做法 - 在 Azure 资源上启用诊断
- 通过在所有的工作负载资源中启用 Azure 诊断，可以访问平台日志，这些日志提供了有关 Azure 资源的详细诊断信息和审核信息。 可以将这些日志引入 Log Analytics 或 SIEM 解决方案（如 Microsoft Sentinel），以实现安全监视和报警。
作者
本文由 Microsoft 维护， 它最初是由以下贡献者撰写的。
主要作者：
- Adnan Khan | 高级云解决方案架构师
其他参与者：
- Ayobami Ayodeji | 项目经理 2
- Ahmed Bham | 高级云解决方案架构师
- Chad Kittel | 首席软件工程师
- John Poole | 高级云解决方案架构师
- Bahram Rushenas | 高级解决方案架构师
- Abed Sau | 高级云解决方案架构师