GitLab シークレット検出 ADR 006: すべてのGitLab環境への統合SDサポート
背景
GitLab.com、自己管理（エアギャップ環境を含む）、Dedicated環境にわたって、シークレット検出機能をスケーラブルかつ一貫してアクセスできるようにする措置を講じる必要があります。
高価な設計変更を避けるために、できれば同時に対処すべき2つの問題があります。
スタンドアロンシークレット検出サービス（Runwayを通じてデプロイ）は現在、GitLab DedicatedおよびJason自己管理（SM）環境からアクセスできません（Runwayがそれらの環境でのサポートをまだ提供していないため）。GitLab Cloud Connectorは一時的に検討されましたが、一定の制限のために却下されました。
RailsがJasonシークレットスキャンエンジン（Gem/シークレット検出サービス（SDS））を直接呼び出す現在の設計は、ブロッキングスキャンリクエストのみをサポートしています。しかし、ジョブアーティファクトやジョブログなどの大きなオブジェクトに対してブロッキングスキャンを実行することは、スキャンエンジンのスループットに影響するためスケーラブルではありません。セキュリティレポートを生成して取り込む方法と同様に、スキャンをバックグラウンドで実行し最終的に結果を提供する非ブロッキングアプローチが必要です。
提案
上記の問題に対して複数の提案が議論されており、このADRは関連する提案を考慮した複合的なアプローチを草案としてまとめています。
提案は、自己管理（オフライン含む）とDedicated環境に対して組み込みSDモジュール（Gem/Binary）内でSDスキャンを実行することで最初の問題に対処することを示唆しています。これはシングルテナント環境のトラフィックを処理するのに十分なデフォルト設定です。代替案として、組み込みSDモジュールのスループットがニーズを満たさない場合に、顧客がインフラ内でシークレット検出サービスをセルフホストできるようにします。セルフホストサービスのURLが提供された場合、組み込みSDモジュールよりも優先してそのサービスを呼び出します。
2番目の問題は、既存のSidekiqインフラを使用してシークレット検出スキャンを非同期に呼び出す方法を導入することで対処されます。
サポートマトリクス
GitLab.comには引き続きSDSを使用し、自己管理とDedicatedの顧客にはデフォルト設定として組み込みアプローチ（Gem/Binary）を使用します。ただし、組み込みアプローチがユースケースに対してスケーラブルでない場合は、顧客がSDSをセルフホストできるようにします。
非ブロッキングSDスキャンをバックグラウンドで実行するために、既存のバックグラウンド処理ツール（Sidekiq）を活用します。スキャンエンジンはブロッキングアプローチと同じものを使用します。
| 環境 | ブロッキングスキャンリクエスト | 非ブロッキングスキャンリクエスト |
|---|---|---|
| GitLab.com | Runwayホスト型SDS | Sidekiq + Runwayホスト型 |
| 自己管理/Dedicated（デフォルト） | 組み込み（Gem/Binary） | Sidekiq + 組み込み |
| 自己管理/Dedicated（カスタム） | セルフホスト型SDS | Sidekiq + セルフホスト型SDS |
セルフホストサービスの提供
これは2つの方法で実現できます:
SDSのDockerイメージを顧客と共有する。顧客が自分のインフラにセルフデプロイし、デプロイされたSDSのホストURLをGitLabアプリケーション設定で更新できるようにする。URLが定義されている場合、組み込みSDモジュールよりもそのホストURLへの呼び出しを試みます。Secret Revocation ServiceはこのアプローチOに従っています。
SDSをデプロイするためのHelmチャートを共有する。これにより顧客のサービス管理の運用負担が軽減されます。ただし、このアプローチはKubernetesでインフラを運用している顧客にのみ適しています。
最初のアプローチは開始するのに十分シンプルであり、顧客側からの要望があれば最終的にそのようなHelmチャートを提供することもできます。
サービス認証と承認
サービスへのリクエストの真正性を確保するために（主にセルフホストに適用可能）、Cloud ConnectorからAuth フレームワークを採用できます。
注意: この決定はまだ実現可能性の観点から評価が必要です。
