Trivy 与 Azure DevOps 生态集成实战Pipelines Task、AKS ImageCleaner 与 Defender for Containers【免费下载链接】trivyFind vulnerabilities, misconfigurations, secrets, SBOM in containers, Kubernetes, code repositories, clouds and more项目地址: https://gitcode.com/GitHub_Trending/tr/trivy本篇技术指南以 Trivy 在 Azure 生态中的三大官方集成路径为核心Azure DevOps Pipelines 扫描任务、Azure Kubernetes ServiceAKS上的 ImageCleaner 过期镜像清理以及 Microsoft Defender for Containers 的 CI/CD 镜像扫描。读者读完将掌握如何在 Azure DevOps 流水线中接入 Trivy 安全门禁、如何利用 Trivy 的漏洞分级结果驱动 AKS 集群镜像自动清理以及理解 Defender for Cloud 扫描结果中 Trivy 引擎的角色并顺带掌握 Azure Container RegistryACR私有仓库的直接扫描方法。集成全景Trivy 在 Azure 生态中的三处落点Trivy 对 Azure 的支持横跨 CI/CD、容器编排与云安全运营三个层面官方在 docs/tutorials/integrations/azure-devops.md 中集中介绍了三条路径场景集成对象核心价值构建阶段Azure DevOps Pipelines Task官方在流水线内完成镜像/仓库扫描失败即阻断发布集群运行时AKS ImageCleaner依据 Trivy 扫描结果自动识别并清理过期镜像云安全运营Microsoft Defender for Containers将 Trivy 扫描结果并入 Defender 统一视图在 docs/ecosystem/cicd.md 中官方明确将 Azure DevOps 列为 Trivy 的官方OfficialCI/CD 集成之一Trivy 提供Azure DevOps Pipelines Task可将安全扫描轻松引入工作流并直接集成到 Azure DevOps 的原生界面中。这意味着扫描任务可以像普通流水线步骤一样被调度、查看日志、触发通知无需额外搭建第三方编排。Azure DevOps Pipelines Task在流水线中接入 Trivy 安全扫描官方提供了独立的 Azure DevOps Pipelines Task仓库名aquasecurity/trivy-azure-pipelines-task见 docs/ecosystem/cicd.md。该任务让开发者只需在azure-pipelines.yml中声明一个任务步骤即可对流水线产物执行漏洞、配置错误、密钥与 SBOM 扫描扫描结果直接呈现在 Azure DevOps 的任务界面中。任务的核心工作方式是调用 Trivy CLI 的各个子命令因此所有 Trivy 原生的控制参数都可以透传使用。其中与流水线门禁最相关的是退出码与严重级别两个参数在 docs/guide/references/configuration/cli/trivy_image.md 中有明确定义--exit-code int指定在发现任何安全问题时返回的进程退出码。设为1时发现漏洞即令流水线步骤失败从而阻断包含高危镜像的发布设为0则只报告不阻断docs/tutorials/integrations/index.md 也明确建议当不希望测试失败时指定--exit-code 0。--severity strings以逗号分隔的严重级别白名单可用值包含UNKNOWN、LOW、MEDIUM、HIGH、CRITICAL用于只关注高于某一阈值的风险。一个典型的仅阻断高危及以上的流水线策略可表达为- task: TrivyTask1 # 官方 Trivy Azure DevOps Pipelines Task inputs: scanType: image imageRef: $(registryName)/$(imageName):$(Build.BuildId) exitCode: 1 # 发现安全问题时返回非零退出码使流水线失败 severity: HIGH,CRITICAL # 只对高危与严重级别触发门禁需要说明的是--exit-code的语义是发现安全问题时的退出码配合 CI 系统对非零退出码的失败判定即可实现有问题就停发的自动化门禁。若希望任务在存在问题时仍然放行例如先观察后治理的灰度阶段将退出码设为0即可。此外微软 Azure 团队还维护了一个基于 Trivy 与 Dockle 的container-scan动作见 docs/tutorials/integrations/github-actions.md适用于 GitHub Actions 场景可作为 Azure DevOps Task 在另一 CI 平台上的同类参考实现。AKS ImageCleaner依据 Trivy 分级结果清理过期镜像问题背景流水线构建带来的镜像堆积在 Azure Kubernetes Service 集群上团队通常会使用流水线持续构建并部署镜像。这种方式在高效产出镜像的同时往往忽略了被替换后遗留的过期镜像stale images最终导致集群节点上的镜像不断膨胀。这些未被引用的镜像本身就是安全风险点——它们可能包含漏洞且由于不再被任何工作负载引用很容易脱离团队的补丁与升级视线。人工清理这些镜像费时费力而 ImageCleaner 正是为缓解这一问题而设计它通过自动化的镜像识别与移除持续消除集群中的这部分风险docs/tutorials/integrations/azure-devops.md 将其定位为流水线发布流程的配套治理组件。工作流程Trivy 扫描 → 分级标记 → 自动清理ImageCleaner 的判定逻辑与 Trivy 深度绑定Trivy 扫描定级漏洞判定基于 Trivy 扫描结果凡是被评为LOW、MEDIUM、HIGH或CRITICAL级别的镜像都会被标记为待处理对象ImageList 自动生成ImageCleaner 会按设定的时间间隔自动生成并更新ImageList手动补充除自动生成外ImageList也支持手动提供便于运维人员将自动识别范围之外的镜像纳入清理清单。这套流程的核心含义是ImageCleaner 本身不做漏洞知识库的判断而是消费 Trivy 的输出——即镜像是否有问题完全由 Trivy 的扫描结论决定。因此理解 Trivy 的严重级别体系是正确配置清理策略的前提。严重级别体系Trivy 输出与清理阈值的对应Trivy 内部使用数字编码表示严重级别完整映射见 docs/guide/scanner/vulnerability.md数字编码严重级别说明0UNKNOWN无任何数据源提供严重级别时使用1LOW基础评分 0.1–3.92MEDIUM基础评分 4.0–6.93HIGH基础评分 7.0–8.94CRITICAL基础评分 9.0–10.0值得注意的是Trivy 在选取严重级别时优先信任厂商数据源而非 NVD。以 docs/guide/scanner/vulnerability.md 中 CVE-2023-0464 为例NVD 评级为 HIGH而 Red Hat 标记为 LowTrivy 会展示为 Low。这是因为 OS 厂商通常会做补丁 backport且其评估更贴合实际分发形态。在 Azure 场景中这意味着运行在 Azure LinuxCBL-Mariner上的镜像会依据微软维护的 OVAL 数据源见 docs/guide/scanner/vulnerability.md 数据源表格判定严重级别其结论与 AKS 节点的实际修复状态更一致从而让 ImageCleaner 的清理决策更贴近真实风险。Microsoft Defender for Containers将 Trivy 结果并入云安全视图部署前提在 Azure Container Registry 上启用集成漏洞扫描需要完成两项配置启用 Microsoft Defender for Containers这是扫描能力的承载平面启用 CI/CD 集成当 CI/CD 工作流将镜像推送到注册表时Defender 会对这些镜像执行扫描。启用后用户既可以在注册表面板查看注册表扫描结果registry scan results也可以查看CI/CD 扫描结果汇总summary of CI/CD scan results。引擎分工Trivy 与 Qualys 的互补需要澄清一个常见的误解Defender for Cloud 的 CI/CD 扫描由 Aqua Trivy 驱动原文明确表述为 Defender for Clouds CI/CD scanning is powered by Aqua Trivy而注册表侧的既有扫描结果则来自 Qualys。CI/CD 扫描发现是对现有 Qualys 注册表扫描发现的一种补充增强enrichment——也就是说推送镜像时Trivy 引擎在 CI/CD 环节执行扫描结果进入 CI/CD 扫描视图注册表存量镜像Qualys 持续扫描结果进入注册表扫描视图两个视图汇总后构成对容器资产更完整的风险画像。从工程视角看Trivy 在此处扮演的是构建期防线角色它把安全检测前移到镜像被推入注册表的那一刻与 ImageCleaner 的运行期清理形成前后衔接——前者阻止带病镜像进入后者移除已滞留的带病镜像。延伸实战直接扫描 Azure Container Registry 私有仓库在配置 Azure DevOps Task 或 Defender 之前团队常需要先在本地直接验证 ACR 中的镜像。Trivy 对 ACR 提供了开箱即用的支持docs/guide/advanced/private-registries/acr.md 中明确了以下几点无额外依赖Trivy 通过 Azure SDK for Go 完成认证不需要安装az命令行工具权限要求服务主体Service Principal必须具备AcrPull权限认证方式通过三个标准环境变量注入 Azure 凭据# 创建带 AcrPull 角色的服务主体需 az CLI仅创建阶段使用 export SP_DATA$(az ad sp create-for-rbac \ --name TrivyTest \ --role AcrPull \ --scope /subscriptions/subscription_id/resourceGroups/resource_group/providers/Microsoft.ContainerRegistry/registries/registry_name) # 从返回结果中提取凭据Trivy 运行时只读取环境变量不再依赖 az export AZURE_CLIENT_ID$(echo $SP_DATA | jq -r .appId) export AZURE_CLIENT_SECRET$(echo $SP_DATA | jq -r .password) export AZURE_TENANT_ID$(echo $SP_DATA | jq -r .tenant)随后即可直接扫描 ACR 镜像注意TRIVY_USERNAME需置为空字符串避免与 Azure 认证冲突docker run -it --rm -v /tmp:/tmp \ -e AZURE_CLIENT_ID -e AZURE_CLIENT_SECRET -e AZURE_TENANT_ID \ aquasec/trivy image your_special_project.azurecr.io/your_special_image:your_special_tag在 Docker 方式下环境变量通过-e透传进容器若在宿主上直接运行二进制则使用export导出后调用trivy image 镜像地址即可。这一能力让 Azure DevOps Task、本地调试与自定义脚本共享同一套认证模型减少配置碎片。总结与实施建议综合三条集成路径一个完整的 Azure 容器安全闭环可以这样组织构建期在 Azure DevOps Pipelines 中接入官方 Trivy Task使用--exit-code 1与--severity HIGH,CRITICAL建立门禁阻止高危镜像发布入库期启用 Defender for Containers 的 CI/CD 集成让 Trivy 扫描结果在 Defender 统一视图中与 Qualys 注册表扫描互补呈现运行期在 AKS 上启用 ImageCleaner让其按时间间隔自动生成 ImageList清理被 Trivy 标记为 LOW 及以上级别的过期镜像必要时手动补充清单。三者共享同一套 Trivy 严重级别语义UNKNOWN/LOW/MEDIUM/HIGH/CRITICAL因此团队只需在一处建立风险口径即可在整个 Azure 生命周期内保持一致。进一步的信息可查阅 docs/ecosystem/cicd.mdCI/CD 集成全景、docs/guide/scanner/vulnerability.md漏洞扫描与严重级别机制与 docs/guide/advanced/private-registries/acr.mdACR 私有仓库扫描。【免费下载链接】trivyFind vulnerabilities, misconfigurations, secrets, SBOM in containers, Kubernetes, code repositories, clouds and more项目地址: https://gitcode.com/GitHub_Trending/tr/trivy创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考