Azure 容器注册表的持续修补功能可自动检测和修正容器映像中的作系统（OS）级别漏洞。 通过计划 使用 Trivy 进行定期扫描并使用 Copa 应用安全修补程序，可以在注册表中维护安全、up-to日期映像，而无需访问源代码或生成管道。 可自由地自定义时间表和目标镜像，以保持 Azure 容器注册表（ACR）环境的安全和合规性
用例
下面是使用连续修补的一些场景：
- 强制实施容器安全性和卫生性： 持续修补使用户能够快速修复 OS 容器 CVE（常见漏洞和暴露），而无需完全从上游重新生成。
- 使用速度： 持续补丁通过自动更新包来消除对特定镜像的上游更新的依赖。 漏洞每天都会出现，而热门映像发布者每月只能提供一次新版本。 通过持续修补，可以确保在检测到最新的 OS 漏洞集后立即修补注册表中的容器映像。
定价
持续修补在基于消耗的模型下运行。 每个补丁利用计算资源，按默认的ACR任务定价标准，以0.000508元/秒的运行时间计算费用。 有关详细信息，请参阅 ACR 定价页。
预览版限制
持续修补目前正在以公共预览形式提供。 以下限制适用：
- 不支持基于 Windows 的容器映像。
- 只会修补源自系统包的“OS 级别”漏洞。 这包括 OS 包管理器管理的容器映像中的系统包，例如“apt”和“yum”。 源自应用程序包的漏洞，例如 Go、Python 和 NodeJS 等编程语言使用的包中的漏洞，无法被修补。
- 持续修补不支持终止服务生命周期（EOSL）映像。 EOSL 映像是指基础操作系统不再提供更新、安全修补程序和技术支持的映像。 示例包括基于旧操作系统版本（如 Debian 8 和 Fedora 28）的映像。 尽管存在漏洞，但 EOSL 映像被跳过补丁程序。建议的方法是将您映像的底层操作系统升级到受支持的版本。
- 不支持多拱形图像。
- 对持续补丁强制实施 100 个映像限制
- 连续修补与已启用 ABAC（基于属性的访问控制）的注册表不兼容，与启用了 PTC（拉取缓存）规则的存储库也不兼容。
- 不支持使用 免费额度的 “试用”上的 Azure 订阅，因为试用帐户缺少 ACR 任务访问权限。
关键概念
由于 ACR 中的连续修补会为每个修补程序创建新的映像，因此 ACR 依赖于标记约定来对已修补的映像进行版本化和标识。 这两种主要方法是增量和浮动方法。
增量标记
工作原理：
每个新修补程序都会在原始标记上递增数字后缀（例如 -1， -2等）。 例如，如果基础映像为 python:3.11，第一个补丁会创建 python:3.11-1，而在同一基础标记上的第二个补丁会创建 python:3.11-2。
特殊后缀规则：
-
-1to-999：这些被视为补丁标记。 -
-x其中x > 999：这些并不是被解释为修补程序标记，而是整个后缀被视为原始标记的一部分。 （示例：ubuntu:jammy-20240530被视为原始标记，而不是修补的标记。这意味着，如果意外地将结束-1的新标记推送到-999某个位置，则连续修补会将其视为已修补的映像。 建议避免将想要修补的-1标记推送到-999。 如果-999已修补映像的版本被命中，则连续修补将返回错误。
浮动标记
工作原理：
单个可变标记 -patched将始终引用映像的最新修补版本。 例如，如果基本映像标记为 python:3.11，则第一个修补程序创建 python:3.11-patched。 每次后续修补时，标记 -patched 都会自动更新为指向最新修补的版本。
我应使用哪项？
增量（默认）：非常适合需要审计和回滚的环境，因为每个新修补程序都有明确标识的唯一标签。
浮动：如果希望将单个指针指向 CI/CD 管道的最新修补程序，则理想。 通过删除每个修补程序在下游应用程序中更新引用的需求，从而降低复杂性，但会牺牲严格的版本控制，从而难以回滚。