ロールと権限

ロールは、グループまたはプロジェクトにおけるユーザーの権限を定義します。

管理者アクセスを持つユーザーは、すべての権限を持ち、あらゆる操作を実行できます。

ロール

ユーザーをプロジェクトまたはグループに追加する際に、ロールを割り当てます。ロールによって、ユーザーの権限が決まります。デフォルトロールまたはカスタムロールのいずれかを割り当てます。

ユーザーは、グループおよびプロジェクトごとに異なるロールを持つことができます。ユーザーは常に、自分のロールのうち最も高いロールの権限を継承します。たとえば、ユーザーが以下を持っているとします:

• 親グループのメンテナーロール
• そのグループ内のプロジェクトのデベロッパーロール

ユーザーは、プロジェクト内でメンテナーロールの権限を継承します。

割り当てられたロールを表示するには、グループまたはプロジェクトのメンバーページに移動します。

デフォルトロール

次のデフォルトロールを使用できます:

デフォルトでは、すべてのユーザーがトップレベルグループを作成し、ユーザー名を変更できます。管理者アクセスを持つユーザーは、この動作を変更できます。

グループメンバーの権限

グループの唯一のオーナーでない限り、どのユーザーもグループから自分自身を削除できます。

次の表は、各ロールで利用可能なグループ権限を示しています:

分析グループの権限

分析機能（バリューストリーム、プロダクト分析、インサイトなど）のグループ権限:

アプリケーションセキュリティグループの権限

依存関係管理、セキュリティアナライザー、セキュリティポリシー、脆弱性管理などのアプリケーションセキュリティ機能のグループ権限。

CI/CDグループの権限

Runner、変数、保護環境などのCI/CD機能のグループ権限:

コンプライアンスグループの権限

コンプライアンスセンター、監査イベント、コンプライアンスフレームワーク、ライセンスなどのコンプライアンス機能のグループ権限。

Footnotes（脚注）

1. ユーザーは、個々のアクションに基づいたイベントのみを閲覧できます。詳細については、前提要件を参照してください。

GitLab Duoグループの権限

GitLab Duoのグループ権限:

Footnotes（脚注）

1. ユーザーがGitLab Duo ProまたはGitLab Duo Enterpriseを使用している場合、そのGitLab Duoアドオンにアクセスするには、ユーザーにシートを割り当てる必要があります。ユーザーがGitLab Duo Coreを使用している場合、他の要件はありません。

グループのグループ権限

グループ機能のグループ権限:

Footnotes（脚注）

1. 開発者とメンテナーは、個々のアクションに基づいたイベントのみを閲覧できます。詳細については、前提要件を参照してください。
2. デベロッパー、メンテナー、オーナー: インスタンスまたはグループにプロジェクト作成ロールが設定されている場合にのみ適用されます。
   デベロッパー: デベロッパーは、デフォルトブランチ保護が「部分的に保護されている」または「保護されていない」に設定されている場合にのみ、新しいプロジェクトのデフォルトブランチにコミットをプッシュできます。
3. メンテナー: メンテナーロールを持つユーザーがサブグループを作成できる場合にのみ適用されます。
4. サブグループには適用されません。

プロジェクト計画グループの権限

Footnotes（脚注）

1. エピックを表示する権限が必要です。
2. エピックを表示し、イシューを編集する権限が必要です。
3. 親エピックと子エピックを表示する権限が必要です。
4. エピックを表示するには、権限が必要です。

Wikiのグループ権限:

Footnotes（脚注）

1. ゲスト: さらに、グループが公開または内部の場合、グループを表示できるすべてのユーザーは、グループWikiページも表示できます。
2. ゲスト: さらに、グループが公開または内部の場合、グループを表示できるすべてのユーザーは、グループWikiページも表示できます。

パッケージとレジストリのグループ権限

パッケージおよびコンテナレジストリのグループ権限:

Footnotes（脚注）

1. ゲストは、個々のアクションに基づいたイベントのみを表示できます。

パッケージレジストリのグループ権限:

リポジトリグループ権限

マージリクエスト、プッシュルール、デプロイトークンなどのリポジトリ機能のグループ権限。

ユーザー管理グループ権限

ユーザー管理のグループ権限:

ワークスペースのグループ権限

ワークスペースのグループ権限:

プロジェクトメンバーの権限

ユーザーのロールによって、プロジェクトで持つ権限が決まります。オーナーロールはすべての権限を提供しますが、次のロールでのみ使用できます:

