第2章 Clair の概念

次のセクションでは、Clair がどのように機能するかの概念的な概要を示します。

2.1. Clair の実践

Clair の分析は、インデックス作成、マッチング、通知の 3 つの部分に分類されます。

2.1.1. インデックス化

Clair のインデクサーサービスは、マニフェストのインデックス作成を実行します。Clair では、マニフェストはコンテナーイメージの表現です。インデクサーサービスは、Clair がレイヤーのコンテンツを理解するために使用するコンポーネントです。Clair は、重複作業を減らすために、Open Container Initiative (OCI) マニフェストとレイヤーがコンテンツアドレス可能であるという事実を利用しています。

インデックス作成には、コンテナーイメージを表すマニフェストの取得と、その設定要素の計算が含まれます。インデクサーは、イメージ内に存在するパッケージ、イメージが派生したディストリビューション、およびイメージ内で使用されているパッケージリポジトリーを検出しようとします。この情報が計算されると、IndexReport に永続化されます。

IndexReport は Clair のデータベースに保存されます。matcher ノードにフィードして、脆弱性レポートを計算できます。

2.1.1.1. コンテンツアドレス可能性

Clair は、すべてのマニフェストとレイヤーを コンテンツアドレス可能 として処理します。Clair のコンテキストでは、コンテンツアドレス可能とは、特定のマニフェストがインデックス化されると、必要でないかぎり、再度インデックス化されないことを意味します。これは個々のレイヤーでも同じです。

たとえば、レジストリー内で ubuntu:artful をベースレイヤーとして使用するイメージの数を考えてみましょう。開発者がイメージを Ubuntu に基づいて作成する場合は、それがイメージの大部分になる可能性があります。レイヤーとマニフェストをコンテンツアドレス可能として処理するということは、Clair がベースレイヤーを 1 回だけフェッチして分析することを意味します。

場合によっては、Clair がマニフェストのインデックスを再作成する必要があります。たとえば、パッケージスキャナーなどの内部コンポーネントが更新されると、Clair は新しいパッケージスキャナーで分析を実行します。Clair は、コンポーネントが変更され、2 回目は IndexReport が異なる可能性があることを判断するのに十分な情報を持っているため、マニフェストのインデックスを再作成します。

クライアントは、Clair の index_state エンドポイントを追跡して、内部コンポーネントがいつ変更されたかを把握し、その後再インデックスを発行できます。Clair の API 仕様を表示する方法については、Clair API ガイドを参照してください。

2.1.2. マッチング

Clair では、マッチャーノードが提供された IndexReport と脆弱性をマッチングします。

マッチャーは脆弱性のデータベースを最新の状態に維持します。通常、マッチャーは一連のアップデーターを実行し、定期的にデータソースをプローブして新しいコンテンツを探します。新しい脆弱性は、発見されると、データベースに保存されます。

マッチャー API は、頻繁に使用されるように設計されています。クエリーを実行すると、常に最新の VulnerabilityReport が提供されるように設計されています。VulnerabilityReport は、マニフェストのコンテンツと、コンテンツに影響を与える脆弱性の両方をまとめたものです。

2.1.2.1. リモートマッチング

リモートマッチャーはマッチャーと同様に機能しますが、リモートマッチャーは API 呼び出しを使用して、提供された IndexReport の脆弱性データをフェッチします。リモートマッチャーは、特定のソースからデータベースにデータを永続化できない場合に役立ちます。

CRDA リモートマッチャーは、Red Hat Code Ready Dependency Analytics (CRDA) から脆弱性をフェッチします。デフォルトでは、このマッチャーは 1 分あたり 100 リクエストを処理します。レート制限は、API キーリクエストフォーム を送信して専用の API キーをリクエストすることで解除できます。

CRDA リモートマッチングを有効にするには、「Clair の CRDA を有効にする」を参照してください。

2.1.3. 通知

Clair は、新しいセキュリティーデータベースの更新を追跡し、新しい脆弱性または削除された脆弱性がインデックス付きマニフェストに影響を与えるかどうかをユーザーに通知するノーティファイアーサービスを使用します。

ノーティファイアーは、以前にインデックス付けされたマニフェストに影響を与える新しい脆弱性を認識すると、config.yaml ファイルで設定されたメソッドを使用して、新しい変更に関する通知を発行します。返された通知は、変更により発見された最も深刻な脆弱性を表しています。これにより、同じセキュリティーデータベースの更新に対して過剰な通知が作成されるのを回避できます。

ユーザーが通知を受け取ると、マッチャーに対して新しいリクエストを発行して、最新の脆弱性レポートを受け取ります。

通知スキーマは、以下の型を JSON でマーシャリングしたものであす。

// Reason indicates the catalyst for a notification
type Reason string
const (
    Added   Reason = "added"
    Removed Reason = "removed"
    Changed Reason = "changed"
)
type Notification struct {
    ID            uuid.UUID        `json:"id"`
    Manifest      claircore.Digest `json:"manifest"`
    Reason        Reason           `json:"reason"`
    Vulnerability VulnSummary      `json:"vulnerability"`
}
type VulnSummary struct {
    Name           string                  `json:"name"`
    Description    string                  `json:"description"`
    Package        *claircore.Package      `json:"package,omitempty"`
    Distribution   *claircore.Distribution `json:"distribution,omitempty"`
    Repo           *claircore.Repository   `json:"repo,omitempty"`
    Severity       string                  `json:"severity"`
    FixedInVersion string                  `json:"fixed_in_version"`
    Links          string                  `json:"links"`
}

次の方法で通知に登録できます。

  • Webhook 配信
  • AMQP 配信
  • STOMP 配信

ノーティファイアーの設定は、Clair YAML 設定ファイルを介して行われます。

2.1.3.1. Webhook 配信

Webhook 配信のノーティファイアーを設定する場合は、サービスに次の情報を提供します。

ノーティファイアーは、更新されたセキュリティーデータベースが変更され、インデックス付きマニフェストの影響を受けるステータスが変更されたと判断すると、次の JSON 本文を設定済みのターゲットに配信します。

{
  "notifiction_id": {uuid_string},
  "callback": {url_to_notifications}
}

受信すると、サーバーはコールバックフィールドに指定された 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 ノーティファイアーの設定で AMQP 配信に direct: true が指定されている場合、通知は設定された交換に直接配信されます。

direct が設定されている場合、rollup プロパティが設定され、1 回の AMQP で最大数の通知を送信するように、ノーティファイアーに指示することができます。これにより、メッセージのサイズとキューに配信されるメッセージの数のバランスが取れます。

2.1.3.3. ノーティファイアーのテストおよび開発モード

ノーティファイアーには、NOTIFIER_TEST_MODE パラメーターで有効にできるテストおよび開発モードがあります。このパラメーターは、任意の値に設定できます。

NOTIFIER_TEST_MODE パラメーターが設定されている場合、ノーティファイアーは、poll_interval 間隔ごとに、設定された配信機能にフェイクの通知を送信し始めます。これにより、新規または既存のデリバラーを簡単に実装およびテストできます。

ノーティファイアーは、環境変数がクリアされてサービスが再起動されるまで、NOTIFIER_TEST_MODE で実行されます。

2.1.3.4. 通知の削除

通知を削除するには、DELETE API 呼び出しを使用できます。通知 ID を手動で削除すると、ノーティファイアー内のリソースがクリーンアップされます。DELETE API 呼び出しを使用しない場合、ノーティファイアーは、配信された通知をデータベースから消去する前に、所定の時間待機します。