ロールと権限

ロールは、グループまたはプロジェクトにおけるユーザーのパーミッションを定義します。

管理者アクセスを持つユーザーは、すべてのパーミッションを持ち、あらゆるアクションを実行できます。

ロール

ユーザーをグループまたはプロジェクトに追加すると、そのユーザーにロールを割り当てます。ロールによって、そのユーザーのパーミッションが決定されます。デフォルトロールまたはカスタムロールのいずれかを割り当てます。

ユーザーは、グループおよびプロジェクトごとに異なるロールを持つことができます。ユーザーは常に、その最高のロールに対するパーミッションを保持します。たとえば、ユーザーが以下を持っている場合:

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

ユーザーは、プロジェクト内でそのメンテナーロールのパーミッションを継承します。

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

デフォルトロール

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

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

グループパーミッション

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

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

グループ

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

補足説明:

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でデベロッパーロールから削除されました。
2. セキュリティマネージャーは、UI（セキュリティ > セキュリティ設定）経由でのみセキュリティ設定を管理できます。

プロジェクト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. 手動で実行する場合、パイプラインは、スケジュールの所有権を持つユーザーのパーミッションではなく、トリガーしているユーザーのパーミッションで実行されます。
14. セキュリティマネージャーは、DASTオンデマンドスキャンパイプラインのみ実行できます。

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

プロジェクトオーナーはリストされているアクションを実行できますが、ソースと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ユーザー権限
• バリューストリーム分析の権限
• プロジェクトエイリアス
• 監査担当者ユーザー
• 非公開イシュー
• コンテナレジストリの権限
• リリース権限
• 読み取り専用ネームスペース