Artifact Registry ADR 021: 認可

ステータス

提案中

この ADR は認可のみを扱います。つまり、認証済みの呼び出し元が何を実行できるかです。認証（呼び出し元のアイデンティティがどのように確立されるか、トークンがどのように発行および検証されるか）は、ADR-020: Authentication Flow で別途扱います。

コンテキスト

Artifact Registry は、GitLab Rails モノリスとは別のサテライトサービス上で動作します。ADR-020 は、呼び出し元のアイデンティティをどのように確立するかを定めています。クライアントは短命のトークンを提示し、Artifact Registry はそれをローカルで検証し、リクエスト処理中に GitLab インスタンスへコールバックすることはありません。

この ADR は次の問いを扱います。その呼び出し元は何を実行できるのか？

Auth Platform チームとの契約は Artifact Registry and Auth Platform interface agreement であり、Artifact Registry が 6 つの要件（R1–R6）全体で必要とするものを定義しています。ADR-020 は認証要件（R1–R3）を扱います。この ADR は認可要件である R4（ポリシー評価エンジン）、R5（relationships API）、R6（ブートストラップ） を扱います。

権限モデル

操作を許可または拒否するために、Artifact Registry は 3 つの要素を評価します。

• プリンシパル: ADR-020 によって確立される、認証済みのユーザーまたはトークン保持者です。これはトークンの sub claim によって識別されます。トークンペイロードの形は ADR-020 で説明されています。すべての認証情報タイプ（personal、OAuth、CI job、group、project access token）は同じ User プリンシパルに解決されるため、クローズドベータでは、使用された認証情報に関係なく、プリンシパルのみで認可します。そのため、漏えいした CI job token はユーザーの完全な権限を持ちます。これはクローズドベータ向けの意図的なトレードオフです（トークンはデフォルトで短命です。ADR-020 を参照）。認証情報タイプごとに認可を区別することは未解決の問いです。
• 操作: リポジトリ管理操作とアーティファクト操作の 2 種類があります。ADR-009 で詳細に説明されています。
• リソース: リソースは 2 つのレベルに存在します。namespace（レジストリ全体。ADR-022 を参照）または個別リポジトリです。ロールはこれらのレベルで割り当てられます（ロール割り当てを参照）。クローズドベータでは、namespace は organization と 1 対 1 で対応します。

Artifact Registry はロールと権限のモデルを使用します。

• ロールは、リソースのコンテキストで_プリンシパルが誰であるか_を定義します。プリンシパルには relationships API（R5）を通じてロールが割り当てられます。クローズドベータでは、Artifact Registry がこれらのロール割り当てを取得し、ポリシーエンジンがそこから有効な権限を解決します。目標状態では、認可 claim が enriched token に含まれて届きます。
• 権限は、_プリンシパルが何を実行できるか_を定義します。各ロールは、組み込みデフォルトで定義された固定の権限セット（「権限バケット」）に対応します。

必要な権限がプリンシパルの有効な権限セットに存在する場合、操作は許可されます。

例:

• 管理操作: リポジトリの作成には create_repository 権限が必要で、これは Artifact Admin ロールが保持します。
• アーティファクト操作: アーティファクトの公開には create_artifact 権限が必要で、これは Artifact Contributor、Artifact Manager、Artifact Admin ロールが保持します。

クローズドベータでは、これらのロールから権限へのマッピングは固定です。以降のイテレーションでアクセスルールを追加し、アーティファクト権限を引き締められるようにします（たとえば、本番リポジトリへの公開を許可するロールから Artifact Contributor を外すなど）。

制約

この決定は、次の 3 つの制約によって形作られています。

