• ロール
• プロジェクトメンバーの権限
• プロジェクト機能の権限
  • GitLab CI/CD の権限
    • ジョブ権限
• グループメンバーの権限
  • サブグループの権限
• 最小限のアクセスしかできないユーザー
• 関連するトピック
• カスタム・ロール
  • カスタムロールの作成
    • カスタムロールの要件
  • 既存のグループメンバーにカスタムロールを関連付けます。
  • グループメンバーからのカスタムロールの削除
  • カスタムロールの削除
  • 既知のイシュー

権限とロール

プロジェクトやグループにユーザーを追加すると、そのユーザーにロールが割り当てられます。ロールによって、GitLabでどのアクションができるかが決まります。

ユーザーをプロジェクトのグループとプロジェクトの両方に追加した場合は、上位のロールが使われます。

GitLab管理者は全ての権限を持ちます。

ロール

利用可能なロールは以下の通りです：

• ゲスト（このロールは非公開プロジェクトおよび内部プロジェクトにのみ適用されます。）
• レポーター
• 開発者
• メンテナー
• オーナー
• 最小アクセス (最上位グループのみ)

Guestロールを割り当てられたユーザーは最小限の権限を持ち、オーナーは最大の権限を持ちます。

デフォルトでは、全てのユーザーがトップレベルのグループを作成し、ユーザー名を変更することができます。GitLab管理者はGitLabインスタンスに対してこの動作を変更することができます。

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

• GitLab 14.8で導入され、個人の名前空間のオーナーは、その名前空間の新しいプロジェクトでOwnerロールで表示されます。personal_project_owner_with_owner_accessというフラグで導入されました。デフォルトでは無効になっています。
• GitLab 14.9で一般的に利用可能に。機能フラグpersonal_project_owner_with_owner_access を削除しました。

ユーザーのロールによって、プロジェクトに対する権限が決まります。オーナーロールはすべての権限を提供しますが、プロジェクトでのみ利用可能です：

• グループとプロジェクトのオーナー。GitLab 14.8以前では、ロールはグループのプロジェクトに継承されます。
• 管理者の場合。

個人ネームスペースのオーナー：

• 名前空間内のプロジェクトでメンテナーのロールを持つものとして表示されますが、Owner ロールを持つユーザーと同じ権限を持ちます。
• GitLab 14.9以降では、ネームスペース内の新規プロジェクトでは、オーナーロールを持つものとして表示されます。

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

以下の表は、各ロールで利用可能なプロジェクト権限の一覧です：

