인스턴스#

사용자 유형#

각 사용자는 다음 유형 중 하나에 해당합니다.

• 일반(Regular).
• 외부(External) - 직접 멤버인 경우에만 그룹과 프로젝트에 접근합니다.
• 내부 사용자 - 시스템이 생성합니다.
• Auditor:
  • 프로젝트 또는 그룹 설정 메뉴에 접근할 수 없습니다.
  • Admin 영역에 접근할 수 없습니다.
  • 그 외 모든 항목에 읽기 전용으로 접근합니다.
• Administrator - 읽기·쓰기 권한을 가집니다.

각 사용자 유형이 어떻게 사용되는지는 권한 페이지를 참고합니다.

역할 정의 YAML 파일#

기본 역할은 config/authz/roles/ 아래의 YAML 파일에 정의되어 있습니다. 각 파일은 해당 역할의 직접 권한과 상속 계층을 지정합니다. 전체 스키마와 권한이 해석되는 방식은 역할 정의 YAML 파일을 참고합니다.

그룹 및 프로젝트#

일반 권한#

그룹과 프로젝트는 다음 공개 수준을 가질 수 있습니다.

• public(20) - 엔터티가 모든 사용자에게 표시됩니다
• internal(10) - 엔터티가 인증된 사용자에게 표시됩니다
• private(0) - 엔터티가 승인된 멤버에게만 표시됩니다

기본적으로 하위 그룹은 상위보다 높은 공개 수준을 가질 수 없습니다. 예를 들어 새 private 그룹을 만들면 그 안에 public 하위 그룹을 둘 수 없습니다.

그룹의 공개 수준은 모든 하위 그룹과 하위 프로젝트의 공개 수준이 같거나 더 낮은 경우에만 변경할 수 있습니다. 예를 들어 모든 하위 그룹과 프로젝트가 internal 또는 private 인 경우에만 그룹을 internal로 설정할 수 있습니다.

공개 수준은 Gitlab::VisibilityLevel 모듈에서 확인할 수 있습니다.

기능별 권한#

또한 다음 프로젝트 기능은 서로 다른 공개 수준을 가질 수 있습니다.

• Issues
• Repository
  • Merge request
  • Forks
  • Pipelines
• Analytics
• Requirements
• Security and compliance
• Wiki
• Snippets
• Pages
• Operations
• Metrics Dashboard

이 기능들은 "Everyone with Access" 또는 "Only Project Members" 로 설정할 수 있습니다. private 프로젝트는 기본적으로 프로젝트 멤버만 접근할 수 있으므로, 이 설정은 public 또는 internal 프로젝트에서만 의미가 있습니다.

멤버#

사용자는 여러 그룹과 프로젝트의 멤버가 될 수 있습니다. 다음 액세스 수준을 사용할 수 있습니다 (Gitlab::Access 모듈에 정의되어 있습니다).

• No access (0)
• Minimal access (5)
• Guest (10)
• Planner (15)
• Reporter (20)
• Security Manager (25)
• Developer (30)
• Maintainer (40)
• Owner (50)

사용자가 프로젝트와 그 프로젝트의 상위 그룹 모두의 멤버라면, 해당 프로젝트에는 가장 높은 권한이 액세스 수준으로 적용됩니다.

사용자가 프로젝트의 멤버이지만 상위 그룹의 멤버가 아니어도 그룹과 그 엔터티(예: 에픽)를 볼 수 있습니다.

프로젝트 멤버십(그룹 멤버십이 이미 반영된 값)은 project_authorizations 테이블에 저장됩니다.

Guest 권한#

GitLab에서 Guest 권한을 가진 사용자는 프로젝트 계획, 블로커, 그 밖의 진행 지표를 볼 수 있습니다. 직접 만들지 않은 데이터는 수정할 수 없지만, 프로젝트 작업 항목을 생성하고 연결하는 방식으로 프로젝트에 기여할 수 있습니다. 또한 다음과 같은 상위 수준 프로젝트 정보를 볼 수 있습니다.

• 분석 정보.
• 인시던트 정보.
• 이슈와 에픽.
• 라이선스.

자세한 내용은 프로젝트 멤버 권한을 참고합니다.

기밀 이슈#

기밀 이슈는 최소 Reporter 권한을 가진 프로젝트 멤버만 접근할 수 있습니다(Guest는 접근할 수 없습니다). 또한 해당 이슈의 작성자와 담당자도 접근할 수 있습니다.

라이선스 기능#

일부 기능은 사용자가 적절한 라이선스 플랜을 가진 경우에만 접근할 수 있습니다.

권한 의존성#

기능 정책은 상당히 복잡할 수 있으며 여러 규칙으로 구성됩니다. 하나의 권한이 다른 권한을 기반으로 하는 경우도 많습니다.

좋은 권한 설계란 기존 권한을 최대한 재사용하고 기능에 대한 접근을 세분화하는 것입니다.

복잡한 리소스는 더 작은 정보 단위로 나누고 각 단위에 서로 다른 권한을 부여해야 합니다.

이 경우의 좋은 예가 머지 리퀘스트 위젯 과 보안 리포트 입니다. 파이프라인 의 공개 수준에 따라 보안 리포트 가 위젯에 표시되기도 하고 표시되지 않기도 합니다. 따라서 머지 리퀘스트 위젯, 파이프라인, 보안 리포트 는 각각 별도의 권한을 가집니다. 나아가 머지 리퀘스트 위젯 과 파이프라인 의 권한은 보안 리포트 의 의존성입니다.

Secure 기능의 권한 의존성#

Secure 기능은 머지 리퀘스트, CI/CD 흐름 등 여러 기능과 통합되어 있어 권한이 복잡합니다.

다음은 권한 의존성의 일부 목록입니다.