• デフォルトでは閉じる。 organization（またはその group や project）のメンバーシップは、Artifact Registry へのアクセスを一切付与しません。Artifact Registry のロールが明示的に割り当てられるまで、プリンシパルには権限がありません。これは、roles management work item におけるチーム横断の方向性と一致する、secure-by-default のための意図的な方針です。
• プラットフォームメンバーシップから継承しない。 トップレベル group や project のロールは、Artifact Registry のロールにはマッピングされません。Artifact Registry のロールは、プロダクト固有の独立した概念であり、個別に割り当てられます。
• リクエスト処理中に GitLab インスタンスへコールバックしない。 リクエストを認可するために必要なものはすべて、到達不能な可能性がある GitLab インスタンスへ到達しなくても利用可能でなければなりません。この制約の対象は_そのインスタンス_であり、Artifact Registry と同じ場所に配置された依存関係、つまり relationships API と GLAZ ポリシーエンジンサイドカーではありません。クローズドベータでは、Artifact Registry は各リクエストでその両方を呼び出します。relationships API でロールを解決し、サイドカーでそれらを評価します。これらは同じ場所に配置されているため許容されます（interface agreementを参照）。依存関係が利用できない場合、認可は fail closed になります。ただし、fail-open/fail-closed のポリシーはまだ未解決の問いです。

決定

プロダクト固有の Artifact Registry ロールを定義します。auth platform の relationships API を通じて、それらを namespace と個別リポジトリに割り当てます。同じ場所に配置されたポリシー評価エンジン（GLAZ、サイドカー）を通じて、組み込みのロールから権限へのデフォルトを使って権限を評価します。アクセスはデフォルトで閉じられ、Organization Administrator にはフルアクセスがブートストラップされます。

クローズドベータでは、認可は 2 つのメカニズムを使用します。

1. Namespace ロール割り当て（詳細） — プリンシパルには namespace 上のロールが割り当てられ、レジストリ内のすべてのリポジトリに継承されるベースラインの権限セットが付与されます。
2. 加算的なリポジトリオーバーライド（詳細） — プリンシパルには個別リポジトリ上の追加ロールを割り当てることができ、そこで権限を追加します。クローズドベータではオーバーライドは加算的です。特定リポジトリでアクセスを減らすことは延期されます。

これにより関心事が明確に分離されます。auth platform はロール割り当て（relationships）を保存し、ポリシー評価エンジンを提供します。Artifact Registry はロール定義と権限モデルを所有し、同じ場所に配置されたエンジンを通じてすべての判断を行います。

ロール

Artifact Registry は、Artifact Registry にスコープされた、プラットフォームロールとは異なる 4 つのプロダクト固有ロールを定義します。

これらはユーザーロールであり、プラットフォームのユーザータイプ（例: Organization Administrator または Organization Member）とは異なります。ユーザータイプは Artifact Registry ロールを意味しません。この 2 つは独立して割り当てられます。この区別の背後にあるチーム横断の整合性については、roles management work item を参照してください。

ロールが割り当てられていないプリンシパルは、プライベートリポジトリへアクセスできません（デフォルトでは閉じる）。公開リポジトリは割り当てなしでも読み取り可能です。リポジトリの可視性を参照してください。

Organization Administrator には、Artifact Admin と同等のフルアクセスがブートストラップされます（R6）。Organization Administrator は organization レベルの owner relationship、つまり owner と organization を束ねるタプルを持ちます。これは所有者の変更に合わせて継続的に維持されます（owner role assignments work item）。ポリシーエンジンは、そのタプルを organization の Artifact Registry namespace とその配下のすべてのリポジトリへの暗黙的アクセスとして扱います。この付与は暗黙的で取り消し不可です。owner であり続ける限り、取り消したりダウングレードしたりできません。これは通常の relationship レコードを通じて流れ、他の割り当てと同じように評価されるため、Artifact Registry 側で特別な処理は不要です。これにより、有効化時に割り当てがまだ存在しなくても、Organization Administrator がリポジトリを作成し、他のユーザーへロールを割り当てられることが保証されます。

カスタムロールはクローズドベータのスコープ外です。カスタムロールを参照してください。

権限

Artifact Registry は固定の権限セットを定義します。

権限は GitLab の権限の規約に従います。すべての権限はアクションと resource(_subresource) を命名し、アクションは read、create、update、delete のいずれかです。この規約をここに適用することで、次の 3 つの結果が生まれます。

