• 요약
• 사용자 지정 역할이란?
• 동기
  • 목표
  • 비목표
• 제안
• 대안 솔루션
  • 아무것도 하지 않음
  • 현재 권한 시스템을 그대로 두고 사용자 정의 역할을 위해 병렬적으로 Declarative Policy 기반 시스템을 구축
  • 기존 권한을 사용자 정의 권한으로 번들화하고 사용자 정의 역할 API에 “사용자 정의 권한”을 사용
• 용어 해설
• 자원

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

요약

오늘날, 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 code 및 admin merge requests가 활성화되어 있지만 admin issues와 같은 기능은 비활성화될 수 있습니다.

동기

이 계획을 명확히 정의하는 것은 사용자 정의 역할 프로젝트의 현재 아키텍처가 현재의 권한 시스템인 Declarative Policy에 바탕을 두고 있기 때문에 중요합니다. Declarative Policy를 사용하면 새로운 권한을 추가하는 데 많은 비용을 지출하지 않게 되었으며, 이로 인해 현재 상태에서 700개 이상의 권한이 ‘gitlab-org/gitlab’ 코드베이스에 있는 결과가 되었습니다. 심지어 권한 관련 문서에는 200개 이상의 행을 포함한 표가 있었습니다. 각 행은 “권한”을 나타냅니다. 지금까지 코드에서 권한이 증식됨에 따라 관리가 가능했지만, 이러한 확인 항목들은 공개 API의 일부가 아니었습니다. 그러나 사용자 정의 역할에서는 이것이 변화하게 됩니다.

현재의 권한 확인은 자주 중복되어 애플리케이션 코드 전체에 흩어져 있습니다. 단일 웹 요청에 대해 UI에서 사용자가 페이지 요소를 볼 수 있는지 여부를 결정하기 위해 여러 다른 권한이 확인되며, 또한 Rails 컨트롤러에서 사용자가 경로에 액세스할 수 있는지를 결정하는 데도 몇 가지 권한 확인 사항이 있으며, 페이지 로드의 일환으로 실행되는 다른 Ruby 서비스 클래스에도 몇 가지 권한 확인 사항이 더 추가될 수 있습니다. 이 접근 방식은 GitLab 개발자 문서에서 권장되는 ‘깊이 방어’ 조치로 나타납니다.

그러나 사용자 정의 역할의 경우, 이 접근 방식은 작동하지 않게 될 것입니다. 그룹 관리자가 사용자에게 사용자 정의 역할을 통해 단일 조치를 취할 수 있도록 하려면 그룹 관리자는 단일하고 명확한 권한을 전환할 수 있어야 합니다. 따라서 단일 웹 요청에 대해 단일하고 명확한 권한만 확인되도록 해야 합니다. 그리고 해당 권한에 대한 액세스는 비교적 안정되어야 하여 관리자가 생각하는 것보다 사용자에게 더 많은 액세스를 부여하지 않도록 합니다. 그렇지 않으면 사용자 정의 역할의 생성 및 관리가 지나치게 복잡하고 보안 문제가 발생할 수 있습니다.

권한은 Auth 그룹이 기능을 소유하지만, 각 팀은 해당 도메인 영역과 관련된 권한 세트를 소유합니다. ‘gitlab-org/gitlab’ 코드베이스의 근본에 위치해 있습니다. 따라서 ‘gitlab-org/gitlab’ 코드베이스에 기여하는 모든 엔지니어링 팀은 권한을 건드립니다. 이는 권한의 미래에 대한 명확한 지침을 제공하고 이러한 지침의 자동 시행을 위해 더 중요함을 의미합니다.

목표

• 사용자 정의 역할을 통해 모든 권한을 사용자 정의할 수 있도록 만듭니다.
• GitLab 권한 시스템을 공개 API로 사용할 수 있도록 개선합니다.
• 권한의 명칭과 일관성을 개선합니다.
• 700개 이상의 권한을 < 100개 미만으로 줄입니다.
• 권한과 관련된 재구성의 위험을 줄입니다.
• 단위 테스트 및 문서 외에도 동작을 평가할 수 있는 방법을 갖춤으로써 권한 재구성을 쉽게 만듭니다.
• 개별 권한의 소유를 추적하여 해당 소유자(DRIs)가 소유한 권한과 관련된 변경사항에 대해 상담을 받을 수 있도록 합니다.
• 권한 동작의 단일 근원지(Single Source of Truth, SSoT)를 생성합니다.
• 권한 문서의 생성을 자동화합니다.

비목표

