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

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

구성원 유형#

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

%%{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. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.

2. 왼쪽 사이드바에서 관리 > 구성원을 선택합니다.

3. 구성원 초대를 선택합니다.

4. 사용자가:

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

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

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

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

   [!warning] Maintainer는 자신의 액세스 만료일을 연장하는 기능을 포함하여 역할이 만료될 때까지 전체 권한을 갖습니다.

7. 초대를 선택합니다. 다음을 사용하여 사용자를 초대한 경우:

   • GitLab 사용자 이름 - 구성원 목록에 추가됩니다.
   • 이메일 주소 - 이메일 주소로 초대장이 보내지고 계정을 만들도록 메시지가 표시됩니다. 초대가 수락되지 않으면 GitLab은 2일, 5일, 10일 후에 알림 이메일을 보냅니다. 수락되지 않은 초대는 90일 후 자동으로 삭제됩니다.

할당할 수 있는 역할#

할당할 수 있는 최대 역할은 그룹에 대한 Maintainer 또는 Owner 역할이 있는지에 따라 다릅니다. 예를 들어, 설정할 수 있는 최대 역할은 다음과 같습니다:

• 프로젝트에 대한 Owner 역할이 있는 경우 Owner(50).
• 프로젝트에 대한 Maintainer 역할이 있는 경우 Maintainer(40).

Owner 역할은 그룹에 대해서만 추가할 수 있습니다.

프로젝트 구성원 보기#

프로젝트 구성원을 보려면:

1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 관리 > 구성원을 선택합니다.

테이블에 구성원의 다음 항목이 표시됩니다:

• 계정 이름과 사용자 이름.
• 구성원 유형의 소스. 투명성을 위해 GitLab은 프로젝트 구성원의 모든 구성원 소스를 표시합니다. 여러 구성원 소스를 가진 구성원은 별도의 구성원으로 표시되고 계산됩니다. 예를 들어, 구성원이 직접 및 상속을 통해 프로젝트에 추가된 경우 구성원은 구성원 테이블에 서로 다른 소스로 두 번 표시되고 두 개의 개별 프로젝트 구성원으로 계산됩니다.
• 프로젝트에서 역할.
• 프로젝트 구성원의 만료 날짜.
• 계정과 관련된 활동.

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

역할 승격에 대한 관리자 승인이 켜진 경우 기존 사용자를 청구 가능한 역할로 승격하는 구성원 요청은 관리자 승인이 필요합니다.

승격 대기 중인 사용자를 보려면:

1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 관리 > 구성원을 선택합니다.
3. 역할 승격 탭을 선택합니다.

역할 승격 탭이 표시되지 않으면 프로젝트에 보류 중인 승격이 없습니다.

만료 및 역할 업데이트#

사용자가:

• 프로젝트의 직접 구성원인 경우 만료 및 역할 필드를 프로젝트에서 직접 업데이트할 수 있습니다.
• 상속, 공유 또는 상속된 공유 구성원인 경우 만료 및 역할 필드는 구성원이 속한 그룹에서 업데이트해야 합니다.

그룹과 프로젝트 공유#

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

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

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

사전 요구 사항:

• Maintainer 또는 Owner 역할이 있어야 합니다.

대상 프로젝트에 대한 가져오는 구성원의 역할이:

• Maintainer인 경우 소스 프로젝트에서 Owner 역할을 가진 구성원은 Maintainer 역할로 가져옵니다.
• Owner인 경우 소스 프로젝트에서 Owner 역할을 가진 구성원은 Owner 역할로 가져옵니다.

프로젝트의 구성원을 가져오려면:

1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 관리 > 구성원을 선택합니다.
3. 프로젝트에서 가져오기를 선택합니다.
4. 프로젝트를 선택합니다. 유지 관리자인 프로젝트만 볼 수 있습니다.
5. 프로젝트 구성원 가져오기를 선택합니다.

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

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

사용자가:

• 프로젝트의 직접 구성원인 경우 프로젝트에서 직접 제거할 수 있습니다.
• 상위 그룹에서 상속된 구성원인 경우 상위 그룹 자체에서만 제거할 수 있습니다.

사전 요구 사항:

• Owner 역할이 없는 구성원을 제거할 때는 Maintainer 또는 Owner 역할.
• Owner 역할을 가진 구성원을 제거할 때는 Owner 역할.

프로젝트에서 구성원을 제거하려면:

1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 관리 > 구성원을 선택합니다.
3. 제거할 프로젝트 구성원 옆에서 구성원 제거를 선택합니다.
4. 선택 사항. 확인 대화 상자에서 이 사용자의 관련 이슈 및 머지 요청 할당도 취소 체크박스를 선택합니다.
5. 비공개 프로젝트에서 민감한 정보가 유출되지 않도록 구성원이 비공개 저장소를 포크하지 않았거나 웹훅을 만들지 않았는지 확인합니다. 기존 포크는 업스트림 프로젝트에서 변경 사항을 계속 받으며, 웹훅은 업데이트를 계속 받습니다. 그룹의 프로젝트가 그룹 외부에서 포크되지 않도록 프로젝트를 구성할 수도 있습니다.
6. 구성원 제거를 선택합니다.

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

Maintainer 또는 Owner 역할을 가진 사용자는 관리자가 제거한 후에 그룹이나 프로젝트에 다시 참여할 수 있는 경쟁 조건을 악용할 수 있습니다.

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

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

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

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

직접 구성원 표시#

1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 관리 > 구성원을 선택합니다.
3. 구성원 필터링 상자에서 Membership = Direct를 선택합니다.
4. Enter를 누릅니다.

간접 구성원 표시#

1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 관리 > 구성원을 선택합니다.
3. 구성원 필터링 상자에서 Membership = Indirect를 선택합니다.
4. Enter를 누릅니다.

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

프로젝트 구성원을 검색하려면:

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

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

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

• 계정 이름
• 액세스 부여 날짜
• 프로젝트에서 구성원이 갖는 역할
• 사용자 생성 날짜
• 마지막 활동 날짜
• 마지막 로그인 날짜

구성원을 정렬하려면:

1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 관리 > 구성원을 선택합니다.
3. 구성원 목록 상단에서 드롭다운 목록으로 정렬할 항목을 선택합니다.

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

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

1. 상단 바에서 검색 또는 이동을 선택합니다.
2. 오른쪽 상단에서 세로 줄임표 (⋮)를 선택하고 액세스 요청을 선택합니다.

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

프로젝트에 직접 Maintainer 또는 Owner가 없는 경우 프로젝트의 상위 그룹에서 가장 최근에 활동한 Owner가 알림을 받습니다.

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

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

1. 상단 바에서 검색 또는 이동을 선택합니다.
2. 프로젝트 이름 옆에서 액세스 요청 철회를 선택합니다.

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

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

사전 요구 사항:

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

1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 설정 > 일반을 선택합니다.
3. 공개 여부, 프로젝트 기능, 권한을 확장합니다.
4. 프로젝트 공개 여부 아래에서 사용자가 액세스를 요청할 수 있음 체크박스가 선택되어 있지 않은지 확인합니다.
5. 변경 사항 저장을 선택합니다.

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

구성원 유형에 따라 그룹이나 프로젝트의 구성원은 그룹이나 프로젝트에 대한 다양한 공개 여부 수준과 권한을 부여받습니다.

다음 표는 프로젝트 구성원의 구성원 자격 및 공개 여부 권한을 나열합니다.

주석:

1. 사용자는 액세스할 수 있는 프로젝트의 이슈만 볼 수 있습니다.

다음 표는 그룹 구성원의 구성원 자격 및 공개 여부 권한을 나열합니다.

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