プロジェクトのメンバー
- プラン: Free、Premium、Ultimate
- 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated
メンバーとは、プロジェクトへのアクセス権を持つユーザーとグループのことです。メンバーは、プロジェクトに直接追加することも、グループを通じてアクセス権を継承することもできます。
各メンバーは、プロジェクトで何ができるかを決定するロールを持っています。適切なロールを持つプロジェクトメンバーは、プロジェクトにユーザーを追加したり、プロジェクトからユーザーを削除したり、アクセスリクエストを管理してプロジェクトリソースへのアクセスを制御したりできます。
メンバーシップの種類
ユーザーは、グループまたはプロジェクトのメンバーに直接的または間接的になることができます。間接的なメンバーシップは、継承、共有、または継承共有される可能性があります。
| メンバーシップの種類 | メンバーシップのプロセス |
|---|---|
| 直接 | ユーザーは、現在のグループまたはプロジェクトに直接追加されます。 |
| 継承 | ユーザーは、現在のグループまたはプロジェクトを含む親グループのメンバーです。 |
| 共有 | ユーザーは、現在のグループまたはプロジェクトに招待されたグループのメンバーです。 |
| 継承共有 | ユーザーは、現在のグループまたはプロジェクトの祖先に招待されたグループのメンバーです。 |
| 間接 | 継承メンバー、共有メンバー、または継承共有メンバーを指す包括的な用語です。 |
%%{init: { "fontFamily": "GitLab Sans" }}%%
flowchart RL
accTitle: Membership types
accDescr: Describes membership types and their inheritance
subgraph Group A
A(Direct member)
B{{Shared member}}
subgraph Project X
H(Direct member)
C{{Inherited member}}
D{{Inherited shared member}}
E{{Shared member}}
end
A-->|Inherited membership in Project X
Direct membership in Group A|C
end
subgraph Group C
G(Direct member)
end
subgraph Group B
F(Direct member)
end
F-->|Group B
invited to
Group A|B
B-->|Inherited membership in Project X
Indirect membership in Group A|D
G-->|Group C invited to Project X|E
前の例では:
- 管理者は、demoグループからの継承メンバーです。
- ユーザー0は、demoグループからの継承メンバーです。
- ユーザー1は、このプロジェクトに招待されたAcmeグループからの共有メンバーです。
- ユーザー2は、demoグループに招待されたToolboxグループからの継承共有メンバーです。
- ユーザー3は、このプロジェクトに追加された直接メンバーです。
セキュリティに関する考慮事項
Gitは、分散型バージョン管理システム(DVCS)です。ソースコードを操作するすべてのユーザーは、リポジトリ全体のローカルコピーを保持しています。
GitLabでは、レポーター以上のロールを持つすべてのプロジェクトメンバーは、ローカルコピーを作成するためにリポジトリをクローンできます。ユーザーは、ローカルコピーを取得した後、次の場所を含め、どこにでもリポジトリ全体をアップロードできます:
- 自分の管理下にある別のプロジェクト。
- 別のサーバー。
- 外部ホスティングサービス。
アクセス制御では、既にリポジトリへのアクセス制御を持つユーザーによるソースコードの意図的な共有を防ぐことはできません。すべてのGit管理プラットフォームは、分散型バージョン管理システムのこの固有の特性を備えています。
権限のあるユーザーによる意図的な共有を防ぐことはできませんが、意図しない共有や情報の破壊を防ぐために、次の手順を実行できます:
- 誰がプロジェクトにユーザーを追加できるかを制御します。
- 承認されていない強制プッシュを防ぐには、保護されたブランチを使用します。
- プロジェクトのメンバーシップを定期的にレビューし、アクセス制御を必要としなくなったユーザーを削除します。
プロジェクトにユーザーを追加する
ユーザーをプロジェクトに追加して直接メンバーにし、アクションを実行する権限を与えます。
前提要件:
- オーナーまたはメンテナーのロールを持っている必要があります。
- グループメンバーシップのロックを無効にする必要があります。
- GitLab Self-Managedインスタンスの場合:
- 新規サインアップが無効になっている場合、管理者がユーザーを追加する必要があります。
- ユーザー招待が許可されていない場合、管理者がユーザーを追加する必要があります。
- 管理者による承認が有効になっている場合、管理者が招待を承認する必要があります。
プロジェクトにユーザーを追加するには:
左側のサイドバーで、検索または移動先を選択して、プロジェクトを見つけます。
管理 > メンバーを選択します。
メンバーを招待を選択します。
ユーザーは次の操作を行います:
- GitLabアカウントを持っている場合は、ユーザー名を入力します。
- GitLabアカウントを持っていない場合は、メールアドレスを入力します。
オプション。アクセス有効期限を選択します。その日付以降、ユーザーはプロジェクトにアクセスできなくなります。
アクセス権の有効期限を選択した場合、プロジェクトメンバーには、アクセス権の有効期限が切れる7日前にメール通知が送信されます。
メンテナーは、自分のアクセス権の有効期限を延長する機能を含め、ロールの有効期限が切れるまで完全な権限を持ちます。
招待を選択します。次のようになります:
- GitLabユーザー名を使用した場合は、メンバーリストに追加されます。
- メールアドレスを使用した場合は、招待状がメールアドレスに送信され、アカウントを作成するように求められます。招待が承認されない場合、GitLabは2日後、5日後、および10日後にリマインダーメールを送信します。未承認の招待は、90日後に自動的に削除されます。
割り当てることができるロール
割り当てることができる最大のロールは、グループのオーナーロールまたはメンテナーロールを持っているかどうかによって異なります。たとえば、設定できる最大のロールは次のとおりです:
- プロジェクトのオーナーロールを持っている場合は、オーナー(
50)。 - プロジェクトのメンテナーロールを持っている場合は、メンテナー(
40)。
オーナーロールは、グループにのみ追加できます。
昇格保留中のユーザーを表示する
ロールの昇格に対する管理者の承認が有効になっている場合は、既存のユーザーを請求対象のロールに昇格するメンバーシップリクエストには、管理者による承認が必要です。
昇格保留中のユーザーを表示するには:
- 左側のサイドバーで、検索または移動先を選択して、プロジェクトを見つけます。
- 管理 > メンバーを選択します。
- ロールの昇格タブを選択します。
ロールの昇格タブが表示されない場合、プロジェクトに保留中の昇格はありません。
有効期限とロールを更新する
ユーザーが次の場合:
- プロジェクトの直接メンバーである場合、有効期限フィールドとロールフィールドはプロジェクトで直接更新できます。
- 継承メンバー、共有メンバー、または継承共有メンバーである場合、有効期限フィールドとロールフィールドは、メンバーの元のグループで更新する必要があります。
プロジェクトをグループと共有する
ユーザーを1人ずつ追加する代わりに、プロジェクトをグループ全体と共有できます。
別のプロジェクトからメンバーをインポートする
別のプロジェクトの直接メンバーを自分のプロジェクトにインポートできます。インポートされたプロジェクトメンバーは、インポート元のプロジェクトと同じ権限を保持します。
プロジェクトの直接メンバーのみがインポートされます。プロジェクトの継承メンバーまたは共有メンバーはインポートされません。
前提要件:
- メンテナー以上のロールを持っている必要があります。
ターゲットプロジェクトに対するインポートメンバーのロールによって、次のようになります:
- メンテナーの場合、ソースプロジェクトのオーナーロールを持つメンバーは、メンテナーロールでインポートされます。
- オーナーの場合、ソースプロジェクトのオーナーロールを持つメンバーは、オーナーロールでインポートされます。
プロジェクトのメンバーをインポートするには:
- 左側のサイドバーで、検索または移動先を選択して、プロジェクトを見つけます。
- 管理 > メンバーを選択します。
- プロジェクトからインポートを選択します。
- プロジェクトを選択します。自分がメンテナーであるプロジェクトのみ表示できます。
- プロジェクトメンバーのインポートを選択します。
インポートが成功すると、成功メッセージが表示されます。メンバータブにインポートされたメンバーを表示するには、ページを更新します。
プロジェクトからメンバーを削除する
ユーザーが次の場合:
- プロジェクトの直接メンバーである場合は、プロジェクトから直接削除できます。
- 親グループからの継承メンバーである場合は、親グループ自体からのみ削除できます。
前提要件:
- 以下のロールを持つ直接メンバーを削除するには:
- メンテナー、デベロッパー、レポーター、プランナー、またはゲストロールの場合は、メンテナーロールを持っている必要があります。
- オーナーロールの場合は、オーナーロールを持っている必要があります。
- オプション。割り当てられているすべてのイシューとマージリクエストからメンバーの割り当てを解除していること。
プロジェクトからメンバーを削除するには:
- 左側のサイドバーで、検索または移動先を選択して、プロジェクトを見つけます。
- 管理 > メンバーを選択します。
- 削除するプロジェクトメンバーの横にあるメンバーを削除を選択します。
- オプション。確認ダイアログで、また、関連するイシューとマージリクエストからこのユーザーのアサインを解除しますチェックボックスをオンにします。
- プライベートプロジェクトからの機密情報の漏えいを防ぐために、メンバーがプライベートリポジトリをフォークしたり、Webhookを作成したりしていないことを確認してください。既存のフォークはアップストリームプロジェクトからの変更を引き続き受信し、Webhookは更新を引き続き受信します。グループ内のプロジェクトがグループ外にフォークされないようにプロジェクトを設定することもできます。
- メンバーを削除を選択します。
削除されたユーザーが自分自身を再度招待できないようにする
メンテナーまたはオーナーロールを持つユーザーは、管理者が削除した後、グループまたはプロジェクトに再参加できる競合条件を悪用する可能性があります。
この問題を回避するために、GitLab管理者は以下を実行できます:
- GitLab Railsコンソールから悪意のあるユーザーセッションを削除します。
- 悪意のあるユーザーになりすまして、以下を行います:
- プロジェクトからユーザーを削除します。
- GitLabからユーザーをログアウトします。
- 悪意のあるユーザーアカウントをブロックします。
- 悪意のあるユーザーアカウントを削除します。
- 悪意のあるユーザーアカウントのパスワードを変更します。
プロジェクトメンバーをフィルタリングおよび並べ替える
プロジェクト内のメンバーのフィルタリングおよび並べ替えを行うことができます。
直接メンバーを表示する
- 左側のサイドバーで、検索または移動先を選択して、プロジェクトを見つけます。
- 管理 > メンバーを選択します。
- メンバーをフィルターするボックスで、
Membership=Directを選択します。 - Enterキーを押します。
間接メンバーを表示する
- 左側のサイドバーで、検索または移動先を選択して、プロジェクトを見つけます。
- 管理 > メンバーを選択します。
- メンバーをフィルターするボックスで、
Membership=Indirectを選択します。 - Enterキーを押します。
プロジェクト内のメンバーを検索する
プロジェクトメンバーを検索するには:
- 左側のサイドバーで、検索または移動先を選択して、プロジェクトを見つけます。
- 管理 > メンバーを選択します。
- 検索ボックスに、メンバーの名前、ユーザー名、またはメールアドレスを入力します。
- Enterキーを押します。
プロジェクト内のメンバーを並べ替える
メンバーは、次の順序で昇順または降順に並べ替えることができます:
- アカウント名
- アクセス付与日日
- メンバーがプロジェクトで持つロール
- 作成されたユーザー日
- 最後のアクティビティー日
- 最終ログイン日
メンバーを並べ替えるには:
- 左側のサイドバーで、検索または移動先を選択して、プロジェクトを見つけます。
- 管理 > メンバーを選択します。
- メンバーリストの上部にあるドロップダウンリストから、並べ替えの基準にする項目を選択します。
プロジェクトへのアクセスをリクエストする
GitLabユーザーは、プロジェクトのメンバーになることをリクエストできます。
- 左側のサイドバーで、検索または移動先を選択して、メンバーになるプロジェクトを見つけます。
- 右上隅で、縦方向の省略記号( )を選択し、アクセスをリクエストを選択します。
最近アクティブなプロジェクトのメンテナーまたはオーナーにメールが送信されます。最大10人のプロジェクトメンテナーまたはオーナーに通知されます。プロジェクトのオーナーまたはメンテナーは、リクエストを承認または拒否できます。プロジェクトメンテナーは、オーナーロールのアクセスリクエストを承認できません。
プロジェクトに直接のオーナーまたはメンテナーがいない場合、プロジェクトの親グループの最近アクティブなオーナーが通知を受け取ります。
プロジェクトへのアクセスリクエストを取り下げる
リクエストが承認される前に、プロジェクトへのアクセスリクエストを取り下げることができます。アクセスリクエストを取り下げるには:
- 左側のサイドバーで、検索または移動先を選択して、アクセスをリクエストしたプロジェクトを見つけます。
- プロジェクト名の横にあるアクセスリクエストを取り消すを選択します。
ユーザーがプロジェクトへのアクセスをリクエストできないようにする
ユーザーがプロジェクトへのアクセスをリクエストできないようにすることができます。
前提要件:
- プロジェクトのオーナーロールを持っている必要があります。
- プロジェクトはパブリックである必要があります。
- 左側のサイドバーで、検索または移動先を選択して、プロジェクトを見つけます。
- 設定 > 一般を選択します。
- 可視性、プロジェクトの機能、権限を展開します。
- プロジェクトの表示レベルで、ユーザーがアクセスをリクエストできますチェックボックスがオンになっていないことを確認します。
- 変更を保存を選択します。
メンバーシップと表示レベルの権利
グループまたはプロジェクトのメンバーには、メンバーシップの種類に応じて、グループまたはプロジェクトに対するさまざまな表示レベルと権利が付与されます。
次の表に、プロジェクトメンバーのメンバーシップと表示レベルの権利を示します。
| アクション | 直接プロジェクトメンバー | 継承プロジェクトメンバー | 直接共有プロジェクトメンバー | 継承共有プロジェクトメンバー |
|---|---|---|---|---|
| ボードを生成する | 可 | 可 | 可 | 可 |
| 親グループのイシューを表示する1 | 可 | 可 | 可 | 可 |
| 親グループのラベルを表示する | 可 | 可 | 可 | 可 |
| 親グループのマイルストーンを表示する | 可 | 可 | 可 | 可 |
| 他のグループに共有される | 可 | 不可 | 不可 | 不可 |
| 他のプロジェクトにインポートされる | 可 | 不可 | 不可 | 不可 |
| プロジェクトを他のメンバーと共有する | 可 | 可 | 可 | 可 |
Footnotes(補足説明):
- ユーザーは、アクセス権を持つプロジェクトのイシューのみ表示できます。
次のテーブルに、グループメンバーのメンバーシップと表示レベルの権利を示します。
| アクション | 直接グループメンバー | 継承グループメンバー | 直接共有グループメンバー | 継承共有グループメンバー |
|---|---|---|---|---|
| ボードを生成する | 可 | 可 | 可 | 可 |
| 親グループのイシューを表示する | 可 | 可 | 可 | 可 |
| 親グループのラベルを表示する | 可 | 可 | 可 | 可 |
| 親グループのマイルストーンを表示する | 可 | 可 | 可 | 可 |
次の例では、Userは以下のとおりです:
subgroupの直接メンバー。subsubgroupの継承メンバー。subgroup-2とsubgroup-3の間接メンバー。subsubgroup-2とsubsubgroup-3の間接継承メンバー。
%%{init: { "fontFamily": "GitLab Sans" }}%%
graph TD
accTitle: Diagram of group inheritance
accDescr: User inheritance, both direct and indirect through subgroups
classDef user stroke:green,color:green;
root --> subgroup --> subsubgroup
root-2 --> subgroup-2 --> subsubgroup-2
root-3 --> subgroup-3 --> subsubgroup-3
subgroup -. shared .-> subgroup-2 -. shared .-> subgroup-3
User-. member .- subgroup
class User user