• グループおよびプロジェクトのオーナー。
• 管理者。

個人のネームスペースオーナーについて:

• ネームスペース内のプロジェクトではメンテナーロールとして表示されますが、実際にはオーナーロールと同じ権限を持っています。
• ネームスペース内の新しいプロジェクトでは、オーナーロールとして表示されます。

保護されたブランチの設定を構成するときに、ロールを選択すると、そのロール以上のすべてのロールを持つユーザーにアクセス権が付与されます。たとえば、保護ブランチの設定でメンテナーを選択した場合、メンテナーとオーナーの両方のロールを持つユーザーがアクションを実行できます。

プロジェクトメンバーの管理方法の詳細については、プロジェクトのメンバーを参照してください。

次の表に、ロールごとに使用できるプロジェクト権限を示します。

分析

バリューストリーム、使用状況トレンド、プロダクト分析、インサイトなどの分析機能のプロジェクト権限。

アプリケーションセキュリティ

依存関係管理、セキュリティアナライザー、セキュリティポリシー、脆弱性管理などのアプリケーションセキュリティ機能のプロジェクト権限。

Footnotes（脚注）

1. admin_vulnerability権限は、GitLab 17.0でデベロッパーロールから削除されました。

CI/CD

一部のロールに対するGitLab CI/CD権限は、次の設定で変更できます:

• プロジェクトベースのパイプラインの表示レベル: 公開に設定すると、特定のCI/CD機能へのアクセスがゲストプロジェクトメンバーに許可されます。
• パイプラインの表示レベル: Everyone with Access（アクセスできるすべてのユーザー）に設定すると、特定のCI/CD「表示」機能へのアクセスがプロジェクトメンバー以外のユーザーに許可されます。

プロジェクトオーナーはリストされているすべてのアクションを実行でき、パイプラインを削除できます:

Footnotes（脚注）

1. 非メンバーとゲスト: プロジェクトが公開の場合のみ。
2. 非メンバー: プロジェクトが公開されており、プロジェクトベースのパイプラインの表示レベルが有効になっている場合のみ。
   ゲスト: プロジェクトベースのパイプラインの表示レベルが有効な場合のみ。
3. 非メンバー: プロジェクトが公開されており、プロジェクトベースのパイプラインの表示レベルが有効になっていて、ジョブでartifacts:public: falseが設定されていない場合のみ。
   ゲスト: プロジェクトベースのパイプラインの表示レベルが有効で、artifacts:public: falseがジョブに設定されていない場合にのみ。
   レポーター: artifacts:public: falseがジョブに設定されていない場合のみ。
4. ゲスト: プロジェクトベースのパイプラインの表示レベルが有効な場合のみ。
5. レポーター: ユーザーが保護環境へのアクセス権を持つグループのメンバーである場合のみ。
   デベロッパーとメンテナー: ユーザーが保護環境へのデプロイを許可されている場合のみ。
6. デベロッパーとメンテナー: ユーザーが保護ブランチへのマージまたはプッシュを許可されている場合のみ。
7. デベロッパー: ジョブがユーザーによってトリガーされ、保護されていないブランチに対して実行される場合のみ。
8. キャンセル権限は、パイプライン設定で制限できます。
9. メンテナー: Runnerに関連付けられたプロジェクトのメンテナーロールが必要です。
10. メンテナー: オーナープロジェクト（Runnerに最初に関連付けられたプロジェクト）のメンテナーロールが必要です。
11. メンテナー: 追加されるプロジェクトと、すでにRunnerに関連付けられたプロジェクトのメンテナーロールが必要です。
12. デベロッパー: ユーザーにマージ権限があるブランチのみ。保護ブランチの場合は、ターゲットブランチに対するマージ権限が必要です。保護タグの場合、ユーザーは保護タグを作成できる必要があります。これらの権限要件は、スケジュールの作成または編集時に適用され、ブランチ保護ルールが時間の経過とともに変化する可能性があるため、動的にチェックされます。
13. 手動で実行すると、パイプラインは、スケジュールオーナーの権限ではなく、トリガーするユーザーの権限で実行されます。

この表は、特定のロールによってトリガーされたジョブに付与される権限を示しています。

プロジェクトオーナーはリストされているアクションを実行できますが、ソースとLFSを一緒にプッシュすることはできません。ゲストユーザーとレポーターロールのメンバーは、これらのアクションを実行できません。