• 可逆的な関係は、独自の動詞ではなくリソースとしてモデル化されます。virtual リポジトリの upstream は repository_upstream です。ホスト型または remote リポジトリを関連付けるために作成し、関連付けを解除するために削除します。
• キャッシュはアーティファクト権限を再利用します。個別のキャッシュ権限はありません。Remote リポジトリは、ホスト型スキーマを反映したテーブルにアーティファクトをキャッシュし（ADR-007）、同じエンドポイントを通じて提供します（ADR-009）。
• read_repository は virtual リポジトリの upstream リストも公開します。解決順序は、そのリポジトリを使用するすべての人に関係するためです。

デフォルト権限バケット

各ロールは、下に示す固定の権限セットに対応します（✓ = そのロールが保持）。ロールは、割り当てられた場所に関係なく同じ権限を保持します。変わるのは_到達範囲_です。namespace 割り当てではレジストリ全体に適用され、リポジトリ割り当てではそのリポジトリのみに適用されます。

各ロールは独立した権限バケットです。ロール間に階層や継承はなく、その列でマークされた権限だけを付与します。

リポジトリの可視性

各リポジトリには、public または private の可視性レベルがあり、Artifact Registry データベースに保存されます（ADR-007: Database Schema を参照）。可視性は Artifact Registry ネイティブの属性であり、外部エンティティには同期されません。

可視性が影響するのは、ベースラインの読み取りアクセスのみです。

• Public: ロール割り当てが存在しない場合でも、リポジトリの public 属性に基づいて公開読み取りが付与されます。そのため、認証されていない呼び出し元を含むすべての呼び出し元がリポジトリとそのアーティファクトを読み取れます。ロールが割り当てられている呼び出し元は、そのロールが付与するものも追加で保持します。
• Private: ロールが割り当てられていない場合、アクセスできません。

書き込み操作と管理操作は、可視性に関係なく、常に割り当てられたロールから対応する権限を必要とします。

Internal visibility は GA 後のイテレーションに延期されます。クローズドベータでは public と private のみをサポートします。

Namespace レベルとリポジトリレベルのリソース

Namespace レベルのリソース

すべての namespace レベルリソースは、固定の権限要件を持つ管理操作です。

リポジトリレベルのリソース

管理操作（固定の権限要件）:

namespace 全体およびリポジトリ内で一覧表示をどのように認可するかは、一覧操作で説明します。

アーティファクト操作（デフォルト権限バケット）:

公開には、形式のプロトコルで許可される場合の再公開が含まれます（Maven SNAPSHOT の再デプロイ、OCI tag の再 push）。公開済みの npm version のような immutable アーティファクトは、プロトコルにより上書きできません。個別の上書き権限はありません。既存アーティファクトの上書きを防ぐことは、クローズドベータから延期されるアクセスルール機能（overwrite アクション）です。

クローズドベータでは、これらのデフォルトは固定です。以降のイテレーションでアクセスルールを追加し、それらを引き締められるようにします。

ロール割り当て

ロールは、auth platform の relationships API（R5）を通じて (subject, role, resource) タプルとして割り当てられます。subject はトークンから解決される relationships-API の Identity 型（origin、origin_id、local_id）であり、resource は Artifact Registry namespace またはリポジトリです。ロール割り当ては、subject をその subject の organization 内のリソースに結び付けます。

ロール割り当ての管理自体も、権限が必要な操作です。Artifact Admin と Artifact Manager ロールはそれらを作成、更新、削除できますが、Artifact Viewer と Artifact Contributor はできません（決定）。この能力は、ロールがどこで保持されていても同一です。異なるのはスコープだけです。namespace レベルのロールはレジストリ全体の割り当てを管理し、リポジトリレベルのロールはそのリポジトリ上の割り当てを管理します。プリンシパルは自分より上位のロールを付与できません。Artifact Manager は Artifact Admin を作成できません。これは project Maintainer が member を Owner に昇格できないのと同じです。これは GitLab UI を通じて行われ、Rails が frontend と API を提供します（R5）。relationships API は書き込み自体を認可します（relationships-API write authorization）。relationships API 自体は gRPC であるため、この Rails surface は GraphQL-over-gRPC ラッパーです（GraphQL wrapper work item）。namespace は organization と 1 対 1 で対応するため、これは organization のアクセス管理体験を通じて表示されます。

