グループアクセスと権限

グループを構成して、グループの権限とアクセスを制御します。詳細については、プロジェクトとグループの共有も参照してください。

Gitアクセスプロトコルを制限する

グループのリポジトリへのアクセスに使用できるプロトコルを、SSH、HTTPS、またはその両方に設定できます。この設定は、管理者がインスタンスの設定を構成すると無効になります。

グループの許可されたGitアクセスプロトコルを変更するには、次の手順に従います。

1. 上部のバーで、検索または移動先を選択して、グループを見つけます。
2. 設定 > 一般を選択します。
3. 権限とグループ機能セクションを展開します。
4. 有効なGitアクセスプロトコルから許可されたプロトコルを選択します。
5. 変更を保存を選択します。

IPアドレスでグループアクセスを制限する

組織のユーザーのみが特定のリソースにアクセスできるようにするために、IPアドレスでグループへのアクセスを制限できます。このトップレベルグループ設定は、以下に適用されます。

• サブグループ、プロジェクト、イシューを含むGitLab UI。GitLab Pagesには適用されません。
• API。
• GitLab Self-Managedでは、グループに対してグローバルに許可されるIPアドレス範囲を設定することもできます。

管理者は、IPアドレスによる制限されたアクセスをグローバルに許可されるIPアドレスと組み合わせることができます。

proxy_set_header X-Forwarded-For $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

IPアドレスでグループアクセスを制限するには、次の手順に従います。

1. 上部のバーで、検索または移動先を選択して、グループを見つけます。

2. 設定 > 一般を選択します。

3. 権限とグループ機能セクションを展開します。

4. IPアドレスによるアクセス制限テキストボックスに、CIDR表記のIPv4またはIPv6アドレス範囲のリストを入力します:

   192.168.1.0/24
   10.0.0.0/8
   2001:db8::/32
   203.0.113.5/32

   各IPアドレスエントリを手動で追加する必要があります。コンマまたはスペースで区切られた複数のエントリの追加はサポートされていません。一括エントリのサポートは、issue 468998で提案されています。

   このリストの仕様は次のとおりです:

   • IPアドレス範囲の数に制限はありません。
   • SSHまたはHTTPの承認されたIPアドレス範囲の両方に適用されます。認可の種類でこのリストを分割することはできません。

5. 変更を保存を選択します。

セキュリティ上の注意点

IPアクセス制限はグループやプロジェクトへのアクセスを制限しますが、完全なファイアウォールではありません。この機能は一般的にグループやプロジェクトのリソースへのアクセスを制限しますが、一部の情報は制限されたユーザーからも引き続きアクセスできる場合があります。許可されていないIPアドレスからGitLabにアクセスする場合の、以下の（網羅的ではない）セキュリティ上の影響のリストを念頭に置いてください:

• 管理者とグループオーナーは、常にグループ設定にアクセスできます。
• 管理者は、常にグループ内のプロジェクトにアクセスできます。これには、コードのクローン作成が含まれます。
• グループオーナーは常にサブグループにアクセスできますが、グループ内またはサブグループ内のプロジェクトにはアクセスできません。
• ユーザーは常に共有リソースにアクセスできます。
• ユーザーは常にグループとプロジェクトの名前および階層を表示できます。
• ユーザーは常にメールで返信機能を使用して、イシューやマージリクエストのコメントを作成および編集できます。
• ユーザーは、プッシュ、マージ、イシュー、またはコメントイベントをダッシュボードで表示できる場合があります。
• IP制限は常に公開プロジェクトに適用されますが、キャッシュされたプロジェクトファイルにアクセスできる場合があります。
• IP制限は、GitLab.comおよびGitLab DedicatedでのSSHを介したGit操作に常に適用されます。GitLab Self-Managedインスタンスは、PROXY protocolが有効になっているgitlab-sshdを使用する必要があります。
• IP制限は、CI/CDジョブによって実行されるGitクローン操作に常に適用されます。
• IP制限はRunnerの登録、またはRunnerがCI/CDジョブをリクエストまたは更新する場合には適用されません。
• IP制限は、フォークしたプロジェクト、またはIP制限されたグループ内のイシューやアーティファクトと間接的にやり取りするアクションには適用されない場合があります。たとえば、マージリクエストの説明でイシューの参照を使用して、IP制限されたグループのイシューを閉じるマージリクエストなどです。

