GitLab の新しい Auth スタック

サマリー

GitLab の認証・認可コードはこれまで 10 年以上にわたって有機的に進化してきました。認証・認可メカニズムのほとんどは GitLab Rails モノリスの中に存在しており、毎日何百人ものソフトウェアエンジニアがプロジェクトにコントリビュートしています。その結果、コードの複雑さが増大しています:

1. 認証に使用される 10 種類以上の異なるトークンタイプが存在します。
2. ユーザーセッションを認証する 5 種類以上の異なる方法があります。
3. GitLab を ID プロバイダーとして使用する 3 種類以上の方法があります。
4. 私たちが構築した、密結合で複雑な Declarative Policies 言語を使用しています。
5. 認可ツールが頻繁なパフォーマンス関連インシデントを引き起こしています。
6. チームが独立して独自の認証方法を構築し続けています。

今日 GitLab は多くのお客様にとってミッションクリティカルなコンポーネントであり、インフラへのアクセス許可・拒否のために私たちの認証・認可メカニズムに依存しています。

上記の課題を踏まえ、コアの認証・認可メカニズムを統合・集中化する という単一の包括的な技術戦略に沿った 3 つのコア原則に従い、GitLab Adaptive Trust Environment（GATE） の構築に注力することを決定しました:

1. ゼロトラスト: 決して信頼せず、常に検証する。アクセスは検証されたアイデンティティ、コンテキスト、明示的なポリシーに基づいて付与されます。アプリケーションスタックのすべてのレベルで継続的に信頼を検証します。
2. 最小権限: すべてのトークンと認証済みプリンシパルに対して、タスクを完了するために必要な最短の時間で最小限の必要な権限を付与します。
3. アンビエントセキュリティ: 認証、認可、継続的な検証は常に存在します。ほとんどのエンジニアとお客様はこの複雑さを扱う必要がありません: これは大部分が抽象化され、デフォルトで有効になっています。

GATE をどのように提供するかについてより明確にするために、お客様に価値イノベーションを届けるこの再設計を固定する 3 つの主要機能の構築に注力します:

1. GitLab Workload Identity Federation: Personal Access Token と長命のクレデンシャルへの依存を削減するために構築されます。
2. GitLab CI でのアンビエントクレデンシャル: CI ジョブでのトークン/クレデンシャル/キーの使用の必要性を大幅に削減します。
3. すべての認証済みプリンシパルへのきめ細かいアクセス制御: 機能セット全体のセキュリティポスチャを向上させます。

詳細

アーキテクチャ決定レジスターと詳細については、プライベートプロジェクトの New Auth Stack デザインドキュメント をご覧ください。

Issue とワークストリームを含む GitLab のメイン Epic は GitLab での New Auth Stack の提供 です。

ページのソースコードを見る - ページの編集 - please contribute.