ロールは、2 つのリソースレベルのいずれか、つまり namespace またはリポジトリで動作し、4 つのロールはいずれもどちらのレベルにも割り当てられます。

• Namespace（トップレベル）: ロールはレジストリ全体、つまりすべてのリポジトリに適用されます。たとえば、namespace レベルの Artifact Manager はすべてのリポジトリの manager です。namespace レベルの Artifact Viewer はすべてのリポジトリを読み取れます。これは、管理者が数千人のユーザーへ大規模にアクセスを付与できるようにするベースラインです。Organization Administrator は namespace レベルの Artifact Admin としてブートストラップされます（R6）。
• リポジトリ（加算的オーバーライド）: 単一リポジトリに割り当てられたロールは、そのリポジトリに対するプリンシパルの namespace ロールへ権限を追加します。権限を増やすことだけができ、減らすことはできません。プリンシパルの有効な権限は、namespace レベルとリポジトリレベルの割り当ての和集合です。特定リポジトリでアクセスを減らすこと（減算的オーバーライド）は、クローズドベータから延期されます。

create_repository と delete_repository はレジストリ全体に対して作用するため、Artifact Admin ロールは主に namespace レベルの割り当てとして意味を持ちます。リポジトリオーバーライドとして割り当てられても、そのリポジトリに対する Artifact Manager を超える意味のあるものは追加されません。

各リクエストは 1 つのリソースに対して解決されます。 リクエストは、それが指す単一リソースに対して認可されます。relationships lookup はそのリソースと祖先（リポジトリ → namespace → organization）でフィルタリングされるため、_別の_リポジトリの割り当てが判断に含まれることはありません。オーバーライドは権限を上げるだけなので、有効ロールは該当する中で最上位のものになります。「最も制限的」という解決はありません。これは仮想リポジトリにも含まれます。仮想リポジトリを経由して提供されるリクエストは、その仮想リポジトリ自体のロールに対して解決される一方、含まれるホスト型またはリモートリポジトリに割り当てられたロールは、その含まれるリポジトリに直接宛てたリクエストを制御します。したがって、仮想リポジトリのロールは、それを経由して提供される集約対象コンテンツへのアクセスを許可します。これは、含まれるリポジトリの割り当てを迂回するものではなく、設計どおりです。

ロール割り当てが Artifact Registry に届く方法は、イテレーションによって異なります。

• クローズドベータ: トークンはアイデンティティとコンテキストのみを運びます（認可 claim はありません）。Artifact Registry は同じ場所に配置された relationships API に問い合わせ、対象リソースでフィルタリングします。namespace 操作では namespace id と organization id を渡し、リポジトリ操作では repository id、namespace id、organization id を渡します。API はそのリソースとその祖先に対するプリンシパルのロール割り当てを membership tuple として返します。Artifact Registry はそれらのすべてのタプルをポリシーエンジンに渡し、ポリシーエンジンが有効な権限を解決します。オーバーライドは加算的であるため、権限は namespace レベルとリポジトリレベルの割り当ての和集合です（エンジンのネイティブな most-permissive 評価）。Artifact Registry は relationships API のレスポンスを、AR で設定された短い期間（デフォルト 30 秒、最大 60 秒）キャッシュします。キャッシュは relationships API に送られた入力、つまりプリンシパル、操作、対象リソースをキーにします。そのため、キャッシュされた結果が別のプリンシパル、操作、リソースに再利用されることはありません。その結果、取り消しを含む最近のロール割り当て変更は、即時に適用されるのではなく、最大でその時間枠だけ反映に時間がかかる可能性があります。
• 目標状態: auth platform の enrichment layer がロール割り当てを解決し、enriched token に認可 claim を含めるため、lookup は不要になります。ADR-020 がこの ADR に委ねているそれらの claim の形は、enrichment layer が出荷されるときに定義されます。

認可フロー