Footnotes（脚注）

1. デベロッパーとメンテナー: トリガーユーザーが外部ユーザーでない場合のみ。
2. トリガーユーザーがプロジェクトのメンバーである場合のみ。プルポリシーif-not-presentでの非公開Dockerイメージの使用も参照してください。
3. コンテナイメージを他のプロジェクトにプッシュすることはできません。

コンプライアンス

コンプライアンスセンター、監査イベント、コンプライアンスフレームワーク、ライセンスなどを含む、コンプライアンス機能のプロジェクト権限。

Footnotes（脚注）

1. GitLab Self-Managedでは、ゲストロールを持つユーザーは、公開および内部プロジェクトでのみこのアクションを実行できます（非公開プロジェクトでは実行できません）。外部ユーザーは、プロジェクトが内部であっても、少なくともレポーターロールを持っている必要があります。GitLab.comのゲストロールを持つユーザーは、内部の表示レベルが利用できないため、公開プロジェクトでのみこのアクションを実行できます。
2. ユーザーは、個々のアクションに基づいたイベントのみを表示できます。詳細については、前提要件を参照してください。

GitLab Duo

GitLab Duoのプロジェクト権限:

Footnotes（脚注）

1. コード提案では、ユーザーがGitLab Duoアドオンにアクセスするためのシートが割り当て済みである必要があります。

機械学習モデルレジストリと実験

モデルレジストリとモデル実験のプロジェクト権限。

Footnotes（脚注）

1. 非メンバーはEveryone with access（アクセスできるすべてのユーザー）の表示レベルで、公開プロジェクトのモデルとバージョンのみを表示できます。非メンバーはログインしていても内部プロジェクトを表示できません。
2. 非メンバーはEveryone with access（アクセスできるすべてのユーザー）の表示レベルで、公開プロジェクトのモデル実験のみを表示できます。非メンバーはログインしていても内部プロジェクトを表示できません。
3. パッケージレジストリAPIを使用して、アーティファクトをアップロードおよびダウンロードすることもできます。これには別の権限セットが使用されます。

モニタリング

エラートラッキングやインシデント管理などのモニタリングのプロジェクト権限:

プロジェクト計画

イシューのプロジェクト権限:

Footnotes（脚注）

1. メタデータには、ラベル、担当者、マイルストーン、エピック、ウェイト、公開設定、タイムトラッキングなどが含まれます。ゲストユーザーは、イシューの作成時にのみメタデータを設定できます。既存のイシューのメタデータは変更できません。ゲストユーザーは、作成したイシューまたは割り当て済みのイシューのタイトルと説明を変更できます。
2. ゲストユーザーは、作成したイシューまたは割り当て済みのイシューに対して、完了および再開が可能です。
3. ゲストユーザーは、作成したイシューまたは割り当て済みのイシューに対して、アーカイブおよび再開が可能です。
4. ゲストユーザーは、作成したイシューまたは割り当て済みのイシューのタイトルと説明を変更できます。

タスクのプロジェクト権限:

Footnotes（脚注）

1. ゲストユーザーは、作成したイシューまたは割り当て済みのイシューのタイトルと説明を変更できます。
2. プランナーまたはオーナーのロールを持たないユーザーは、自分が作成したタスクを削除できます。

OKRのプロジェクト権限:

Wikiのプロジェクト権限:

パッケージとレジストリ

コンテナレジストリのプロジェクト権限:

Footnotes（脚注）:

1. コンテナレジストリの表示およびイメージのプルは、コンテナレジストリの表示レベル権限によって制御されます。ゲストロールには、非公開プロジェクトでの表示またはプルの権限がありません。

パッケージレジストリのプロジェクト権限:

Footnotes（脚注）

1. GitLab Self-Managedでは、ゲストロールを持つユーザーは、公開および内部プロジェクトでのみこのアクションを実行できます（非公開プロジェクトでは実行できません）。外部ユーザーには、プロジェクトが内部であっても、明示的なアクセス権（少なくともレポーターロール）を付与する必要があります。GitLab.comのゲストロールのユーザーは、内部表示レベルを利用できないため、公開プロジェクトでのみこのアクションを実行できます。

プロジェクト

プロジェクト機能のプロジェクト権限:

Footnotes（脚注）

