This page contains information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned on this page are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
Status Authors Coach DRIs Owning Stage Created
proposed @jessieay @jarka @grzesiek @hsutor @adil.farrukh devops manage 2023-03-10

사용자 정의 역할을 활성화하기 위한 권한 변경 사항

요약

현재 GitLab 권한 시스템은 우리의 정적 역할 기반 액세스 제어 시스템의 백엔드 구현 세부 사항입니다.

%15.9에서 알려드린 바와 같이, 사용자 정의 역할 기능의 고객 MVC를 발표했습니다. MVC는 기본 GitLab Guest 역할을 기반으로 한 사용자 정의 역할에 하나의 단일 권한(read_code)을 추가하는 기능을 소개했습니다. MVC는 기존의 권한을 가져와 사용자 정의 역할이 true로 설정된 경우 활성화하도록 구현되었습니다.

MVC 이후, Auth 그룹은 더 많은 권한을 사용자 정의할 수 있도록 하는 작업을 시작했으며, 최종 목표는 모든 권한을 사용자 정의할 수 있도록 하는 것입니다.

이 작업을 계획하기 시작하자, 두 가지 큰 도전 과제가 있습니다:

  1. GitLab 권한 시스템은 안정적이지 않고 하위 호환되는 API가 아닙니다. 그러나 사용자 정의 역할 기능은 현재 권한 시스템을 기반으로 구축되었기 때문에, 사용자 정의 역할은 권한이 안정적이고 하위 호환되는 API인 것을 전제로 합니다. 따라서 현재의 아키텍처를 유지하려면 권한 시스템에 대한 접근 방식을 변경해야 합니다.
  2. 권한 시스템을 재구성하는 것은 권한 수(700개 이상), 코드베이스 전체에 걸친 권한 확인 중복, 그리고 보안상의 중요성(오류 비용이 매우 높음)으로 인해 어려운 작업입니다.

이 청사진은 이러한 도전 과제 각각에 대해 자세히 설명하고 해결책의 길을 제안합니다.

사용자 정의 역할이란?

우리의 권한 시스템은 여섯 가지 기본 역할(Guest, Reporter, Developer, Maintainer, Owner)을 지원하며, 사용자는 프로젝트나 그룹마다 할당되며 수정할 수 없습니다. 사용자 정의 역할은 현재 시스템의 제약 사항을 해결해야 합니다.

사용자 정의 역할을 사용하면 고객이 자신만의 역할을 정의하고 원하는 권한을 부여할 수 있습니다. 만들어진 각 역할에 대해 권한 집합을 할당할 수 있습니다. 예를 들어 새로 만든 “Engineer” 역할은 read codeadmin merge requests를 활성화할 수 있지만 admin issues와 같은 기능은 비활성화할 수 있습니다.

동기

이 계획을 정의하는 것은 현재 사용자 정의 역할 프로젝트의 아키텍처가 현재 권한 시스템인 선언적 정책을 기반으로 구축되어 있기 때문에 중요합니다. 선언적 정책을 사용하면 새로운 권한을 추가하는 데 비용이 들지 않게 되어 현재 gitlab-org/gitlab 코드베이스에 700개 이상의 권한이 생겼습니다. 심지어 권한 문서에는 각각이 고유한 “권한”을 나타내는 200개 이상의 행이 있는 표가 있습니다. 지금까지 코드 내 권한의 증식은 공개 API의 일부가 아니기 때문에 관리가 가능했습니다. 그러나 사용자 정의 역할에서는 이러한 상황이 변화하고 있습니다.

현재의 권한 확인은 코드 전반에 중복되어 흩어져 있습니다. 단일 웹 요청에는 사용자가 페이지 요소를 볼 수 있는지 여부를 결정하기 위해 UI에서 여러 권한이 확인될 것이며, 또한 사용자가 경로에 액세스할 수 있는지를 결정하기 위해 Rails 컨트롤러에서 몇 가지 권한 확인이 이루어질 것입니다. 또한 페이지로드의 일환으로 실행되는 다른 Ruby 서비스 클래스에 몇 가지 권한 확인이 더 분산될 것입니다. 이 접근 방식은 “깊이 있는 방어”로 GitLab 개발자 문서에서 권장되고 있습니다.

그러나 사용자 정의 역할의 맥락에서는 이러한 접근 방식이 작동하지 않을 것입니다. 그룹 관리자가 사용자 정의 역할을 통해 단일 작업을 사용자가 수행할 수 있도록 활성화하려면 그룹 관리자가 하나의 명확하게 명명된 권한을 토글할 수 있어야 합니다. 따라서 단일 웹 요청에는 하나의 명확하게 명명된 권한만 확인되어야 합니다. 또한 해당 권한에 부여된 액세스는 비교적 안정적이어야 하여 관리자가 예상보다 더 많은 액세스 권한을 부여하는 일이 없어야 합니다. 그렇지 않으면 사용자 정의 역할의 생성 및 관리가 지나치게 복잡하고 보안상의 악몽이 될 것입니다.

권한은 Auth 그룹이 소유한 기능이지만, 각 팀은 도메인 영역과 관련된 권한 집합을 소유하고 있습니다. 이는 gitlab-org/gitlab 코드베이스의 각 구석구석에 걸쳐 권한을 사용하는 모든 엔지니어링 팀이 권한에 영향을 미친다는 것을 의미합니다. 따라서 권한의 미래에 대한 명확한 지침을 제공하고 이러한 지침의 자동화를 제공하는 것이 더욱 중요합니다.