GitLab.comのアクセス制限

IPアドレスに基づくグループアクセス制限は、GitLab.comのホストRunnerでは機能しません。これらのRunnerは、大規模なクラウドプロバイダープール（AWS、Google Cloud）からの動的IPアドレスを持つ一時的な仮想マシンとして動作します。これらの広いIP範囲を許可すると、IPアドレスベースのアクセス制限の目的が損なわれます。

ドメインでグループアクセスを制限する

トップレベルのネームスペースでEメールのドメイン許可リストを定義することで、グループとそのプロジェクトにアクセスできるユーザーを制限できます。ユーザーのプライマリEメールのドメインが、そのグループにアクセスするために許可リストのエントリと一致している必要があります。サブグループは同じ許可リストを継承します。

ドメインによるグループアクセスを制限するには、次の手順に従います。

1. 上部のバーで、検索または移動先を選択して、グループを見つけます。
2. 設定 > 一般を選択します。
3. 権限とグループ機能セクションを展開します。
4. メールのドメインでメンバーシップを制限するテキストボックスに、許可するドメイン名を入力します。
5. 変更を保存を選択します。

次回グループにユーザーを追加しようとする際は、そのプライマリEメールが許可されたドメインの1つと一致している必要があります。

次のような最も一般的な公開メールドメインの使用は制限できません:

• aol.com、gmail.com、hotmail.co.uk、hotmail.com、
• hotmail.fr、icloud.com、live.com、mail.com、
• me.com、msn.com、outlook.com、
• proton.me、protonmail.com、tutanota.com、
• yahoo.com、yandex.com、zohomail.com

グループを共有する場合、ソースとターゲットの両方のネームスペースで、メンバーのEメールアドレスのドメインを許可する必要があります。

ユーザーがグループへのアクセスをリクエストできないようにする

グループオーナーは、メンバー以外のユーザーからのグループへのアクセスをリクエストできないようにすることができます。

1. 上部のバーで、検索または移動先を選択して、グループを見つけます。
2. 設定 > 一般を選択します。
3. 権限とグループ機能セクションを展開します。
4. Allow users to request accessチェックボックスをオフにします。
5. 変更を保存を選択します。

現在のグループ外へプロジェクトがフォークするのを防止

デフォルトでは、グループ内のプロジェクトはフォークできます。ただし、現在のトップレベルグループの外部にグループ内のプロジェクトがフォークされるのを防ぐこともできます。

前提条件:

• この設定は、トップレベルグループでのみ有効になります。
• すべてのサブグループは、トップレベルグループからこの設定を継承し、サブグループレベルで変更することはできません。

プロジェクトがグループ外にフォークされるのを防ぐには、次の手順に従います。

1. 上部のバーで、検索または移動先を選択して、グループを見つけます。
2. 設定 > 一般を選択します。
3. 権限とグループ機能セクションを展開します。
4. 現在のグループ外へプロジェクトがフォークするのを防止をオンにします。
5. 変更を保存を選択します。

既存のフォークは削除されません。

グループ内のプロジェクトへのメンバーの追加を防止する

グループオーナーは、グループ内のすべてのプロジェクトでプロジェクトメンバーシップの新規追加を停止できます。そうすることで、プロジェクトメンバーシップをより厳密に制御できるようになります。

たとえば、監査イベントがあることからグループをロックする場合、監査中にプロジェクトメンバーシップを確実に変更できないようにすることができます。

グループメンバーシップロックが有効になっている場合でも、グループオーナーは次のことができます。