認可は認証の後に始まります。Artifact Registry はすでにトークンを検証し、プリンシパルを確立しています（ADR-020）。次に、relationships API からプリンシパルのロール割り当てを取得し、同じ場所に配置されたポリシーエンジンサイドカーに要求されたアクションの評価を依頼し、GitLab インスタンスへコールバックせずに判断を返します。

下記のフローは、認証済みプリンシパルを前提としています。認証されていないリクエストにはトークンがありません。公開リポジトリでは、リポジトリの public 属性に基づいて読み取りが許可され、非公開リポジトリでは拒否されます。リポジトリの可視性を参照してください。

sequenceDiagram
    participant Client
    participant AR as Artifact Registry
    participant Rel as Relationships API<br/>(co-located)
    participant PE as Policy Engine<br/>(co-located sidecar)

    Client->>AR: Request with validated token (principal + context)
    Note over AR: Identity established per ADR-020

    Note over AR,Rel: Step 1 — Look up role assignments
    AR->>Rel: Look up role assignments (filtered by target resource:<br/>namespace+org, or repository+namespace+org)
    Rel-->>AR: Assignments for the resource and its ancestors (membership tuples)
    Note over AR,Rel: Target state: authorization claims arrive in the enriched token,<br/>so this lookup is skipped

    Note over AR,PE: Step 2 — Evaluate the action
    AR->>PE: Role tuples + action + context (resource attributes)
    Note over PE: roles → permission buckets (predefined policy),<br/>union, then check the requested action
    PE-->>AR: ALLOW / DENY (with policy ID)

    AR-->>Client: Response (403, or 404 if the resource is unreadable)

操作が拒否された場合、ステータスコードは、プリンシパルがそのリソースの存在を見ることさえできるかどうかによって変わります。これは、一覧および閲覧操作に適用されるメタデータ漏えい防止と同じです。

• プリンシパルがリソースを読み取れない（例: そのプリンシパルがロールを持たない private リポジトリ）: Artifact Registry は直接アクセスに対して 404 Not Found を返し、リソースの存在を確認させません。これは一覧結果のフィルタリングと一致します。
• プリンシパルはリソースを読み取れるが、特定の操作が不足している（例: ロールは持っているが delete_repository は持っていない）: リソースの存在はすでに知られているため、Artifact Registry は 403 Forbidden を返します。

どちらの場合も、認可ポリシーの詳細が漏えいすることを避けるため、レスポンスは拒否の原因となった権限やポリシーを明かしません。ポリシーエンジンは、監査ログとデバッグのために判断を決定したポリシー ID を返します（R4）。

一覧操作

一覧は一度に多くのリソースにまたがるため、上記の単一リソース評価には当てはまりません。

リポジトリ一覧（namespace スコープ）。 Artifact Registry は、リポジトリごとに 1 回ずつ確認するのではなく、単一の namespace レベルチェックでこれを判断します。

• 任意の namespace レベルロールを持つプリンシパルは、その namespace 内のすべてのリポジトリを一覧表示できます。すべてのロールは read_repository を含むため、これは「プリンシパルが namespace でロールを持っているか」に単純化されます。その後、Artifact Registry は自身のデータベースからリポジトリを列挙します。
• namespace レベルロールを持たないプリンシパル（認証されていない呼び出し元を含む）には、各リポジトリの public 属性から解決される公開リポジトリのみが見えます。

レジストリ全体の統計の表示も同じように機能します。これは単一リポジトリではなくレジストリ全体を要約するため、namespace レベルロールが必要です。

リポジトリ内の一覧（リポジトリスコープ）。 リポジトリのコンテンツまたはサブリソースを閲覧することは単一リポジトリを対象とするため、そのリポジトリに対する通常のポイントチェックです。アーティファクト/コンテンツ一覧（tag、version、file）には read_artifact が必要です。リポジトリ詳細、リポジトリ単位の統計、upstream リストには read_repository が必要です。

すべての場合において、プリンシパルが読み取れないリソースは拒否されるのではなく結果から省略されます。空または部分的な一覧になり、エラーも、隠されたリソースが存在することを示す情報もありません。これによりメタデータ漏えいを防ぎます。

後続イテレーションへ延期

