グループ共有とサブグループ
(トップページはこちら) - (プロジェクトで作業を整理する)
組織の階層構造をGitLabに反映させたい、外部パートナーと特定のプロジェクトだけ共有したい。こうした要件に対して、GitLabはグループ共有とサブグループという2つの機能を提供しています。本記事では、これらの仕組みと実践的な活用方法を解説します。
1. グループ共有の仕組み
GitLabでは、プロジェクトやグループを他のグループと共有できます。共有には2つのパターンがあり、それぞれアクセス権の付与範囲が異なります。
1.1 プロジェクト共有とグループ共有の違い
プロジェクトをグループと共有する場合
招待されたグループの直接メンバーと継承メンバーの両方がアクセス権を取得します。
| メンバーの種類 | アクセス権 |
|---|---|
| 招待されたグループの直接メンバー | ✓ あり |
| 招待されたグループの継承メンバー | ✓ あり |
| 招待されたグループの共有メンバー | ✓ あり |
| サブグループの直接メンバー（招待されたグループのメンバーでない） | × なし |
グループを別のグループと共有する場合
招待されたグループの直接メンバーのみがアクセス権を取得します。
| メンバーの種類 | アクセス権 |
|---|---|
| 招待されたグループの直接メンバー | ✓ あり |
| 招待されたグループの継承メンバー | × なし |
| 招待されたグループの共有メンバー | × なし |
| サブグループのメンバー | × なし |
この違いにより、グループ共有の方がアクセス範囲を厳密に制御できます。
1.2 ロールの決定ルール
共有時のロールは、以下の2つのうち低い方が適用されます。
- メンバーが所属グループで持っているロール
- 共有時に設定した最大ロール
実践例
プロジェクト「project-01」の直接メンバー：
- ユーザーA：オーナー
- ユーザーB：メンテナー
グループ「group-01」の直接メンバー：
- ユーザーC：オーナー
- ユーザーD：メンテナー
- ユーザーE：レポーター
「group-01」を「project-01」にデベロッパー権限で招待した場合：
- ユーザーA：オーナー（変更なし）
- ユーザーB：メンテナー（変更なし）
- ユーザーC：デベロッパー（最大ロールで制限）
- ユーザーD：デベロッパー（最大ロールで制限）
- ユーザーE：レポーター（元のロールが低いため）
「group-01」を「project-01」にオーナー権限で招待した場合：
- ユーザーA：オーナー（変更なし）
- ユーザーB：メンテナー（変更なし）
- ユーザーC：オーナー（元のロールを維持）
- ユーザーD：メンテナー（元のロールを維持）
- ユーザーE：レポーター（元のロールを維持）
1.3 プロジェクトにグループを招待する手順
前提条件：
- プロジェクトのオーナーロールを持っている
- 招待するグループのメンバーである
手順：
- プロジェクトを開き、「管理」>「メンバー」を選択
- 「グループを招待」を選択
- 招待するグループと最大ロールを選択
- オプション：アクセス有効期限を設定
- 「招待」を選択
招待されたグループは「グループ」タブに、そのメンバーは「メンバー」タブに表示されます。
1.4 グループに別のグループを招待する手順
前提条件：
- 招待先グループのオーナーロールを持っている
- 招待するグループにアクセスできる
手順：
- グループを開き、「管理」>「メンバー」を選択
- 「グループを招待」を選択
- 招待するグループと最大ロールを選択
- オプション：アクセス有効期限を設定
- 「招待」を選択
招待を解除するには、「グループ」タブから「グループを削除」を選択します。
2. サブグループによる階層構造
サブグループを使うことで、組織構造をGitLab上に再現できます。
2.1 サブグループの特徴
- 1つの親グループに所属
- 最大20階層までネスト可能
- 親グループのランナーを使用可能
- サブグループごとに異なる可視性レベルを設定可能
2.2 メンバーシップの継承
親グループに追加されたメンバーは、すべてのサブグループに自動的に継承されます。サブグループのメンバーは、以下の4つの経路でアクセス権を取得します。
- 直接メンバー：サブグループに直接追加されたメンバー
- 継承メンバー：親グループから継承されたメンバー
- 共有メンバー：トップレベルグループと共有されたグループのメンバー
- 間接メンバー：継承メンバーと、サブグループまたはその祖先に招待されたグループのメンバー
メンバーページの「ソース」列で、メンバーシップの継承元を確認できます。
2.3 ロールの上書き
親グループで付与されたロールよりも低いロールをサブグループで設定することはできません。ただし、より高いロールを付与することは可能です。
例
ユーザー田中がグループ2でデベロッパーロールを持っている場合：
- グループ2のすべてのサブグループでデベロッパーロールを継承
- グループ4でメンテナーロールを付与したい場合は、グループ4に再度メンテナーロールで追加
- グループ4から削除すると、グループ2のデベロッパーロールに戻る
2.4 サブグループの作成手順
前提条件：
- グループのメンテナーロール以上を持っている
手順：
- 親グループの概要ページで「新しいサブグループ」を選択
- フィールドに入力（予約名に注意）
- 「サブグループを作成」を選択
サブグループ作成権限は、グループ設定の「権限とグループ機能」>「サブグループを作成できるロール」で変更できます。
2.5 プライベートサブグループの扱い
公開グループの中にプライベートサブグループがある場合、階層リストには展開オプションが表示されます。ただし、プライベートグループの内容を見ることができるのは、そのグループの直接メンバーまたは継承メンバーのみです。
ネストされたサブグループの存在自体を非公開にしたい場合は、プライベートサブグループをプライベートな親グループにのみ追加してください。
GitLab 16.11以降、招待されたグループの名前とメンバーシップソースは、以下の条件を満たさない限りマスクされます。
- 招待されたグループが公開されている
- 現在のユーザーが招待されたグループのメンバーである
- 現在のユーザーがプロジェクトのオーナーである
3. セキュリティとアクセス制御
3.1 プロジェクト共有の制限
プロジェクトを他のグループと共有できないように設定できます。
設定方法：
- グループ設定の「権限とグループ機能」を展開
- 「
<グループ名>のプロジェクトは他のグループと共有できません」を選択 - 「変更を保存」を選択
この設定を有効にすると：
- すべてのサブグループに適用される（サブグループのオーナーが上書きしない限り）
- 既に追加されているグループはアクセス権を失う
この設定を無効にすると：
- このグループのみに適用され、サブグループには適用されない
- すべてのサブグループで無効にするには、各サブグループを個別に更新する必要がある
3.2 階層外のグループ招待の防止
トップレベルグループで、階層外のグループを招待できないように設定できます。
例
以下のような階層がある場合：
- 動物 > 犬 > 犬プロジェクト
- 動物 > 猫
- 植物 > 木
「動物」グループで階層外の招待を防止すると：
- 「犬」は「猫」グループを招待できる（同じ階層内）
- 「犬」は「木」グループを招待できない（階層外）
- 「犬プロジェクト」は「猫」グループを招待できる（同じ階層内）
- 「犬プロジェクト」は「木」グループを招待できない（階層外）
設定方法：
- グループ設定の「権限とグループ機能」を展開
- 「メンバーは
<グループ名>とそのサブグループ外のグループを招待できません」を選択 - 「変更を保存」を選択
4. 外部ユーザーとの協力のベストプラクティス
4.1 グループ構造の設計
- 組織のニーズに基づいて論理的に構成する
- 不要なグループの作成は避ける
- 多数のユーザーを管理する場合、ユーザー管理用グループとプロジェクト管理用グループを分離する
4.2 招待時の注意点
- 必要なグループのみを招待する（過剰な共有を防ぐ）
- 最大ロールは必要最小限に設定する（デフォルトで最高ロールにしない）
- サブグループのメンバーにもアクセス権を付与したい場合は、サブグループを個別に招待する
4.3 運用上の注意点
- 複数のグループに所属するユーザーの最大ロールを確認する（意図しない高い権限を防ぐ）
- 定期的にグループアクセスを見直し、不要になったグループは削除する
- アクセス有効期限を活用する（一時的な協力の場合）
5. まとめ：使い分けの判断基準
プロジェクト共有 vs グループ共有
プロジェクト共有を使うケース
- 特定のプロジェクトのみを外部チームと共有したい
- 継承メンバーにもアクセス権を付与したい
- プロジェクト単位で細かくアクセス制御したい
グループ共有を使うケース
- 複数のプロジェクトを含むグループ全体を共有したい
- 直接メンバーのみにアクセス権を付与したい（より厳密な制御）
- 組織間の継続的な協力関係を構築したい
サブグループを使うケース
- 組織の階層構造をGitLabに反映させたい
- 部門ごとに異なる可視性レベルを設定したい
- 大規模プロジェクトでソースコードの各部分へのアクセス権を細かく制御したい
- 親グループのランナーを複数のプロジェクトで共有したい
セキュリティ設定の判断基準
プロジェクト共有を制限すべきケース
- 機密性の高いプロジェクトを扱う
- アクセス権の拡大を厳密に管理したい
- コンプライアンス要件がある
階層外の招待を防止すべきケース
- 組織の境界を明確にしたい
- 外部グループとの共有を制限したい
- アクセス権の管理を簡素化したい
GitLabのグループ共有とサブグループ機能を適切に組み合わせることで、組織の構造に合わせた柔軟かつセキュアなアクセス管理が実現できます。最小権限の原則に基づいて設定し、定期的な見直しを行うことで、長期的に管理しやすい環境を維持できます。