第 2 章 Clair 概念
以下小节概述了 Clair 的工作原理。
2.1. 实践中的 Clair 复制链接链接已复制到粘贴板!
Clair 分析分为三个不同的部分:索引、匹配和通知。
2.1.1. 索引 复制链接链接已复制到粘贴板!
Clair 的索引器服务负责索引清单。在 Clair 中,清单是容器镜像的表示。indexer 服务是 Clair 用来了解层内容的组件。Clair 利用了开放容器项目(OCI)清单和层已解决,以减少重复工作。
索引涉及使用一个代表容器镜像的清单并计算其一致性部分。索引器会尝试发现镜像中存在哪些软件包、从中派生镜像的发布,以及镜像中使用哪些软件包存储库。计算此信息时,它将保持在 IndexReport
中。
IndexReport
存储在 Clair 的数据库中。它可以被限制为一个 匹配器
节点来计算漏洞报告。
2.1.1.1. 内容地址 复制链接链接已复制到粘贴板!
Clair 将所有清单和层视为 可寻址的内容。在 Clair 中,内容地址意味着,当特定清单被索引时,除非需要它,否则不会再次索引它。这对单个层相同。
例如,考虑 registry 中有多少镜像可能会使用 ubuntu:artful
作为基础层。如果开发人员更喜欢从 Ubuntu 中捆绑其镜像,则可能是大多数镜像。将层和清单视为可寻址的内容意味着 Clair 仅获取并分析基础层。
在某些情况下,Clair 应该重新索引清单。例如,当更新软件包扫描程序等内部组件时,Clair 会使用新的软件包扫描程序执行分析。Clair 有足够的信息来确定组件已更改,并且 IndexReport
可能会与第二个时间不同,因此它重新索引清单。
客户端可以跟踪 Clair 的 index_state
端点,以了解内部组件何时更改,从而可以重新索引问题。请参阅 Clair API 指南以了解如何查看 Clair 的 API 规格。
2.1.2. 匹配 复制链接链接已复制到粘贴板!
使用 Clair 时,匹配器节点负责与提供的 IndexReport
匹配漏洞。
匹配者负责保持漏洞数据库最新。匹配者通常会运行一组更新程序,这些更新程序定期将其数据源探测到新内容。发现新漏洞时,会将其存储在数据库中。
matcher API 设计为经常使用。它设计为在查询时始终提供最新的 VulnerabilityReport
。VulnerabilityReport
总结了清单的内容以及影响内容的所有漏洞。
2.1.2.1. 远程匹配 复制链接链接已复制到粘贴板!
远程匹配程序的行为类似于匹配者,但远程匹配者使用 API 调用来获取提供的 IndexReport
的漏洞数据。当无法将给定源中的数据保留到数据库中时,远程匹配者很有用。
CRDA 远程匹配程序负责从 Red Hat Code Ready Dependency Analytics (CRDA)获取漏洞。默认情况下,这个匹配程序每分钟提供 100 个请求。速率限制可以通过请求专用的 API 密钥来取消,该密钥通过提交 API 密钥请求表单 来完成。
要启用 CRDA 远程匹配,请参阅 "Enabling CRDA for Clair"。
2.1.3. 通知 复制链接链接已复制到粘贴板!
Clair 使用一个通知程序服务来跟踪新的安全数据库更新,并通知用户是否有新的或删除的漏洞是否影响索引的清单。
当 notifier 知道影响之前索引清单的新漏洞时,它使用 config.yaml
文件中配置的方法来提供有关新更改的通知。返回的通知表示因为变化而发现的最严重漏洞。这可避免为同一安全数据库更新创建过量通知。
当用户收到通知时,它会针对匹配者发出一个新的请求,以接收最新的漏洞报告。
通知模式是以下类型的 JSON marshalled 表单:
您可以通过以下机制订阅通知:
- Webhook 交付
- AMQP 交付
- STOMP 交付
配置通知程序是通过 Clair YAML 配置文件完成的。
2.1.3.1. Webhook 交付 复制链接链接已复制到粘贴板!
当您为 webhook 交付配置通知程序时,您可以使用以下信息提供以下信息:
- Webhook 将触发的目标 URL。
-
可以访问通知程序的回调 URL,包括其 API 路径。例如:
http://clair-notifier/notifier/api/v1/notifications
。
当确定了更新的安全数据库已更改时,它会为配置的目标提供以下 JSON 正文:
{ "notifiction_id": {uuid_string}, "callback": {url_to_notifications} }
{
"notifiction_id": {uuid_string},
"callback": {url_to_notifications}
}
在接收时,服务器可以浏览到 callback 字段中提供的 URL。
2.1.3.2. AMQP 交付 复制链接链接已复制到粘贴板!
Clair 通知程序还支持向 AMQP 代理发送通知。通过 AMQP 交付,您可以控制回调是否传送到代理,或者通知是否直接传送到队列。这允许 AMQP 使用者的开发人员确定通知处理的逻辑。
AMQP 交付仅支持 AMQP 0.x 协议(如 RabbitMQ)。如果您需要向 AMQP 1.x 消息队列发布通知(如 ActiveMQ),您可以使用 STOMP 发送。
2.1.3.2.1. AMQP 直接交付 复制链接链接已复制到粘贴板!
如果 Clair notifier 的配置为 AMQP 发送指定 direct: true
,则通知将直接发送到配置的交换。
设置 直接
后,可能会设置 rollup
属性来指示通知程序在单个 AMQP 中发送最大通知数。这在消息大小和发送到队列的消息数量之间提供平衡。
2.1.3.3. 通知程序测试和开发模式 复制链接链接已复制到粘贴板!
notifier 有一个测试和开发模式,可通过 NOTIFIER_TEST_MODE
参数启用。这个参数可以设置为任何值。
当设置了 NOTIFIER_TEST_MODE
参数时,通知程序开始将虚拟通知发送到每个 poll_interval
间隔配置的交付机制。这提供了实现和测试新或现有交付者的简单方法。
在环境变量被清除并重新启动前,通知程序在 NOTIFIER_TEST_MODE
中运行。
2.1.3.4. 删除通知 复制链接链接已复制到粘贴板!
要删除通知,您可以使用 DELETE
API 调用。删除通知 ID,手动清理通知器中的资源。如果不使用 DELETE
API 调用,则通知程序会在从其数据库清除通知前等待预先确定的时间长度。