1. GitLab Self-Managedでは、ゲストロールを持つユーザーは、公開および内部プロジェクトでのみこのアクションを実行できます（非公開プロジェクトでは実行できません）。外部ユーザーには、プロジェクトが内部であっても、明示的なアクセス権（少なくともレポーターロール）を付与する必要があります。GitLab.comのゲストロールのユーザーは、内部表示レベルを利用できないため、公開プロジェクトでのみこのアクションを実行できます。

2. 設計管理のデザインに関するコメントにのみ適用されます。

3. ゲストユーザーは、アセットをダウンロードするためにGitLabリリースにアクセスできますが、ソースコードをダウンロードしたり、コミットやリリースエビデンスなどのリポジトリ情報を表示したりすることはできません。

4. タグが保護されている場合、デベロッパーとメンテナーに付与されたアクセス権によって異なります。

5. GitLab Self-Managedの場合、プロジェクトアクセストークンは全プランで利用できます。GitLab.comの場合、プロジェクトアクセストークンはPremiumおよびUltimateプランでサポートされています（トライアルライセンスを除く）。

6. プロジェクトの表示レベルが非公開に設定されている場合、メンテナーまたはオーナーはプロジェクトの機能の表示レベルを変更できません。

GitLab Pagesのプロジェクト権限:

リポジトリ

リポジトリ機能（ソースコード、ブランチ、プッシュルールなど）のプロジェクト権限:

Footnotes（脚注）

1. GitLab Self-Managedでは、ゲストロールを持つユーザーは、公開および内部プロジェクトでのみこのアクションを実行できます（非公開プロジェクトでは実行できません）。外部ユーザーには、プロジェクトが内部であっても、明示的なアクセス権（少なくともレポーターロール）を付与する必要があります。GitLab.comのゲストロールのユーザーは、内部表示レベルを利用できないため、公開プロジェクトでのみこのアクションを実行できます。GitLab 15.9以降では、Ultimateプランのライセンスを持つゲストロールのユーザーは、管理者（GitLab Self-ManagedまたはGitLab Dedicated）またはグループオーナー（GitLab.com）が許可した場合、非公開リポジトリのコンテンツを表示できます。管理者またはグループオーナーは、APIまたはUIからカスタムロールを作成し、そのロールをユーザーに割り当てることができます。
2. GitLab Self-Managedでは、ゲストロールを持つユーザーは、公開および内部プロジェクトでのみこのアクションを実行できます（非公開プロジェクトでは実行できません）。外部ユーザーには、プロジェクトが内部であっても、明示的なアクセス権（少なくともレポーターロール）を付与する必要があります。GitLab.comのゲストロールのユーザーは、内部表示レベルを利用できないため、公開プロジェクトでのみこのアクションを実行できます。GitLab 15.9以降では、Ultimateプランのライセンスを持つゲストロールのユーザーは、管理者（Self-ManagedまたはGitLab Dedicated）またはグループオーナー（GitLab.com）が許可した場合、非公開リポジトリのコンテンツを検索できます。管理者またはグループオーナーは、APIまたはUIからカスタムロールを作成し、そのロールをユーザーに割り当てることができます。
3. GitLab Self-Managedでは、ゲストロールを持つユーザーは、公開および内部プロジェクトでのみこのアクションを実行できます（非公開プロジェクトでは実行できません）。外部ユーザーには、プロジェクトが内部であっても、明示的なアクセス権（少なくともレポーターロール）を付与する必要があります。GitLab.comのゲストロールのユーザーは、内部表示レベルを利用できないため、公開プロジェクトでのみこのアクションを実行できます。
4. ブランチが保護されている場合、デベロッパーとメンテナーに付与されたアクセス権によって異なります。
5. GitLab Self-Managedでは、ゲストロールを持つユーザーは、公開および内部プロジェクトでのみこのアクションを実行できます（非公開プロジェクトでは実行できません）。外部ユーザーには、プロジェクトが内部であっても、明示的なアクセス権（少なくともレポーターロール）を付与する必要があります。GitLab.comのゲストロールのユーザーは、内部表示レベルを利用できないため、公開プロジェクトでのみこのアクションを実行できます。GitLab 15.9以降では、Ultimateプランのライセンスを持つゲストロールのユーザーは、管理者（GitLab Self-ManagedまたはGitLab Dedicated）またはグループオーナー（GitLab.com）が許可した場合、非公開リポジトリのコンテンツを表示できます。管理者またはグループオーナーは、APIまたはUIからカスタムロールを作成し、そのロールをユーザーに割り当てることができます。
6. ゲスト、レポーター、デベロッパー、メンテナー、またはオーナーには許可されていません。保護ブランチを参照してください。

