Cells: パーソナルアクセストークン
このドキュメントは作業中であり、Cells 設計の非常に初期の状態を表しています。重要な側面は未だ文書化されていませんが、将来的に追加する予定です。これは Cells のアーキテクチャの一候補であり、実装するアプローチを決定する前に代替案と比較検討するつもりです。このアーキテクチャを採用しないと決定した場合でも、そのドキュメントを保持し、このアプローチを選択しなかった理由を記録します。
1. 定義
ユーザーに関連付けられたパーソナルアクセストークン（PAT）は、ユーザーが GitLab の API と対話して操作を実行するための手段です。 PAT は現在ユーザーにスコープされており、ユーザーがアクセスできるすべてのグループにアクセスできます。
2. データフロー
3. 提案
以下の Issue / マージリクエストでさまざまなアプローチが議論されています:
3.1. Organization スコープの PAT
メリット:
- Rails アプリケーションから完全に管理できます。
- セキュリティの向上。PAT は Organization のみに制限されます。
- 特定の Cell への API リクエストは PAT に基づいてルーティングできます。
デメリット:
- 異なる Organization には異なる PAT が必要です。
- 異なる Organization にまたがる複数のプロジェクトを含む自動化では、動作させるために複数の PAT（Organization ごとに 1 つ）が必要です。
- PAT が特定のプロジェクト/Namespace に適用されるかどうかを一目で確認できません。
3.2. ルーティング
Topology Service はトークンを要求して、所有する Cell へのリクエストのルーティングを容易にします。 ただし、この機能は Cells 1.5 でのみ利用可能になる予定です。
Cells 1.0 で Topology Service チームへの追加要件を課さないために、ルーティングにはトークンプレフィックスを使用します。
このプレフィックスは所有する Cell に関連付けられ、個々のトークンを要求することなく Topology Service 経由でルーティングを機能させます。
ただし、このアプローチは gitlab-rails を担当するチームと SRE の作業量を増加させます。
プレフィックスを追加する必要があるトークンは以下の通りです:
- パーソナルアクセストークン（その派生形: なりすましトークン、プロジェクトアクセストークン、グループアクセストークンを含む）
- OAuth アクセストークンとリフレッシュトークン
- RSS / カレンダーフィードトークン
- 受信メールトークン
- Runner トークン
- CI ジョブトークン
- パイプライントリガートークン
- デプロイトークン
4. 検討した代替アプローチ
4.1. クラスター全体の PAT
メリット:
- ユーザーは PAT が適用されるスコープを気にする必要がありません。
デメリット:
- ユーザーは PAT の広範なスコープ（例: 個人アイテムと業務アイテムの分離）を気にする必要があります。
- Organization は PAT のスコープを自分の Organization のみに制限できません。
- 複雑性が増します。すべてのクラスター全体のデータは、おそらく別の データアクセス層 に移動されます。
4.2. オプションの Organization スコープ付きクラスター全体の PAT
これはオプション 3.1 と 4.1 の組み合わせで、PAT はクラスター全体で作成されますが、オプションで Organization にスコープできます。 初期開発では、クラスター全体の PAT をサポートし（スケーラビリティの課題への対応を含む）、最終的に Organization をトークンスコープとして追加すること（API や読み取り/書き込みスコープと同様に）を意味します。
メリット:
- ユーザー（または管理者）が PAT スコープを制御できる柔軟かつ安全な方法です。
デメリット:
- クラスター全体のデータにアクセス、共有、更新する際のスケーラビリティの 課題 発見リスクがあります。
