ロールと権限

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

管理者アクセスを持つユーザーはすべての権限を持ち、任意のアクションを実行できます。

ロール

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

ユーザーは各グループおよびプロジェクトで異なるロールを持つことができます。ユーザーは常に、その最高ロールの権限を保持します。たとえば、ユーザーが以下の場合:

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

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

割り当てられたロールを表示するには、メンバーページ (グループまたはプロジェクト) にアクセスします。

デフォルトロール

以下のデフォルトロールが利用可能です:

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

グループ権限

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

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

グループ

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

脚注:

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

グループアナリティクス

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

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

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

グループCI/CD

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

グループコンプライアンス

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

脚注:

1. ユーザーは、自身のアクションに基づくイベントのみを表示できます。詳細については、前提条件を参照してください。

グループGitLab Duo

GitLab Duoのグループ権限:

脚注:

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

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

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

脚注:

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

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

グループ計画

脚注:

1. エピックを表示する権限が必要です。
2. エピックを表示し、イシューを編集する権限が必要です。
3. 親エピックと子エピックを表示する権限が必要です。
4. 親エピックを表示する権限が必要です。
5. プランナーまたはオーナーロールを持たないユーザーは、自身が作成したエピックのみを削除できます。

Wikiのグループ権限:

脚注:

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

グループリポジトリ

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

グループユーザー管理

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

グループワークスペース

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

プロジェクト権限

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

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

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

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

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

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

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

プロジェクト

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

脚注:

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

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

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

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

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

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

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

プロジェクトアナリティクス

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

プロジェクトアプリケーションセキュリティ

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

脚注:

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

プロジェクトCI/CD

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

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

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

脚注:

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

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

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

脚注:

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

プロジェクトコンプライアンス

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

脚注:

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

プロジェクトGitLab Duo

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

脚注:

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

プロジェクトマージリクエスト

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

脚注:

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

プロジェクトモデルレジストリと実験

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

脚注:

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

プロジェクトモニタリング

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

プロジェクトパッケージとレジストリ

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

脚注:

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

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

脚注:

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

プロジェクト計画

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

脚注:

1. メタデータには、ラベル、担当者、マイルストーン、エピック、ウェイト、公開設定、タイムトラッキングなどが含まれます。ゲストユーザーは、イシューの作成時にのみメタデータを設定できます。既存のイシューのメタデータは変更できません。ゲストユーザーは、作成したイシューまたは割り当て済みのイシューのタイトルと説明を変更できます。
2. ゲストユーザーは、作成したイシューまたは割り当て済みのイシューに対して、完了および再開が可能です。
3. ゲストユーザーは、作成したイシューまたは割り当て済みのイシューに対して、アーカイブおよび再開が可能です。
4. ゲストユーザーは、作成したイシューまたは割り当て済みのイシューのタイトルと説明を変更できます。
5. プランナーまたはオーナーロールを持たないユーザーは、自身が作成したイシューのみを削除できます。
6. プランナーロールを持つユーザーは、マイルストーンまたは機密イシューに対するコメントの高度な検索を使用できません。詳細については、エピック17674を参照してください。

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

脚注:

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

OKRのプロジェクト権限:

Wikiのプロジェクト権限:

プロジェクトリポジトリ

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

脚注:

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

プロジェクトユーザー管理

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

脚注:

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

サブグループの権限

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

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

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

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

• トップレベルグループのプロジェクトおよびサブグループに自動的にアクセスできる。オーナーは、これらのユーザーを特定のサブグループおよびプロジェクトに明示的に追加する必要があります。
• ユーザーがインスタンスまたはGitLab.comのネームスペースで他のロールを持たない場合、ライセンスシートとしてカウントされます。

最小アクセスロールを持つユーザーが、いずれかのプロジェクトまたはサブグループで請求対象ロールを付与された場合、そのユーザーは最高のロールに基づいてライセンスシートを消費します。

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

1. 上部のバーで、検索または移動先を選択して、グループを見つけます。
2. 設定 > SAML SSOを選択します。
3. デフォルトのメンバーシップロールドロップダウンリストから、最小アクセスを選択します。
4. 変更を保存を選択します。

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

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

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

この問題を回避するには、これらのユーザーにゲスト、プランナー、レポーター、デベロッパー、メンテナー、またはオーナーロールを親グループ内の任意のプロジェクトまたはサブグループに付与します。ゲストユーザーは、Premiumプランではライセンスシートを消費しますが、Ultimateプランでは消費しません。

関連トピック

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