목표

  • 모든 권한을 사용자 정의 역할을 통해 사용자 정의할 수 있도록 만들기.
  • GitLab 권한 시스템을 공개 API로 가치 있게 만들기.
  • 권한의 명칭과 일관성 개선하기.
  • 700개 이상의 총 권한 수를 100개 미만으로 줄이기.
  • 권한과 관련된 리팩터링의 위험 감소시키기.
  • 단위 테스트와 문서화 외의 동작을 평가할 수 있는 방법을 통해 권한의 리팩터링을 더 쉽게 만들기.
  • 개별 권한의 소유권을 추적하여 해당 권한에 관한 변경 사항에 대해 소유자에게 상담을 받을 수 있도록 만들기.
  • 권한 동작에 대한 단일 진실의 원천(SSoT) 만들기.
  • 권한 문서화 생성을 자동화하기.

비목표

  • 기존 권한 시스템을 리팩터링하는 동안 사용자 정의 역할 프로젝트를 무기한 중지하기(이는 최종 기능으로 큰 수요가 있음).
  • 전체 권한 시스템을 완전히 다시 작성하거나 다시 빌드하지 않기(고강도의 투자로 인해 고객 가치를 제공하지 못함).
  • 기능을 완전히 완료하지 않고 반복적으로 사용자 정의 역할에 착수하기(“어디로든 반복하기”).

제안

  1. 모든 새로운 권한이 명명 규칙을 준수하는지 보장하는 린터 도입.
  2. 기존 권한을 통합하여 700개 이상의 총 권한 수를 100개 미만으로 줄이기.
  3. 각 권한에 대한 소유 그룹을 필요로 하는 권한에 대해 업데이트하는 모든 MR을 검토할 수 있도록 권한 태그를 도입.
  4. 코드에서 권한 문서를 생성하기 위한 Rake 작업 도입하여 권한에 대한 단일 진실의 원천을 갖도록 함.

대체 솔루션

아무것도 하지 않기

장점:

  • 긴장된 건축 대화나 계획이 필요하지 않음
  • 앞으로 진행하는 동안 권한 시스템을 개선하는 방법을 자연스럽게 발견할 수 있음.

단점:

  • 사용자 정의 역할 기능을 설계하기 위한 청사진 없이 권한 시스템에 대한 전략적인 비전이 없으면 진전이 느릴 수 있음.
  • 전략적으로 중요한 비전 없이 반복적으로 진행하는 경우 권한 시스템이 유지보수하기 어려운 코드로 전개될 수 있음.

현재 권한 시스템을 그대로 유지하고 사용자 정의 역할에 사용할 선언적 정책 기반 시스템을 병행하여 구축하기

장점:

  • 기존 시스템을 대규모로 리팩터링하는 것보다 새로운 시스템을 설계하고 구축하는 것이 빠름.
  • 인증팀이 이 새로운 시스템을 완전히 소유할 수 있음.

단점:

  • 2가지 시스템을 유지해야 함
  • 각 새로운 “일반” 권한 추가마다 사용자 정의 역할 시스템에 병렬로 추가되어야 함. 이로 인해 사용자 정의 역할과 기본 역할 사이의 기능 동등성을 갖추기가 어려워짐.
  • 사용자 정의 역할로 기존 RBAC 시스템을 교체하는 것이 이 접근 방식으로는 더 어려움. 왜냐하면 기존 권한 시스템을 폐기해야 하기 때문임.

기존 권한을 사용자 정의 권한으로 묶어 “사용자 정의 권한”을 사용하여 사용자 정의 역할에 사용하기

장점:

  • 기존 시스템을 대규모로 리팩터링하는 것보다 새로운 시스템을 설계하고 구축하는 것이 빠름.
  • 인증팀이 이 새로운 묶인 권한을 완전히 소유할 수 있음.

단점:

  • 권한 묶음이 덜 세분화되어 있음; 사용자 정의 권한의 목표는 세부적인 액세스를 가능하게 하는 것임.
  • 각 새로운 “일반” 권한 추가마다 사용자 정의 역할 시스템에 병렬로 추가되어야 함. 이로 인해 사용자 정의 역할과 기본 역할 사이의 기능 동등성을 갖추기가 어려움.

용어집

  • RBAC: 역할 기반 접근 제어; “개별 사용자의 역할에 기반한 네트워크 액세스를 제한하는 방법.” RBAC는 GitLab이 사용하는 액세스 제어 방법임.
  • 기본 역할: GitLab 사용자를 그룹화할 수 있는 5가지 범주: 게스트, 보고자, 개발자, 유지보수자, 소유자 (문서). 기본 역할은 권한 그룹으로 생각할 수 있음.
  • 선언적 정책: GitLab에서 사용하는 코드 라이브러리로 우리의 권한 로직을 정의함.
  • 권한: 역할을 가진 사용자가 가진 특정 능력. 예를 들어, 개발자는 MR을 생성할 수 있지만 게스트는 할 수 없음. 권한 문서에 나열된 각 행이 “권한”을 나타냄. 그러나 이러한 권한은 선언적 정책 능력과 1:1 매핑되지 않을 수 있음. 기능은 권한이 GitLab 코드베이스에서 표시되는 방식임.
  • 액세스 레벨: 기본 역할을 나타내는 정수 값으로, 그룹 계층 구조에서 사용자의 액세스를 결정하고 상속된 사용자의 액세스를 계산하는 데 사용됨 (문서).

자료