권한 규칙

GitLab에서 새로운 권한을 도입하고 명명하는 규칙 및 비공개 권한 사용 방법을 설명합니다.

새로운 권한 도입 # 새 권한은 반드시 필요할 때만 도입합니다. 항상 기존 권한을 먼저 사용해 봅니다. 예를 들어 이미 read_issue 가 있고 두 권한이 요구하는 접근 수준이 같다면 read_issue_description 권한은 필요하지 않습니다. 일반적인 지침으로, 주체와 행위가 같다면 권한을 재사용할 수 있습니다. 앞의 예에서 주체는 issue 이고 행위는 read 입니다. 사용자가 읽을 수 있는 이슈의 속성마다 새 권한을 만들 필요는 없습니다. 권한을 도입해야 하는 예는 admin_project 처럼 권한 범위가 매우 넓은 경우입니다. 이 경우 권한이 모호하며 프로젝트 메인테이너에게 부여됩니다. 이론상 이 권한은 CI/CD 변수 관리 기능이 메인테이너에게 부여되므로 프로젝트에서 CI/CD 변수를 관리하는 접근을 제어하는 데 쓸 수 있습니다. 다만 범위가 넓은 권한을 사용하면 권한 검사만 보아서는 무엇을 인가하는지 분명하지 않습니다. 또한 admin_cicd_variable 이나 manage_cicd_variable 같은 권한은 인가되는 행위가 여러 가지임을 함의하므로 피해야 합니다. 대신 행위는 create_cicd_variable 이나 read_cicd_variable 처럼 구체적이어야 합니다. 세분화된 권한을 구현하면 커스텀 역할에서 최소 권한 원칙을 지킬 수 있고 표준 역할에도 훨씬 세밀한 선택지를 제공합니다. 새 권한은 최소 권한 원칙을 뒷받침해야 합니다. 단일 리소스에 대한 하나의 명확히 정의된 행위에 필요한 접근만 부여해야 하며 그 이상은 안 됩니다. 제안된 권한이 둘 이상의 행위에 대한 접근을 부여하거나 서로 무관한 기능을 묶는다면 별개의 권한으로 분리합니다. 권한을 이만큼 좁게 한정할 수 없다면 도입하기 전에 설계를 다시 검토합니다. 권한은 역할 정의 YAML 파일 (기본 역할용), 커스텀 어빌리티 YAML 파일 (커스텀 역할용), 할당 가능 권한 그룹 (세분화된 PAT 스코프 지정용)에서 참조됩니다. 권한 명명 # 모든 권한이 action_resource(_subresource) 라는 일관된 패턴을 따르도록 하는 것이 목표입니다. 이 지침은 Assignable Permissions와 Raw Permissions 모두에 적용되지만, Assignable Permissions는 외부에 공개되므로 더 엄격하게 지켜야 합니다. 선호 행위(Actions) # 새 권한을 도입한다면 다음 행위 중 하나를 사용하는 것이 좋습니다. 행위 기능 예시 create 새 객체를 생성합니다 create_issue read 객체를 조회하거나 검색합니다 read_project update 기존 객체를 수정합니다 update_merge_request delete 객체를 제거합니다 delete_issue 이 행위 집합이 제한적이며 모든 기능에 적용되지는 않는다는 점을 인지하고 있습니다. 상황에 따라 이 집합 밖의 행위도 허용 되지만 Authorization 팀 의 승인이 필요합니다. 허용되지 않는 행위(Actions) # 다음 행위 패턴은 권