1. セルフマネジメントの GitLab インスタンスでは、Guest ロールを持つユーザーは公開プロジェクトと内部プロジェクトでのみこのアクションを実行できます (非公開プロジェクトではできません)。プロジェクトが内部であっても、外部ユーザーには明示的なアクセス権（少なくともレポーターロール）を与える必要があります。GitLab.comでGuestロールを持つユーザーは、内部可視性が利用できないため、公開プロジェクトでのみこのアクションを実行できます。
2. ゲストユーザーは、自分で作成した、または割り当てられた機密イシューのみを閲覧することができます。
3. ゲスト、レポーター、開発者、メンテナー、オーナーには許可されません。保護されたブランチを参照してください。
4. ブランチが保護されている場合は、開発者やメンテナーに与えられているアクセス権に依存します。
5. ゲストユーザーは GitLab にアクセスできます。 リリースにアクセスしてアセットをダウンロードできますが、ソースコードをダウンロードしたり、コミットやリリースの証拠などのリポジトリ情報を見ることはできません。
6. アクションはユーザーが所有（参照）しているレコードのみに制限されます。
7. 共有グループロックが有効な場合、プロジェクトを他のグループと共有することはできません。グループ共有のグループには影響しません。
8. マージリクエストの承認者については、承認者を参照してください。
9. Design Managementデザインに対するコメントのみに適用されます。
10. ユーザーは各自のアクションに基づくイベントのみを表示できます。
11. プロジェクトアクセストークンは、Free以上のセルフマネージドインスタンスでサポートされています。GitLab SaaS Premium以上（トライアルライセンスを除く）でもサポートされています。
12. タグが保護されている場合、これは開発者とメンテナーに与えられたアクセス権に依存します。
13. プロジェクトの可視性が非公開に設定されている場合、メンテナーやオーナーはプロジェクト機能の可視性レベルを変更できません。
14. ユーザーが開発者ロールを持っていなくても、添付されたデザインファイルがイシューと一緒に移動されます。
15. ゲストユーザーは、課題の作成時にのみメタデータ（ラベル、担当者、マイルストーンなど）を設定できます。既存のイシューのメタデータを変更することはできません。
16. 外部メンバーからの貢献を受け入れるプロジェクトでは、ユーザーは自分自身のマージリクエストを作成、編集、クローズすることができます。
17. 作成者と担当者は、レポーターロールを持っていなくても、タイトルと説明を修正できます。
18. 作成者と担当者は、レポーターのロールを持っていなくても、イシューをクローズしたり、再開することができます。
19. コンテナレジストリの表示とイメージのプル機能は、コンテナレジストリの表示権限によって制御されます。
20. メンテナーは、オーナーを作成、降格、削除することはできず、ユーザーをオーナーのロールに昇格させることもできません。また、Ownerロールのアクセス要求を承認することもできません。
21. タスクの作成者はオーナーロールを持っていなくてもタスクを削除できますが、少なくともプロジェクトのゲストロールを持っている必要があります。
22. エピックの閲覧権限が必要です。
23. GitLab 15.9以降では、GuestロールとUltimateライセンスを持つユーザーは、管理者（セルフマネージド上）またはグループオーナー（GitLab.com上）がそれらのユーザーに権限を与えた場合、非公開リポジトリのコンテンツを閲覧することができます。管理者またはグループオーナーは、APIを通じてカスタムロールを作成し、そのロールをユーザーに割り当てることができます。

プロジェクト機能の権限

プロジェクトレベルの機能の権限についての詳細は以下の通りです。

GitLab CI/CD の権限

一部のロールに対するGitLab CI/CD権限は、これらの設定によって変更することができます：

• 公開パイプライン：公開パイプライン: 公開に設定すると、特定の CI/CD 機能へのアクセスをゲストプロジェクトメンバーに与えます。
• パイプラインの可視化：Everyone with Accessに設定すると、プロジェクトメンバー以外でもCI/CDの特定の機能にアクセスできるようになります。

1. プロジェクトが公開されていて、プロジェクト設定 > CI/CDでパブリックパイプラインが有効になっている場合。
2. プロジェクト設定 > CI/CDで公開パイプラインが有効になっている場合。
3. プロジェクトが公開されている場合。
4. ジョブが両方あった場合のみ：
   • ユーザーによってトリガーされました。
   • GitLab 13.0以降では、保護されていないブランチに対して実行。
5. ユーザーが保護ブランチへのマージやプッシュを許可されている場合。
6. ユーザーが少なくともレポーターロールを持つグループに属している場合。

ジョブ権限

この表は、特定のタイプのユーザーによってトリガーされたジョブに付与された権限を示しています：

1. トリガーユーザーが外部でない場合のみ。
2. トリガーユーザーがプロジェクトのメンバーである場合のみ。プルポリシーによる非公開Dockerイメージの利用if-not-presentも参照してください。

グループメンバーの権限

グループの最後のオーナーでない限り、どのユーザーでもグループから自分を削除することができます。

次の表は、各ロールで利用可能なグループ権限の一覧です：

1. グループは、オーナー、またはオーナーとメンテナーのロールを持つユーザーがサブグループを作成できるように設定できます。
2. デフォルトのプロジェクト作成ロールは以下で変更できます：
   • インスタンス・レベル。
   • グループ・レベル。
