プロンプトとコンテキスト
自社のプラットフォームはOCIレジストリにイメージを保存しており、リリースポリシーの一環としてパイプラインで署名、SBOM、および脆弱性レポートを添付する必要があります。リポジトリとイメージダイジェストを指定すると、添付されたアーティファクトを返し、artifactTypeでフィルタリングし、Referrers APIを持たないレジストリをサポートし、デプロイ前に未検証のイメージをブロックするディスカバリおよび検証サービスを設計してください。特定のクラウドSDKではなく、レジストリプロトコルとサービス境界に焦点を当て、バックエンドまたはプラットフォームエンジニア向けに回答してください。
面接官が評価するポイント
優れた回答では、タグではなくイメージダイジェストを不変のsubjectとして扱います。subjectが関連付けを作成し、artifactTypeが目的を記述し、Referrers APIがOCI Indexを返すことを理解しています。また、レガシーのフォールバックタグ、ページネーション、キャッシュの一貫性、およびアーティファクトの検出と署名の検証が別個の処理であるという事実も網羅しています。「イメージタグを読み取る」または「SBOMがあれば信頼性が証明される」という回答は、セキュリティモデルが不完全であることを示します。
最初に確認すべき明確化の質問
- 入力はタグですか、それともダイジェストですか？タグの場合は、検証前にそれを解決してダイジェストを固定します。
- 404を返すレジストリをサポートする必要がありますか？該当する場合は、OCIフォールバックタグを実装し、同時更新を処理します。
- 結果によってデプロイをゲート（制御）しますか？該当する場合は、信頼境界内で署名、パブリッシャーのID、およびダイジェストを検証します。
- 関連付けリストが1ページを超える可能性はありますか？該当する場合は、不透明な
nextTokenを解釈せずにそのまま渡します。
30秒の回答フレームワーク
「まずタグをダイジェストに解決し、すべての関連付けのsubjectとしてそのダイジェストを使用します。/v2/{name}/referrers/{digest}を呼び出し、アーティファクトタイプによって署名、SBOM、またはレポートをフィルタリングします。古いレジストリからの404は、ダイジェストから派生したフォールバックタグをトリガーします。ディスカバリの後に署名とパブリッシャーの検証が行われ、ポリシーによってデプロイが許可されるかどうかが決定されます。リストAPIはページ分割され、ダイジェストとフィルタを含むキーで短いTTLのキャッシュが適用されます。」
ステップバイステップの詳細解説
OCI 1.1では、マニフェストsubjectを使用して参照先の対象マニフェストを指し、artifactTypeで添付されたアーティファクトを記述します。Referrers APIは、ダイジェスト、メディアタイプ、およびアーティファクトタイプを含む記述子（descriptor）を持つOCI Indexを返します。
GET /v2/{name}/referrers/{subject-digest}?artifactType={type}ダイジェストのない検証リクエストは拒否してください。タグは変更可能なポインタであり、署名検証の主キーにはなり得ません。一度解決して結果のダイジェストを記録し、そのダイジェストをディスカバリ、キャッシュ、およびアドミッション全体に渡します。
APIをサポートするレジストリの場合、空のIndexを含む200レスポンスは、添付されたアーティファクトが存在しないことを意味します。404を返す古い実装の場合、クライアントはsha256:をsha256-に置き換えて形成されたフォールバックタグを読み取ります。クライアントがそのフォールバックタグを維持するため、新しいリファラーを追加することはread-modify-writeの競合になります。ライターには条件付き書き込み、オプティミスティックリトライ、または単一ライターキューが必要です。リーダーはフォールバックを強整合性として扱ってはなりません。
検出された署名、SBOM、およびスキャンレポートを3つの段階で処理します：artifactTypeとポリシーでフィルタリングする、参照先のマニフェストとコンテンツを取得する、署名がターゲットダイジェストをカバーしていること、パブリッシャーが信頼されていること、アーティファクトのステータスが許可されていることを検証する。Microsoftのガイダンスでは、消費前の整合性、真正性、およびブロックを分離しているため、「署名が見つかった」ことは「イメージが信頼されている」ことと同じではありません。
APIはページ分割される場合があります。不透明なnextTokenを保持してそのまま渡し、ページサイズの上限を設定し、レジストリ、リポジトリ、subjectダイジェスト、アーティファクトタイプ、および認証コンテキストをキャッシュキーに含めます。ダイジェストは不変であるため、ディスカバリ結果は短時間キャッシュできますが、失効やステータスの変更には依然として明示的なTTLと再検証ポリシーが必要です。アドミッションパスにおいて、キャッシュはディスカバリを高速化できますが、最終的な検証をスキップしてはなりません。
高品質な回答例
私はダイジェストを唯一のsubject識別子にします。クライアントはタグを解決し、OCI Referrers APIを呼び出し、artifactTypeを使用して署名、SBOM、およびスキャンレポートを分離します。サポートしているレジストリはOCI Indexを返します。古いレジストリからの404は、同時更新のためのリトライを備えたダイジェスト派生フォールバックタグをトリガーします。ディスカバリ単体でデプロイを許可することは決してありません。アドミッションサービスは、署名の対象ダイジェスト、パブリッシャーのID、および信頼ルートを検証し、ポリシーを適用します。エンドポイントは不透明なページネーショントークンをそのまま渡し、ダイジェストとフィルタでキャッシュしますが、すべてのデプロイメントはキャッシュエントリを信頼の決定として扱うのではなく、再検証を行います。
よくある間違い
- 間違い → タグを署名キーとして使用する → 失敗する理由：タグは別の対象を指すように変更される可能性がある → 修正方法：最初にダイジェストを解決して固定する。
- 間違い → すべての404を「添付されたアーティファクトなし」として扱う → 失敗する理由：古いレジストリはReferrersを実装していない可能性がある → 修正方法：仕様のフォールバックタグを読み取る。
- 間違い → 署名が見つかり次第デプロイを許可する → 失敗する理由：パブリッシャーのID、カバレッジ、およびターゲットダイジェストが未検証のままになる → 修正方法：ディスカバリと暗号検証を分離する。
- 間違い →
nextTokenをパースまたは構築する → 失敗する理由：トークンは不透明なサーバーカーソルである → 修正方法：変更せずにそのまま渡し、ページサイズとタイムアウトに上限を設ける。
フォローアップの質問と回答
フォローアップ1：2つのビルドがフォールバックタグを同時に更新した場合、どうしますか？
フォールバックIndexをread-modify-writeトランザクションとして扱います。レジストリの条件付き書き込み、オプティミスティックリトライ、または単一ライターキューを使用します。競合が発生した場合は、最新のIndexを読み取って新しい記述子をマージします。別のビルドの関連付けを上書きしてはなりません。
フォローアップ2：署名は存在しますが、SBOMが古いダイジェストを参照しています。何が起こりますか？
現在のsubjectダイジェストとの一貫性を確認します。署名、SBOM、およびレポートはそれぞれ同じダイジェストを参照している必要があります。古い参照は適用不可としてマークし、アドミッションをブロックします。イメージタグのみを照合するのは安全ではありません。
フォローアップ3：レジストリが数千のリファラーを返します。サービスをどのように保護しますか？
maxResultsに上限を設定し、不透明なトークンをそのまま渡し、ダイジェストとアーティファクトタイプをキーとする短いTTLのキャッシュを使用します。アドミッションパスでは、ポリシーで必要なタイプのみをクエリします。バックグラウンドのインデックス作成で結果をウォームアップできますが、デプロイ時には依然として返されたマニフェストダイジェストと信頼ステータスを検証します。