사용자 역할의 사전 정의된 시스템

인스턴스

사용자 유형

각 사용자는 다음 중 하나일 수 있습니다.

  • 정규.
  • 외부 - 직접 멤버인 경우에만 그룹 및 프로젝트에 액세스합니다.
  • 내부 사용자 - 시스템에서 생성됨.
  • 감사자:
    • 프로젝트나 그룹 설정 메뉴에 대한 액세스 권한 없음.
    • 관리 영역에 대한 액세스 권한 없음.
    • 나머지 모든 부분에 대한 읽기 전용 액세스 권한.
  • 관리자 - 읽기-쓰기 액세스 권한.

각 사용자 유형이 어떻게 사용되는지에 대한 자세한 내용은 권한 페이지를 참조하세요.

그룹 및 프로젝트

일반 권한

그룹 및 프로젝트에는 다음 가시성 수준이 있습니다.

  • public (20) - 모든 사람이 볼 수 있는 엔터티
  • internal (10) - 인증된 사용자만 볼 수 있는 엔터티
  • private (0) - 엔터티의 승인된 멤버에게만 보이는 엔터티

기본적으로 하위 그룹은 더 높은 가시성 수준을 가질 수 없습니다. 예를 들어, 새로운 비공개 그룹을 만든 경우, 공개 하위 그룹을 포함할 수 없습니다.

그룹의 가시성 수준은 모든 하위 그룹과 하위 프로젝트가 동일하거나 낮은 가시성 수준을 가진 경우에만 변경할 수 있습니다. 예를 들어, 모든 하위 그룹 및 프로젝트가 내부 또는 비공개인 경우에만 그룹을 내부로 설정할 수 있습니다.

caution
기존 그룹을 보다 낮은 가시성 수준으로 마이그레이션하는 경우, 해당 작업은 하위 그룹을 동일한 방식으로 마이그레이션하지 않습니다. 이는 알려진 문제입니다.

가시성 수준은 Gitlab::VisibilityLevel 모듈에서 찾을 수 있습니다.

기능별 특정 권한

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

  • 이슈
  • 리포지터리
    • Merge Request
    • 포크
    • 파이프라인
  • 분석
  • 요구 사항
  • 보안 및 컴플라이언스
  • 위키
  • 스니펫
  • 페이지
  • 작업
  • 메트릭 대시보드

이러한 기능은 “액세스 권한이 있는 모든 사람” 또는 “프로젝트 멤버만”으로 설정할 수 있습니다. 비공개 프로젝트의 경우 기본적으로 프로젝트 멤버만 액세스할 수 있습니다.

멤버

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

  • 액세스 권한 없음 (0)
  • 최소한의 액세스 (5)
  • 게스트 (10)
  • 보고자 (20)
  • 개발자 (30)
  • 유지자 (40)
  • 소유자 (50)

사용자가 프로젝트와 프로젝트 상위 그룹의 멤버인 경우, 프로젝트의 적용된 액세스 수준이 가장 높은 권한입니다.

사용자가 프로젝트의 멤버이지만 상위 그룹의 멤버가 아닌 경우, 그들은 여전히 그룹 및 엔터티(에픽과 같은)를 볼 수 있습니다.

프로젝트 멤버십(그룹 멤버십은 이미 고려된 상태)은 project_authorizations 테이블에 저장됩니다.

note
개인 네임스페이스의 프로젝트의 최대 역할은 소유자입니다.

게스트 역할

GitLab의 게스트 역할을 하는 사용자는 프로젝트 계획, 방해요소 및 기타 진행 표시를 볼 수 있습니다. 그들이 작성하지 않은 데이터를 수정할 수 없지만, 게스트는 프로젝트에 기여하여 프로젝트 작업 항목을 만들고 연결할 수 있습니다. 게스트는 또한 다음과 같은 프로젝트의 고수준 정보를 볼 수 있습니다:

  • 분석.
  • 사건 정보.
  • 이슈 및 에픽.
  • 라이선스.

자세한 정보는 프로젝트 멤버 권한을 참조하세요.

비밀 이슈

비밀 이슈는 적어도 보고자인 프로젝트 멤버에 의해서만 액세스될 수 있습니다(게스트는 액세스할 수 없습니다). 또한, 그들의 작성자 및 담당자도 액세스할 수 있습니다.

라이선스 기능

일부 기능은 사용자가 올바른 라이선스 계획을 가지고 있는 경우에만 액세스할 수 있습니다.

권한 의존성

기능 정책은 매우 복잡할 수 있으며 여러 규칙으로 구성될 수 있습니다. 많은 경우, 하나의 권한은 다른 권한에 기반할 수 있습니다.

좋은 권한을 디자인하는 것은 가능한 한 기존 권한을 최대한 재사용하고 기능에 대한 액세스를 세분화하는 것을 의미합니다.

복잡한 리소스의 경우, 리소스를 더 작은 정보 조각으로 나누고 각 조각에 대해 다른 권한을 부여해야 합니다.

이 경우의 좋은 예는 ‘Merge Request 위젯’과 ‘보안 보고서’입니다. ‘파이프라인’의 가시성 수준에 따라 ‘보안 보고서’가 위젯에 표시될 수도 있고 아닐 수도 있습니다. 따라서 ‘Merge Request 위젯’, ‘파이프라인’, ‘보안 보고서’에는 별도의 권한이 있습니다. 게다가, ‘Merge Request 위젯’과 ‘파이프라인’의 권한은 ‘보안 보고서’의 의존성입니다.

안전한 기능의 권한 의존성

안전한 기능은 복잡한 권한을 가지고 있으므로 이러한 기능은 Merge Request 및 CI 플로우와 통합되어 있습니다.

다음은 일부 권한 의존성 디렉터리입니다.

활동 수준 리소스 위치 권한 의존성
보기 라이선스 정보 의존성 디렉터리, 라이선스 컴플라이언스 리포지터리를 볼 수 있음
보기 의존성 정보 의존성 디렉터리, 라이선스 컴플라이언스 리포지터리를 볼 수 있음
보기 취약점 정보 의존성 디렉터리 보안 결과를 볼 수 있음
보기 프로젝트의 검은색/흰색 디렉터리에 있는 라이선스 라이선스 컴플라이언스, Merge Request 리포지터리를 볼 수 있음
보기 보안 결과 Merge Request, CI 작업 페이지, 파이프라인 보안 탭 프로젝트 및 CI 작업을 읽을 수 있음
보기 취약점 피드백 Merge Request 보안 결과를 읽을 수 있음
보기 의존성 디렉터리 페이지 프로젝트 의존성 정보에 액세스할 수 있음
보기 라이선스 컴플라이언스 페이지 프로젝트 라이선스 정보에 액세스할 수 있음