• グループを招待するか、メンバーをグループに追加して、ロックされたグループのプロジェクトへのアクセス権を付与します。
• グループメンバーのロールを変更します。

設定はカスケードされません。サブグループ内のプロジェクトは、親グループを無視して、サブグループの構成を監視します。

グループ内のプロジェクトにメンバーが追加されないようにするには、次の手順に従います。

1. 上部のバーで、検索または移動先を選択して、グループを見つけます。
2. 設定 > 一般を選択します。
3. 権限とグループ機能セクションを展開します。
4. メンバーシップで、このグループのプロジェクトにユーザーを追加することはできませんを選択します。
5. 変更を保存を選択します。

グループのメンバーシップをロックした後は、以下の通りとなります。

• 以前に権限を持っていたすべてのユーザーは、グループにメンバーを追加できなくなります。
• プロジェクトに新しいユーザーを追加するAPIリクエストができなくなります。

LDAPでグループメンバーシップを管理する

グループの同期により、LDAPグループをGitLabグループにマッピングできます。これにより、グループごとのユーザー管理をより細かく制御できます。グループの同期を設定するには、group_base DN（'OU=Global Groups,OU=GitLab INT,DC=GitLab,DC=org'）を編集します。このOUには、GitLabグループに関連付けられているすべてのグループが含まれています。

グループリンクは、CNまたはフィルターのいずれかを使用して作成できます。これらのグループリンクを作成するには、グループの設定 > LDAP同期ページに移動します。リンクを設定した後、ユーザーがGitLabグループと同期されるまでに1時間以上かかる場合があります。リンクを設定した後は、以下の通りとなります。

• GitLab 16.7以前では、グループオーナーはグループのメンバーを追加または削除できません。LDAPサーバーは、LDAP認証情報でサインインしたすべてのユーザーのグループメンバーシップの信頼できる唯一の情報源と見なされます。
• GitLab 16.8以降では、グループオーナーはメンバーロールAPIまたはグループメンバーAPIを使用して、サービスアカウントユーザーをグループに追加したり、グループからサービスアカウントユーザーを削除したりできます。これは、グループに対してLDAP同期が有効になっている場合でも可能です。グループオーナーは、サービスアカウント以外のユーザーを追加または削除できません。

ユーザーが同じGitLabグループ用に構成された2つのLDAPグループに属している場合、GitLabは2つの関連ロールのうち、高い方のロールをユーザーに割り当てます。例:

• ユーザーは、LDAPグループOwnerとDevのメンバーです。
• GitLabグループは、これら2つのLDAPグループで構成されています。
• グループの同期が完了すると、ユーザーにはオーナーロールが付与されます。これは、2つのLDAPグループロールのうち高い方のロールであるためです。

LDAPおよびグループの同期の管理の詳細については、メインのLDAPドキュメントを参照してください。

LDAPグループを介してプロジェクトアクセスを管理するための回避策を使用できます。

CNでグループリンクを作成する

LDAPグループCNでグループリンクを作成するには、次の手順に従います。

1. リンクのLDAPサーバーを選択します。
2. 同期方法で、LDAP Group cnを選択します。
3. LDAP Group cnフィールドに、グループのCNの入力を開始します。設定されたgroup_baseに、一致するCNを持つドロップダウンリストがあります。このリストからCNを選択します。
4. LDAP Accessセクションで、このグループで同期されたユーザーのデフォルトロールまたはカスタムロールを選択します。
5. 同期を追加を選択します。

フィルターでグループリンクを作成する

LDAPユーザーフィルターでグループリンクを作成するには、次の手順に従います。

1. リンクのLDAPサーバーを選択します。
2. 同期方法で、LDAP user filterを選択します。
3. LDAP User filterボックスにフィルターを入力します。ユーザーフィルターに関するドキュメントの手順に従います。
4. LDAP Accessセクションで、このグループで同期されたユーザーのデフォルトロールまたはカスタムロールを選択します。
5. 同期を追加を選択します。

グループリンクの削除

