正式なドキュメントは英語版であり、この日本語訳はAI支援翻訳により作成された参考用のものです。日本語訳の一部の内容は人間によるレビューがまだ行われていないため、翻訳のタイミングにより英語版との間に差異が生じることがあります。最新かつ正確な情報については、英語版をご参照ください。

グループアクセスと権限

  • プラン: Free、Premium、Ultimate
  • 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated

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

グループプッシュルール

  • プラン: Premium、Ultimate
  • 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated

グループプッシュルールを使用すると、グループメンテナーは、特定のグループで新しく作成されたプロジェクトのプッシュルールを設定できます。

グループのプッシュルールを設定するには:

  1. 左側のサイドバーで、検索または移動先を選択して、グループを見つけます。新しいナビゲーションをオンにした場合、このフィールドは上部のバーに表示されます。
  2. 設定 > リポジトリを選択します。
  3. 事前定義されたプッシュルールセクションを展開します。
  4. 必要な設定を選択します。
  5. プッシュルールを保存を選択します。

新しいプロジェクトは、プッシュルールを以下から継承します:

  • プッシュルールが定義された最も近い親グループ。
  • プッシュルールが定義された親グループがない場合は、インスタンス全体に設定されたプッシュルール。

プロジェクトのみがプッシュルールを継承します。サブグループは、親グループからプッシュルールを継承しません。どのプッシュルールが新しいプロジェクトに適用されるかを確認するには、サブグループにプロジェクトを作成し、プロジェクトのプッシュルールを確認します。

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

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

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

  1. 左側のサイドバーで、検索または移動先を選択して、グループを見つけます。新しいナビゲーションをオンにした場合、このフィールドは上部のバーに表示されます。
  2. 設定 > 一般を選択します。
  3. 権限とグループ機能セクションを展開します。
  4. 有効なGitアクセスプロトコルから許可されたプロトコルを選択します。
  5. 変更を保存を選択します。

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

  • プラン: Premium、Ultimate
  • 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated

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

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

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

IP制限には、X-Forwarded-Forヘッダーの適切な設定が必要です。IPスプーフィングのリスクを制限するには、クライアントから送信されたX-Forwarded-Forヘッダーを上書きする必要があります(追加してはいけません)。

アップストリームプロキシまたはロードバランサーなしでデプロイする場合は、ユーザーからの直接リクエストを受信するサーバーを構成して、元のクライアントIPアドレスを保持し、X-Forwarded-Forヘッダーを上書きします。たとえば、NGINXでは、設定ファイルを修正して以下を含めます:

proxy_set_header X-Forwarded-For $remote_addr;

アップストリームプロキシまたはロードバランサーを使用してデプロイする場合は、プロキシまたはロードバランサーを構成して、元のクライアントIPアドレスを保持し、X-Forwarded-Forヘッダーを上書きします。このアプローチにより、GitLabは、元のクライアントから始まるIPの完全なチェーンを受信し、IP制限を正しく評価できます。たとえば、NGINXでは、設定ファイルを修正して以下を含めます:

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

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

  1. 左側のサイドバーで、検索または移動先を選択して、グループを見つけます。新しいナビゲーションをオンにした場合、このフィールドは上部のバーに表示されます。
  2. 設定 > 一般を選択します。
  3. 権限とグループ機能セクションを展開します。
  4. IPアドレスによるアクセス制限テキストボックスに、IPv4またはIPv6アドレス範囲のリストをCIDR表記で入力します。このリストでは、:
    • IPアドレス範囲の数に制限はありません。
    • SSHまたはHTTPの承認されたIPアドレス範囲の両方に適用されます。承認の種類でこのリストを分割することはできません。
  5. 変更を保存を選択します。

セキュリティ上の注意点

IPアクセス制限はグループとプロジェクトへのアクセスを制限しますが、完全なファイアウォールではありません。この機能は通常、グループとプロジェクトのリソースへのアクセスを制限しますが、制限されたユーザーは一部の情報にアクセスできる場合があります。許可されていないIPアドレスからGitLabにアクセスする場合、以下のセキュリティ上の注意点(網羅的ではありません)に留意してください:

  • 管理者とグループオーナーは、常にグループ設定にアクセスできます。
  • 管理者は、常にグループ内のプロジェクトにアクセスできます。これには、コードのクローン作成が含まれます。
  • グループオーナーは、常にサブグループにアクセスできますが、グループまたはサブグループ内のプロジェクトにはアクセスできません。
  • ユーザーは常に共有リソースにアクセスできます。
  • ユーザーは常にグループとプロジェクトの名前と階層を表示できます。
  • ユーザーは常にメールによる返信機能を使用して、イシューまたはマージリクエストに関するコメントを作成および編集できます。
  • ユーザーは、ダッシュボード上でプッシュ、マージ、イシュー、またはコメントイベントを表示できる場合があります。
  • IP制限は常にパブリックプロジェクトに適用されますが、キャッシュされたプロジェクトファイルにアクセスできる場合があります。
  • IP制限は、GitLab.comおよびGitLab Dedicated上のSSHを介したGit操作に常に適用されます。GitLab自己管理インスタンスは、gitlab-sshdを有効にしたPROXYプロトコルを使用する必要があります。
  • 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アドレスに基づくアクセス制限の目的が損なわれます。

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

  • プラン: Premium、Ultimate
  • 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated

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

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

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

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