• 기존 권한 시스템을 재구성하는 동안 사용자 정의 역할 프로젝트를 무기한으로 일시 중지합니다(이것은 Ultimate 기능으로서 높은 수요가 있습니다).
• 기존 권한 시스템의 총재작성 또는 재구축을 수행하지 않습니다(고객 가치를 제공하지 않고 미적인 투자가 많이 들어갑니다).
• 기존 권한 시스템을 재작성하거나 새로이 빌드하지 않습니다(사양없는 반복적인 작업).

제안

1. 모든 새 권한이 명명 규칙을 준수하는지 확인하는 린터를 도입합니다.
2. 기존 권한을 통합하여 700개 이상의 권한을 < 100개 미만으로 줄입니다.
3. 각 권한에 대해 소유 그룹을 요구하는 소유 태그를 도입합니다. 이렇게 함으로써 해당 권한을 업데이트하는 모든 MR을 검토해야 합니다.
4. 코드에서 권한에 대한 문서를 생성하는 Rake 작업을 만듭니다. 이렇게 하면 권한에 대한 단일 근원지가 생기게 됩니다.

대안 솔루션

아무것도 하지 않음

장점:

• 장기적인 아키텍처 대화나 계획이 필요하지 않음
• 전환하면서 권한 시스템을 개선하는 방법을 자연스럽게 발견할 수 있음.

단점:

• 전반적으로 사용자 정의 역할 기능을 구축하는 데 확고한 비전이 없이 권한 시스템을 고민할 경우 진행이 느려짐
• 권한 시스템이 전략적으로 중요한 비젼 없이 개선될 경우 관리할 수 없는 코드로 전개될 수 있습니다.

현재 권한 시스템을 그대로 두고 사용자 정의 역할을 위해 병렬적으로 Declarative Policy 기반 시스템을 구축

장점:

• 기존 시스템을 대대로 재구성하는 것보다 새로운 시스템을 설계하고 구축하는 것이 빠른 시가지를 차지함.
• 인증 팀이이 새 시스템을 완전히 소유 가능합니다.

단점:

• 2개의 시스템 유지/보수
• 각 새 “일반” 권한을 추가할 때마다 이를 사용자 정의 역할 시스템에 병렬로 추가해야 합니다. 이로 인해 사용자 정의 역할과 기본 역할 간의 기능 동등성을 유지하기가 어려워집니다.
• 기존의 RBAC 시스템을 사용자 정의 역할로 대체하는 것은 더욱 어려워집니다. 왜냐하면 기존의 권한 시스템을 폐기해야 하기 때문입니다.

기존 권한을 사용자 정의 권한으로 번들화하고 사용자 정의 역할 API에 “사용자 정의 권한”을 사용

장점:

• 기존 시스템을 대대로 재구성하는 것보다 새로운 시스템을 설계하고 구축하는 것이 빠른 시가지를 차지함.
• Auth 팀은 이러한 번들 권한을 완전히 소유할 수 있습니다.

단점:

• 권한 번들을 한결같이 사용하는 것은 덜 구체적입니다. 사용자 지정 권한의 목표는 세부적인 액세스를 활성화하는 것입니다.
• 각 새로운 “일반” 권한을 추가할 때마다 이를 사용자 정의 역할 시스템에 번들 권한을 병렬로 추가해야 합니다. 이로 인해 사용자 정의 역할과 기본 역할 간의 기능 동등성을 유지하기가 어려워집니다.

용어 해설

• RBAC: Role-based access control; “개별 사용자의 역할에 따라 네트워크 접근을 제한하는 방법”입니다. RBAC는 GitLab이 사용하는 접근 제어 방법입니다.
• 기본 역할: GitLab 사용자가 그룹화될 수 있는 5가지 카테고리: Guest, Reporter, Developer, Maintainer, Owner (문서). 기본 역할은 권한 그룹으로 생각할 수 있습니다.
• 선언적 정책: GitLab에서 사용하는 코드 라이브러리로, 권한 부여 논리를 정의합니다.
• 권한: 역할을 가진 사용자가 가지고 있는 특정 능력입니다. 예를 들어 Developer는 Merge Request을 생성할 수 있지만 Guest는 할 수 없습니다. 권한 문서에 나열된 각 행은 “권한”을 나타내지만, 이것들은 선언적 정책 능력과 1:1 매핑되지 않을 수 있습니다. 능력은 권한이 GitLab 코드베이스에서 표현되는 방식입니다.
• 접근 수준: 기본 역할을 나타내는 정수 값으로, 그룹 계층 구조에서의 사용자 접근을 결정하고 상속된 사용자 접근을 계산하는 데 사용됩니다 (문서).

자원

• 사용자 정의 역할 MVC 발표
• 사용자 정의 역할 lunch and learn 노트
• 권한에 대한 자동 생성 문서 발견.