구성원은 프로젝트에 액세스할 수 있는 사용자와 그룹입니다. 구성원은 프로젝트에 직접 추가되거나 그룹을 통해 액세스 권한을 상속받습니다.

각 구성원에게는 프로젝트에서 수행할 수 있는 작업을 결정하는 권한이 있습니다. 적절한 권한을 가진 프로젝트 구성원은 프로젝트에 사용자를 추가하거나 제거하고 액세스 요청을 관리해 프로젝트 리소스에 대한 액세스를 통제할 수 있습니다.

구성원 유형#

사용자는 그룹이나 프로젝트의 구성원이 직접 또는 간접적으로 될 수 있습니다. 간접 구성원 자격은 상속, 공유, 상속된 공유로 나뉩니다.

%%{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

앞의 예시에서 각 구성원은 다음과 같습니다:

• Administrator는 demo 그룹에서 상속된 구성원입니다.
• User 0은 demo 그룹에서 상속된 구성원입니다.
• User 1은 이 프로젝트에 초대된 Acme 그룹의 공유 구성원입니다.
• User 2는 demo 그룹에 초대된 Toolbox 그룹에서 상속된 공유 구성원입니다.
• User 3은 이 프로젝트에 직접 추가된 구성원입니다.

보안 고려 사항#

Git은 분산 버전 관리 시스템(DVCS)입니다. 소스 코드를 다루는 모든 사람이 전체 리포지터리의 로컬 사본을 가집니다.

GitLab에서 Reporter, Developer, Maintainer, Owner 권한을 가진 모든 프로젝트 구성원은 리포지터리를 클론해 로컬 사본을 만들 수 있습니다. 로컬 사본을 확보한 사용자는 다음을 포함해 어디에나 전체 리포지터리를 업로드할 수 있습니다:

• 본인이 관리하는 다른 프로젝트.
• 다른 서버.
• 외부 호스팅 서비스.

액세스 제어로는 이미 리포지터리에 액세스할 수 있는 사용자가 의도적으로 소스 코드를 공유하는 것을 막을 수 없습니다. 모든 Git 관리 플랫폼은 분산 버전 관리 시스템의 이러한 본질적 특성을 가지고 있습니다.

권한이 있는 사용자의 의도적인 공유는 막을 수 없지만, 의도하지 않은 공유와 정보 파기를 방지하기 위해 다음 조치를 취할 수 있습니다:

• 프로젝트에 사용자를 추가할 수 있는 사람을 통제합니다.
• 보호된 브랜치를 사용해 승인되지 않은 강제 푸시를 방지합니다.
• 프로젝트 구성원을 정기적으로 검토하고 더 이상 액세스가 필요하지 않은 사용자를 제거합니다.

프로젝트에 사용자 추가#

프로젝트에 사용자를 추가하면 해당 사용자는 직접 구성원이 되어 작업을 수행할 권한을 갖습니다.

사전 요구 사항:

• Maintainer 또는 Owner 권한이 있어야 합니다.
• 그룹 구성원 자격 잠금이 비활성화되어 있어야 합니다.
• GitLab Self-Managed 인스턴스의 경우:
  • 신규 사용자 계정 생성이 비활성화되어 있으면 관리자가 사용자를 추가해야 합니다.
  • 사용자 초대가 허용되지 않으면 관리자가 사용자를 추가해야 합니다.
  • 관리자 승인이 활성화되어 있으면 관리자가 초대를 승인해야 합니다.

프로젝트에 사용자를 추가하려면 다음을 수행합니다.

1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.

2. 왼쪽 사이드바에서 Manage > Members를 선택합니다.

3. Invite members를 선택합니다.

4. 해당 사용자가:

   • GitLab 계정이 있으면 사용자 이름을 입력합니다.
   • GitLab 계정이 없으면 이메일 주소를 입력합니다.

5. 기본 역할 또는 사용자 정의 역할을 선택합니다.

6. 선택 사항. Access expiration date를 선택합니다. 해당 날짜부터 사용자는 더 이상 프로젝트에 액세스할 수 없습니다.

   액세스 만료일을 선택하면 프로젝트 구성원은 액세스가 만료되기 7일 전에 이메일 알림을 받습니다.

   [!warning] Maintainer는 권한이 만료될 때까지 모든 권한을 가지며, 본인의 액세스 만료일을 연장할 수도 있습니다.

7. Invite를 선택합니다. 초대에 사용한 값에 따라 다음과 같이 동작합니다:

   • GitLab 사용자 이름으로 초대하면 해당 사용자가 구성원 목록에 추가됩니다.
   • 이메일 주소로 초대하면 해당 주소로 초대가 전송되고 계정을 생성하라는 안내가 표시됩니다. 초대가 수락되지 않으면 GitLab은 2일, 5일, 10일 뒤에 알림 이메일을 보냅니다. 수락되지 않은 초대는 90일 뒤에 자동으로 삭제됩니다.

할당할 수 있는 권한#

할당할 수 있는 최대 권한은 그룹에 대해 Maintainer 권한을 가졌는지 Owner 권한을 가졌는지에 따라 달라집니다. 예를 들어 설정할 수 있는 최대 권한은 다음과 같습니다:

• 프로젝트에 대해 Owner 권한이 있으면 Owner(50)입니다.
• 프로젝트에 대해 Maintainer 권한이 있으면 Maintainer(40)입니다.

Owner 권한은 그룹에만 추가할 수 있습니다.

프로젝트 구성원 보기#

프로젝트의 구성원을 보려면 다음을 수행합니다.

1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Manage > Members를 선택합니다.

표에는 구성원의 다음 정보가 표시됩니다:

• Account 이름과 사용자 이름.
• 구성원 자격의 Source. GitLab은 투명성을 위해 프로젝트 구성원의 모든 구성원 자격 출처를 표시합니다. 구성원 자격 출처가 여러 개인 구성원은 별도의 구성원으로 표시되고 집계됩니다. 예를 들어 어떤 구성원이 프로젝트에 직접 추가되고 상속으로도 추가되었다면 Members 표에 서로 다른 출처로 두 번 표시되며 프로젝트의 개별 구성원 두 명으로 집계됩니다.
• 프로젝트에서의 Role.
• 프로젝트 구성원 자격의 Expiration 날짜.
• 계정과 관련된 Activity.

승격 대기 중인 사용자 보기#

권한 승격에 대한 관리자 승인이 켜져 있으면 기존 사용자를 과금 대상 권한으로 승격하는 구성원 자격 요청에는 관리자 승인이 필요합니다.

승격 대기 중인 사용자를 보려면 다음을 수행합니다.

1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Manage > Members를 선택합니다.
3. Role promotions 탭을 선택합니다.

Role promotions 탭이 표시되지 않으면 해당 프로젝트에는 대기 중인 승격이 없습니다.

만료 및 권한 업데이트#

사용자가 다음에 해당하면 각각 다음과 같이 처리합니다:

• 프로젝트의 직접 구성원이면 Expiration과 Role 필드를 프로젝트에서 바로 업데이트할 수 있습니다.
• 상속, 공유, 상속된 공유 구성원이면 Expiration과 Role 필드를 해당 구성원의 출처 그룹에서 업데이트해야 합니다.

그룹과 프로젝트 공유#

사용자를 한 명씩 추가하는 대신 프로젝트를 그룹 전체와 공유할 수 있습니다.

다른 프로젝트에서 구성원 가져오기#

다른 프로젝트의 직접 구성원을 본인 프로젝트로 가져올 수 있습니다. 가져온 프로젝트 구성원은 가져온 원본 프로젝트와 동일한 권한을 유지합니다.

사전 요구 사항:

• Maintainer 또는 Owner 권한이 있어야 합니다.

가져오기를 수행하는 구성원의 대상 프로젝트 권한에 따라 다음과 같이 동작합니다:

• Maintainer 이면 원본 프로젝트에서 Owner 권한을 가진 구성원은 Maintainer 권한으로 가져옵니다.
• Owner 이면 원본 프로젝트에서 Owner 권한을 가진 구성원은 Owner 권한으로 가져옵니다.

프로젝트의 구성원을 가져오려면 다음을 수행합니다.

1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Manage > Members를 선택합니다.
3. Import from a project를 선택합니다.
4. 프로젝트를 선택합니다. 본인이 maintainer 인 프로젝트만 볼 수 있습니다.
5. Import project members를 선택합니다.

가져오기가 성공하면 성공 메시지가 표시됩니다. Members 탭에서 가져온 구성원을 보려면 페이지를 새로 고칩니다.

프로젝트에서 구성원 제거#

사용자가 다음에 해당하면 각각 다음과 같이 처리합니다:

• 프로젝트의 직접 구성원이면 프로젝트에서 바로 제거할 수 있습니다.
• 상위 그룹에서 상속된 구성원이면 상위 그룹에서만 제거할 수 있습니다.

사전 요구 사항:

• Owner 권한이 없는 구성원을 제거할 때는 Maintainer 또는 Owner 권한이 필요합니다.
• Owner 권한이 있는 구성원을 제거할 때는 Owner 권한이 필요합니다.

프로젝트에서 구성원을 제거하려면 다음을 수행합니다.

1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Manage > Members를 선택합니다.
3. 제거할 프로젝트 구성원 옆에서 Remove member를 선택합니다.
4. 선택 사항. 확인 대화 상자에서 Also unassign this user from related issues and merge requests 체크박스를 선택합니다.
5. 비공개 프로젝트에서 민감한 정보가 유출되지 않도록 해당 구성원이 비공개 리포지터리를 포크했거나 웹훅을 생성하지 않았는지 확인합니다. 기존 포크는 업스트림 프로젝트의 변경 사항을 계속 받고, 웹훅도 업데이트를 계속 받습니다. 그룹 내 프로젝트가 그룹 밖에서 포크되지 않도록 프로젝트를 설정할 수도 있습니다.
6. Remove member를 선택합니다.

제거된 사용자가 스스로 다시 초대하지 못하도록 방지#

Maintainer 또는 Owner 권한이 있는 사용자는 관리자가 자신을 제거한 뒤 그룹이나 프로젝트에 다시 합류할 수 있는 경쟁 조건을 악용할 수 있습니다.

이 문제를 피하기 위해 GitLab 관리자는 다음을 수행할 수 있습니다:

• GitLab Rails 콘솔에서 악의적인 사용자 세션을 제거합니다.
• 악의적인 사용자를 가장해 다음을 수행합니다:
  • 프로젝트에서 해당 사용자를 제거합니다.
  • 해당 사용자를 GitLab에서 로그아웃시킵니다.
• 악의적인 사용자 계정을 차단합니다.
• 악의적인 사용자 계정을 제거합니다.
• 악의적인 사용자 계정의 비밀번호를 변경합니다.

프로젝트 구성원 필터링 및 정렬#

프로젝트의 구성원을 필터링하고 정렬할 수 있습니다.

직접 구성원 표시#

1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Manage > Members를 선택합니다.
3. Filter members 상자에서 Membership = Direct를 선택합니다.
4. Enter를 누릅니다.

간접 구성원 표시#

1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Manage > Members를 선택합니다.
3. Filter members 상자에서 Membership = Indirect를 선택합니다.
4. Enter를 누릅니다.

프로젝트에서 구성원 검색#

프로젝트 구성원을 검색하려면 다음을 수행합니다.

1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Manage > Members를 선택합니다.
3. 검색 상자에 구성원의 이름, 사용자 이름, 이메일을 입력합니다.
4. Enter를 누릅니다.

프로젝트에서 구성원 정렬#

다음 기준으로 구성원을 오름차순 또는 내림차순으로 정렬할 수 있습니다:

• Account 이름
• Access granted 날짜
• 프로젝트에서 구성원이 가진 Role
• User created 날짜
• Last activity 날짜
• Last sign-in 날짜

구성원을 정렬하려면 다음을 수행합니다.

1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Manage > Members를 선택합니다.
3. 구성원 목록 상단의 드롭다운 목록에서 정렬 기준으로 사용할 항목을 선택합니다.

프로젝트에 대한 액세스 요청#

GitLab 사용자는 프로젝트의 구성원이 되기를 요청할 수 있습니다.

1. 상단 바에서 Search or go to를 선택합니다.
2. 오른쪽 상단에서 세로 줄임표(⋮)를 선택한 다음 Request Access를 선택합니다.

가장 최근에 활동한 프로젝트 Maintainer 또는 Owner에게 이메일이 전송됩니다. 최대 10명의 프로젝트 Maintainer 또는 Owner가 알림을 받습니다. 프로젝트 Maintainer 또는 Owner는 누구나 요청을 승인하거나 거절할 수 있습니다. 프로젝트 Maintainer는 Owner 권한 액세스 요청을 승인할 수 없습니다.

프로젝트에 직접 Owner 나 Maintainer가 없으면 프로젝트 상위 그룹에서 가장 최근에 활동한 Owner가 알림을 받습니다.

프로젝트에 대한 액세스 요청 철회#

프로젝트에 대한 액세스 요청은 승인되기 전에 철회할 수 있습니다. 액세스 요청을 철회하려면 다음을 수행합니다.

1. 상단 바에서 Search or go to를 선택합니다.
2. 프로젝트 이름 옆에서 Withdraw Access Request를 선택합니다.

사용자가 프로젝트에 대한 액세스를 요청하지 못하도록 방지#

사용자가 프로젝트에 대한 액세스를 요청하지 못하도록 막을 수 있습니다.

사전 요구 사항:

• 프로젝트에 대한 Owner 권한이 있어야 합니다.
• 프로젝트가 공개 상태여야 합니다.

1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
3. Visibility, project features, permissions를 확장합니다.
4. Project visibility 아래에서 Users can request access 체크박스가 선택되어 있지 않은지 확인합니다.
5. Save changes를 선택합니다.

구성원 자격 및 공개 여부 권한#

구성원 유형에 따라 그룹이나 프로젝트의 구성원에게는 해당 그룹 또는 프로젝트에 대한 서로 다른 공개 수준과 권한이 부여됩니다.

다음 표는 프로젝트 구성원의 구성원 자격 및 공개 여부 권한을 정리한 것입니다.

다음 표는 그룹 구성원의 구성원 자격 및 공개 여부 권한을 정리한 것입니다.

다음 예시에서 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
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