3. サブグループには適用されません。
4. 開発者が新しいプロジェクトのデフォルトブランチにコミットをプッシュできるのは、デフォルトブランチの保護が“Partially protected” あるいは “Not protected” に設定されている場合だけです。
5. さらに、グループが公開または内部の場合、グループを見ることができるすべてのユーザーはグループの Wiki ページも見ることができます。
6. ユーザーは各自のアクションに基づくイベントのみを表示できます。
7. エピックの閲覧およびイシューの編集には権限が必要です。
8. 親エピックおよび子エピックを表示する権限が必要です。

サブグループの権限

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

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

最小限のアクセスしかできないユーザー

• GitLab 13.4 で導入されました。
• GitLab 15.9 で導入されたMinimal Access ロールを持つユーザーの招待をサポート。

Minimal Access ロールを持つユーザーは招待できません：

• セルフマネージドUltimateサブスクリプションやGitLab.comサブスクリプションのライセンスシートとしてカウントされません。
• ルートグループ内のプロジェクトやサブグループに自動的にアクセスできます。

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

Minimal Accessロールを使用して、同じメンバーにグループ内で複数のロールを与えることができます：

1. 最小アクセス・ロールを持つルート・グループにメンバーを追加します。
2. グループ内の任意のサブグループまたはプロジェクトに、特定のロールを持つ直接メンバとしてメンバを招待します。

未解決のイシューがあるため、Minimal Accessロールを持つユーザーを招待することはできません：

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

このイシューを回避するには、これらのユーザーに、親グループ内のプロジェクトまたはサブグループのゲスト以上のロールを与えます。

関連するトピック

• 権限の背後にあるGitLabの原則
• メンバー
• 保護ブランチの権限のカスタマイズ
• LDAP ユーザー権限
• 価値ストリーム分析権限
• プロジェクトのエイリアス
• 監査役ユーザー
• 機密に関するイシュー
• コンテナレジストリ権限
• リリース権限
• 読み取り専用の名前空間

カスタム・ロール

• GitLab 15.7でcustomizable_roles というフラグで導入されました。
• GitLab 15.9ではデフォルトで有効。
• GitLab 15.10で機能フラグが削除されました。
• GitLab 16.1でcustom_roles_vulnerability というフラグで 導入された、カスタムロールが脆弱性レポーターを閲覧する機能。
• GitLab 16.1でデフォルトで有効になった脆弱性レポートの閲覧機能。
• GitLab 16.2で機能フラグcustom_roles_vulnerability を削除しました。

カスタムロールにより、オーナーロールを割り当てられたグループメンバーは、組織のニーズに合わせたロールを作成することができます。

カスタムロール機能のデモについては、[Demo] Ultimate Guest can view code on private repositories via custom roleを参照してください。

以下のカスタムロールが利用できます：

• Guest+1ロールは、Guestロールを持つユーザーにコードの閲覧を許可します。
• GitLab 16.1以降では、脆弱性レポートを閲覧し、脆弱性のステータスを変更できるカスタムロールを作成できます。
• GitLab 16.3以降では、依存性リストを閲覧できるカスタムロールを作成できます。
• GitLab 16.4 以降では、マージリクエストを承認できるカスタムロールを作成できます。

個々のカスタムロールと権限リクエストについては、イシュー391760 を参照してください。

ゲスト・ロールを持つユーザに対して脆弱性カスタム・ロールを有効にすると、そのユーザは昇格された権限にアクセスできるようになります：

• 自己管理GitLabの課金ユーザーとみなされます。
• GitLab.comのシートを使用。

これはGuest+1カスタムロールには適用されません。なぜなら、view_code の能力はこの動作から除外されているからです。

カスタムロールの作成

グループのカスタムロールを有効にするには、オーナーロールを持つグループメンバーが必要です：

1. Guestにカスタムロールを与えた効果を確認できるように、このグループまたはそのサブグループの1つに、少なくとも1つの非公開プロジェクトがあることを確認してください。
2. APIスコープで個人アクセストークンを作成します。
3. APIを使用してルートグループのカスタムロールを作成します。

カスタムロールの要件