次のような最も一般的なパブリックEメールのドメインの場合、制限することはできません:

  • aol.comgmail.comhotmail.co.ukhotmail.com
  • hotmail.fricloud.comlive.commail.com
  • me.commsn.comoutlook.com
  • proton.meprotonmail.comtutanota.com
  • yahoo.comyandex.comzohomail.com

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

メールのドメインでメンバーシップを制限するリストからドメインを削除しても、そのドメインを持つ既存のユーザーがグループまたはそのプロジェクトから削除されることはありません。また、グループまたはプロジェクトを別のグループと共有する場合、ターゲットグループは、ソースグループのリストにないEメールのドメインをリストに追加できます。したがって、この機能では、現在のメンバーが常にメールのドメインでメンバーシップを制限するリストに準拠していることを保証するものではありません。

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

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

  1. 左側のサイドバーで、検索または移動先を選択して、グループを見つけます。新しいナビゲーションをオンにした場合、このフィールドは上部のバーに表示されます。
  2. 設定 > 一般を選択します。
  3. 権限とグループ機能セクションを展開します。
  4. Allow users to request accessチェックボックスをオフにします。
  5. 変更を保存を選択します。

Allow users to request access(ユーザーにアクセスをリクエストさせる) 設定を無効にすると、新しいアクセスリクエストが防止されます。既存の保留中のリクエストは削除されず、承認または拒否できます。

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

  • プラン: Premium、Ultimate
  • 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated

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

可能な場合は、トップレベルグループ外へのフォークを防止するようにしてください。それにより、悪意のある第三者が用いる侵入経路を減らせます。ただし、外部とのコラボレーションが多いことが予想される場合、トップレベルグループ外へのフォークを許可せざるを得ないこともあります。

前提要件:

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

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

  1. 左側のサイドバーで、検索または移動先を選択して、グループを見つけます。新しいナビゲーションをオンにした場合、このフィールドは上部のバーに表示されます。
  2. 設定 > 一般を選択します。
  3. 権限とグループ機能セクションを展開します。
  4. 現在のグループ外へプロジェクトがフォークするのを防止をオンにします。
  5. 変更を保存を選択します。

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

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

  • プラン: Premium、Ultimate
  • 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated

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

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

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

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

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

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

  1. 左側のサイドバーで、検索または移動先を選択して、グループを見つけます。新しいナビゲーションをオンにした場合、このフィールドは上部のバーに表示されます。
  2. 設定 > 一般を選択します。
  3. 権限とグループ機能セクションを展開します。
  4. メンバーシップで、このグループのプロジェクトにユーザーを追加することはできませんを選択します。
  5. 変更を保存を選択します。

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

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

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

  • プラン: Premium、Ultimate
  • 提供形態: GitLab Self-Managed

グループの同期により、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グループOwnerDevのメンバーです。
  • GitLabグループは、これら2つのLDAPグループで構成されています。
  • グループの同期が完了すると、ユーザーにはオーナーロールが付与されます。これは、2つのLDAPグループロールのうち高い方のロールであるためです。

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

LDAPグループの同期を追加すると、LDAPユーザーがグループメンバーであり、LDAPグループの一部でない場合、そのユーザーはグループから削除されます。

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

  • プラン: Premium、Ultimate
  • 提供形態: GitLab Self-Managed、GitLab Dedicated

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

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

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

  1. リンクのLDAP Server(LDAPサーバー)を選択します。
  2. 同期方法で、LDAP user filterを選択します。
  3. LDAP User filterボックスにフィルターを入力します。ユーザーフィルターに関するドキュメントの手順に従います。
  4. LDAP Accessセクションで、このグループで同期されたユーザーのデフォルトロールまたはカスタムロールを選択します。
  5. Add Synchronization(同期を追加)を選択します。
  • プラン: Premium、Ultimate
  • 提供形態: GitLab Self-Managed、GitLab Dedicated
  1. 左側のサイドバーで、検索または移動先を選択して、グループを見つけます。新しいナビゲーションをオンにした場合、このフィールドは上部のバーに表示されます。
  2. 設定 > Active synchronizationを選択します。
  3. 削除するグループリンクを特定し、削除を選択します。

LDAPグループ同期を削除すると、既存のメンバーシップとロールの割り当ては保持されます。

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

  • プラン: Premium、Ultimate
  • 提供形態: GitLab Self-Managed、GitLab Dedicated

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

  1. 左側のサイドバーで、検索または移動先を選択して、グループを見つけます。新しいナビゲーションをオンにした場合、このフィールドは上部のバーに表示されます。
  2. 管理 > メンバーを選択します。LDAP同期によって、:
    • 親グループメンバーシップよりも多くの権限を持つロールがユーザーに付与された場合、そのユーザーはグループのダイレクトメンバーシップを持っていると表示されます。
    • 親グループメンバーシップと同じかそれ以下の権限を持つロールがユーザーに付与された場合、そのユーザーはグループの継承されたメンバーシップを持っていると表示されます。
  3. (オプション)編集するユーザーが継承されたメンバーシップを持っていると表示される場合は、LDAPユーザーの権限をオーバーライドする前に、サブグループをフィルタリングしてダイレクトメンバーを表示します
  4. 編集するユーザーの行で、鉛筆( pencil ) アイコンを選択します。
  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アドレスを許可リストに追加することで、このイシューを解決できます。