マージリクエスト

マージリクエストのプロジェクト権限:

Footnotes（脚注）

1. GitLab Self-Managedでは、ゲストロールを持つユーザーは、公開および内部プロジェクトでのみこのアクションを実行できます（非公開プロジェクトでは実行できません）。外部ユーザーには、プロジェクトが内部であっても、明示的なアクセス権（少なくともレポーターロール）を付与する必要があります。GitLab.comのゲストロールのユーザーは、内部表示レベルを利用できないため、公開プロジェクトでのみこのアクションを実行できます。
2. プランナーとレポーターロールからの承認は、プロジェクトで有効な場合にのみ使用できます。
3. 外部メンバーからのコントリビュートを受け入れるプロジェクトでは、ユーザーは自分のマージリクエストを作成、編集、および完了できます。非公開プロジェクトの場合、ゲストロールは非公開プロジェクトをクローンできないため除外されます。internal（内部）プロジェクトの場合、内部プロジェクトをクローンできるため、プロジェクトへの読み取り専用アクセス権を持つユーザーが含まれます。
4. 外部メンバーからのコントリビュートを受け入れるプロジェクトでは、ユーザーは自分のマージリクエストを作成、編集、および完了できます。担当者、レビュアー、ラベル、マイルストーンなど、一部のフィールドは編集できません。

ユーザー管理

ユーザー管理のプロジェクト権限。

Footnotes（脚注）

1. メンテナーは、オーナーを作成、降格、または削除することはできず、ユーザーをオーナーロールにプロモートすることもできません。また、オーナーロールのアクセスリクエストを承認することもできません。
2. グループ共有ロックが有効になっている場合、プロジェクトを他のグループと共有することはできません。グループとグループの間の共有には影響しません。

サブグループの権限

メンバーをサブグループに追加すると、そのメンバーは親グループからメンバーシップと権限レベルを継承します。このモデルにより、親グループのいずれかにメンバーシップを持っていれば、ネストされたグループへのアクセスが許可されます。

詳細については、サブグループメンバーシップを参照してください。

最小アクセス権を持つユーザー

最小アクセスロールを持つユーザーは、次の対象にはなりません:

• トップレベルグループのプロジェクトおよびサブグループに自動的にアクセスできる。
• GitLab Self-ManagedのUltimateサブスクリプションまたはGitLab.comサブスクリプションで、ライセンスシートとしてカウントされる（ユーザーがインスタンスまたはGitLab.comネームスペース内のどこにも他のロールを持っていない場合）。

オーナーは、これらのユーザーを特定のサブグループおよびプロジェクトに明示的に追加する必要があります。

GitLab.comグループのSAML SSOで最小アクセスロールを使用して、グループ階層内のグループおよびプロジェクトへのアクセスを制御できます。SSOを介してトップレベルグループに自動的に追加されたメンバーのデフォルトロールを最小アクセスに設定できます。

1. 左側のサイドバーで、検索または移動先を選択して、グループを見つけます。新しいナビゲーションをオンにしている場合、このフィールドは上部のバーにあります。
2. 設定 > SAML SSOを選択します。
3. デフォルトのメンバーシップロールドロップダウンリストから、最小アクセスを選択します。
4. 変更を保存を選択します。

最小アクセスユーザーが404エラーを受け取る場合

未解決の問題のため、最小アクセスロールを持つユーザーは以下の状況で404エラーを受け取ります:

• 標準のWeb認証でサインインすると、親グループにアクセスするときに404エラーが表示されます。
• グループSSOでサインインすると、親グループページにリダイレクトされるため、すぐに404エラーが表示されます。

この問題を回避するには、これらのユーザーに、親グループ内の任意のプロジェクトまたはサブグループに対して、少なくともゲストロールを付与します。ゲストユーザーは、Premiumプランではライセンスシートを消費しますが、Ultimateプランでは消費しません。

関連トピック

• リポジトリを保護する
• カスタムロール
• メンバー
• 保護ブランチの権限のカスタマイズ
• LDAPユーザー権限
• バリューストリーム分析の権限
• プロジェクトエイリアス
• 監査担当者ユーザー
• 非公開イシュー
• コンテナレジストリの権限
• リリース権限
• 読み取り専用ネームスペース