次の機能は、意図的にクローズドベータのスコープ外です。設計を記録に残すためここに文書化しており、クローズドベータの顧客需要に基づいて再検討します。

減算的リポジトリオーバーライド

クローズドベータでは、**加算的（引き上げのみ）**のリポジトリオーバーライドをサポートします。リポジトリレベルの割り当てはそのリポジトリ上で権限を追加するだけであり、Artifact Registry は namespace とリポジトリの割り当ての和集合を付与します（ロール割り当てを参照）。

特定リポジトリ上でプリンシパルのアクセスを下げること（減算的オーバーライド）はスコープ外です。これは、GitLab 全体で機能しているロール継承と衝突するためです。namespace レベルの割り当てはすべてのリポジトリへ伝播します。これが追加される場合、Artifact Registry は namespace レベルとリポジトリレベルの両方でプリンシパルの権限を読み取り、それらの和集合を取るのではなく、リポジトリレベルが完全に優先されるようにして、アクセスを_引き上げる_ことも_引き下げる_こともできるようにすることで優先順位を解決します。

アクセスルール

アクセスルールにより、管理者は_どのロールがアーティファクト権限を保持するか_を、namespace、リポジトリ、またはパターンに一致するアーティファクト上で、プリンシパルを指定せずに引き締められます。これは、特定のアーティファクトを保護すること、重複アップロードを許可または防止することという 2 つの顧客ユースケースを扱います。ポリシーエンジン（R4）向けのユーザー定義ポリシーとしてモデル化され、組み込みデフォルトを引き締めることだけができ、広げることはできません。この機能とともに導入される専用の *_access_rule 権限セットを通じて管理されます。これらは延期されるため、クローズドベータではリポジトリごとに権限を引き締めることはできません。

カスタムロール

カスタムロールはクローズドベータから延期されます。custom roles roadmap work item を参照してください。

権限モデルは、カスタムロールを自然に扱えます。カスタムロールは、独自の権限バケットを持つ新しいロールです。ロールは独立した権限バケットであるため、カスタムロールには Artifact Registry 権限の任意の組み合わせを含められます（例: read_artifact と create_artifact は持つが read_repository は持たない “CI Publisher” ロール）。auth platform を通じて定義されたカスタムロールは、同じ relationships API を通じて割り当てられ、組み込みロールと同じようにアクセスルールで参照できます。

影響

ポジティブ

1. プラットフォームの方向性と一致している。 Artifact Registry は独自の認可システムを構築するのではなく、auth platform の relationships API とポリシー評価エンジン（R4、R5）を利用し、統合の方向性と一致します。
2. 同じ場所に配置された評価。 ロール割り当てが利用可能になると（クローズドベータでは解決され、目標状態では enriched token に含まれる）、権限判断は GitLab インスタンスへコールバックせず、同じ場所に配置されたサービスを通じて行われます。
3. 関心事の明確な分離。 アイデンティティは ADR-020 で確立されます。この ADR はプリンシパルが何を実行できるかに答えます。auth platform は割り当てを保存し、Artifact Registry はロールと権限モデルを所有します。
4. デフォルトでセキュア。 プラットフォームメンバーシップからの継承がなく、デフォルトで閉じたアクセスは、明示的に割り当てられた場合にのみアクセスが付与されることを意味し、エンタープライズ顧客が重視するものです。
5. 権限モデルが維持され、移植しやすい。 独立した権限バケットとしてのロールは、ポリシーエンジンの「deny overrides」モデルに一致し、将来の移行作業を最小化します。

ネガティブ

1. クローズドベータのロール解決。 enrichment layer が出荷されるまで、Artifact Registry はトークンから claim を読むのではなく、relationships API に問い合わせてロール割り当てを自ら解決します。これはより複雑です。
2. オンボーディングの負荷。 デフォルトで閉じるには明示的なロール割り当てが必要であり、管理作業が増えます。これは Organizations UI の一括割り当てワークフローによって緩和されます。
3. ロール増殖の可能性。 プロダクト固有ロールは時間とともに大きなリストへ増える可能性があります。これは roles management work item の north star に従い、スケーリングメカニズムとして Teams と group template によって緩和されます。
4. クローズドベータではリポジトリごとの引き締めがない。 アクセスルールや減算的オーバーライドがない場合、管理権限はレジストリ全体で保持され、プリンシパルのアクセスはリポジトリ上で引き上げることだけができ、引き下げることはできません。どちらも延期され、顧客需要に基づいて再検討されます。