1. 上部のバーで、検索または移動先を選択して、グループを見つけます。
2. 設定 > Active synchronizationを選択します。
3. 削除するグループリンクを特定し、削除（削除）を選択します。

ユーザー権限をオーバーライドする

LDAPユーザー権限は、管理者が手動でオーバーライドできます。ユーザーの権限をオーバーライドするには、次の手順に従います。

1. 上部のバーで、検索または移動先を選択して、グループを見つけます。
2. 管理 > メンバーを選択します。LDAP同期によって、
   • 親グループメンバーシップよりも多くの権限を持つロールがユーザーに付与された場合、そのユーザーはグループのダイレクトメンバーシップを持っていると表示されます。
   • 親グループメンバーシップと同じかそれ以下の権限を持つロールがユーザーに付与された場合、そのユーザーはグループの継承されたメンバーシップを持っていると表示されます。
3. オプション。編集するユーザーが継承されたメンバーシップを持っていると表示される場合は、LDAPユーザー権限をオーバーライドする前に、サブグループをフィルタリングしてダイレクトメンバーを表示します。
4. 編集するユーザーの行で、鉛筆( ) アイコンを選択します。
5. ダイアログで権限を編集するを選択します。

これで、メンバーページからユーザーの権限を編集できるようになります。

パイプライン変数を使用できるデフォルトロールを設定する

このグループ設定は、プロジェクト設定であるパイプライン変数を伴う新しいパイプラインの実行を許可された最小限のロールのデフォルトの値を制御します。グループで作成された新しいプロジェクトには、デフォルトでこの値が選択されています。

前提条件:

• グループ内でメンテナーまたはオーナーロールを持っている必要があります。
• グループはトップレベルグループである必要があり、サブグループであってはなりません。

デフォルトの最小ロールを設定するには:

1. 上部のバーで、検索または移動先を選択して、グループを見つけます。
2. 設定 > CI/CD > 変数を選択します。
3. パイプライン変数を使えるデフォルトロールで最小ロールを選択するか、誰にも許可しないを選択して、ユーザーがパイプライン変数を使用できないようにします。
4. 変更を保存を選択します。

新しいプロジェクトが作成された後、メンテナーまたはオーナーロールを持つプロジェクトメンバーは、必要に応じてプロジェクトの設定を別の値に変更できます。

トラブルシューティング

IP制限によってアクセスがブロックされているかどうかを確認する

特定のグループへのアクセスを試みたときに、ユーザーに404エラーが表示される場合、そのアクセスはIP制限によってブロックされている可能性があります。

auth.logレールログで、次のエントリの1つ以上を検索します。

• json.message: 'Attempting to access IP restricted group'
• json.allowed: false

ログエントリを表示する際に、remote.ipを、グループの許可されたIPアドレスのリストと比較してください。

グループメンバーの権限を更新できない

グループのオーナーがグループメンバーの権限を更新できない場合は、リストされているメンバーシップを確認してください。グループのオーナーは、ダイレクトメンバーシップのみを更新できます。

サブグループに直接追加されたメンバーは、親グループで同じロールまたはより高いロールを持っている場合、継承されたメンバーと見なされます。

ダイレクトメンバーシップを表示および更新するには、グループをフィルタリングしてダイレクトメンバーを表示します。

イシュー337539は、タイプ別にフィルタリングする機能を備えたダイレクトメンバーシップと間接メンバーシップの両方をリストする、再設計されたメンバーページを提案しています。

IP制限を有効にした後、SSHを使用してクローンまたはプルができない

IPアドレス制限を追加した後、Git SSHオペレーションでイシューが発生する場合は、接続がIPv6にデフォルト設定されているかどうかを確認してください。

一部のオペレーティングシステムでは、IPv6とIPv4の両方が利用可能な場合、IPv6がIPv4よりも優先されます（Gitターミナルのフィードバックからだと明確に表示されない可能性があります）。

接続でIPv6を使用している場合は、IPv6アドレスを許可リストに追加することで、このイシューを解決できます。