すべての能力について、最小アクセスレベルが定義されています。特定の能力を有効にするカスタム・ロールを作成するには、member_roles テーブル・レコードが関連する最小アクセス・レベルを持っている必要があります。すべての能力について、最小アクセス・レベルはGuestです。少なくともGuestロールを持つユーザだけがカスタム・ロールに割り当てられます。

一部のロールおよび能力では、他の能力を有効にする必要があります。たとえば、カスタム・ロールが脆弱性の管理 (admin_vulnerability) を有効にできるのは、脆弱性の読み取り (read_vulnerability) も有効になっている場合のみです。

必要な最小アクセス・レベルと必要な能力は、以下の表で確認できます。

既存のグループメンバーにカスタムロールを関連付けます。

カスタムロールを既存のグループメンバーに関連付けるには、オーナーロールを持つグループメンバーを指定します：

1. ルートグループ、またはルートグループの階層内の任意のサブグループやプロジェクトに、直接のメンバーとしてユーザーをゲストとして招待します。この時点で、このゲストユーザーは、グループまたはサブグループ内のプロジェクトのコードを見ることはできません。

2. オプション。オーナーがID カスタム・ロールを受け取るゲスト・ユーザーを ID知らない場合ID 、 ID APIリクエストを行うことでID それを見つけます ID。

3. Group and Project Members APIエンドポイントを使用して、メンバーをGuest+1ロールに関連付けます。

   # to update a project membership
   curl --request PUT --header "Content-Type: application/json" --header "Authorization: Bearer $YOUR_ACCESS_TOKEN" --data '{"member_role_id": '$MEMBER_ROLE_ID', "access_level": 10}' "https://example.gitlab.com/api/v4/projects/$ID/members/$GUEST_USER_ID"
      
   # to update a group membership
   curl --request PUT --header "Content-Type: application/json" --header "Authorization: Bearer $YOUR_ACCESS_TOKEN" --data '{"member_role_id": '$MEMBER_ROLE_ID', "access_level": 10}' "https://example.gitlab.com/api/v4/groups/$ID/members/$GUEST_USER_ID"
   

   どこに：

   • $ID:カスタムロールを受け取るメンバーシップに関連付けられたプロジェクトまたはグループの ID またはURL エンコードされたパス。
   • $MEMBER_ROLE_ID:前のセクションで作成したメンバー・ロールのID 。
   • $GUEST_USER_ID:カスタム・ロールを受け取るゲスト・ユーザーのID 。

   これで、Guest+1ユーザーは、このメンバーシップに関連付けられたすべてのプロジェクトのコードを閲覧できるようになります。

グループメンバーからのカスタムロールの削除

グループ・メンバーからカスタム・ロールを削除するには、Group and Project Members APIエンドポイントを使用し、空のmember_role_id 値を渡します。

curl --request PUT --header "Content-Type: application/json" --header "Authorization: Bearer $YOUR_ACCESS_TOKEN" --data '{"member_role_id": "", "access_level": 10}' "https://example.gitlab.com/api/v4/groups/$GROUP_PATH/members/$GUEST_USER_ID"

これでユーザーは通常のゲストとなります。

カスタムロールの削除

カスタムロールを削除すると、そのカスタムロールを持つすべてのメンバーもグループから削除されます。カスタムロールを削除する場合は、そのカスタムロールを持つユーザをグループに追加し直す必要があります。

グループからカスタムロールを削除するには、オーナーロールを持つグループメンバーをグループから削除します：

1. オプション。オーナーがID カスタムロールを ID知らない場合は、APIリクエストで確認してください。
2. APIを使用してカスタムロールを削除します。

既知のイシュー

• 追加権限は、ゲストロールを持つユーザーにのみ適用できます。
• カスタムロールを持つユーザーがグループやプロジェクトと共有された場合、そのカスタムロールは引き継がれません。ユーザーは新しいグループまたはプロジェクトで通常のGuestロールを持ちます。
• 監査役ユーザをカスタムロールのテンプレートとして使用することはできません。