検討した代替案

Organization Teams

Organization Teams は、ベースロールと任意の権限修飾子をユーザーに割り当てる第一級エンティティとして Teams を導入し、明示的な継承制御を備えます。Artifact Registry は、ベースラインアクセス用に organization ごとの Team を使用し、リポジトリごとの粒度は sub-team を通じて扱うこともできました。

今採用しない理由: Organization Teams は proposed ステータスであり、Artifact Registry のタイムラインでは利用できません。Teams は、roles management work item の north star に従った、ロール割り当ての将来的なスケーリングメカニズムであり続けます。relationships API を通じて行われるロール割り当ては、その方向性と互換性があります。

Artifact Registry ネイティブの認可

Artifact Registry は、auth platform に依存せず、独自のユーザー・リソース関係と権限ロジックを維持することもできました。

採用しない理由: これはプラットフォームの認可システムとは別に、もう 1 つの認可システムを導入することになり、統合の方向性とは逆に断片化を増やします。ユーザー管理をゼロから構築する必要があり、一貫性のないユーザー体験を生み、後からプラットフォームへ収束させることも難しくなります。relationships API（R5）は、この ADR が必要とするリソースごとのロール割り当てを、これらの欠点なしに提供します。

未解決の問い

1. relationships service が利用できない場合の振る舞い。 クローズドベータでは fail closed（リクエストを拒否）ですが、fail-open と fail-closed のどちらにするかのポリシーはまだ最終決定中です（infrastructure discussion）。
2. スケール時の organization から namespace への解決。 ロール割り当ては Artifact Registry namespace に付与され、これはクローズドベータでは organization と 1 対 1 で対応します（ADR-022）。将来の organization merge によって複数の namespace が 1 つの organization 配下に置かれる場合、organization 全体の関心事、つまり owner ブートストラップと割り当てに関する org スコープ不変条件を、それら全体でどのように解決するかを定義します。
3. 認証情報タイプを意識した認可。 クローズドベータでは User プリンシパルのみで認可します。すべての認証情報タイプは同じプリンシパルに解決されるため（ADR-020）、漏えいした CI job token はユーザーの完全な権限を持ちます。認証情報タイプによって認可を制約するかどうか、たとえば CI job token を publish-only に制限するかどうかは延期されます。そのためにはまず ADR-020 がトークンに認証情報タイプを含める必要があるため、ADR-020/ADR-021 共同の follow-up です。
4. Interface agreement との整合。 interface agreement は現在、Artifact Registry が 5 つの組み込み GitLab ロールを使用し、「独自のロールを定義しない」と述べています。このセクションは、Auth Platform チームと調整して、ここで決定したプロダクト固有ロールを反映する companion update が必要です。

参考文献

• ADR-001: Organizations as Anchor Point
• ADR-007: Database Schema — アクセスルール
• ADR-009: API Design — 管理 API とクライアント API エンドポイント
• ADR-020: Authentication Flow — アイデンティティの確立とトークン検証
• ADR-022: Namespace Decoupling
• Artifact Registry and Auth Platform interface agreement — ここで扱う R4–R6（認可）要件
• Relationships API — IAM relationships API contract。クローズドベータでは、リソースとその祖先に対する直接 relationship tuple を返し、ポリシーエンジンがそれを和集合（加算的オーバーライド）として評価します
• GitLab permission conventions — これらの権限が従う命名規則と CRUD 分解ルール
• Roles management and Artifact Registry onboarding — プロダクト固有ロール、デフォルトで閉じる、3 部構成モデル
• GATE Design Document — GitLab Adaptive Trust Environment
• Organization Teams Blueprint
• ADR-012: Organizations, Roles, and Permissions in Artifact Registry
• Custom roles roadmap

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