권한 규칙

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

새로운 권한 도입 # 새로운 권한은 절대적으로 필요한 경우에만 도입합니다. 항상 기존 권한을 먼저 사용하려고 시도하세요. 예를 들어, 이미 read_issue 가 있고 두 권한 모두 동일한 수준의 접근을 요구한다면 read_issue_description 권한을 새로 만들 필요가 없습니다. 일반 지침으로, 주체(subject)와 행위(action)가 동일한 경우 권한을 재사용할 수 있습니다. 앞의 예시에서 주체는 issue 이고 행위는 read 입니다. 사용자가 읽을 수 있는 이슈의 각 속성마다 새로운 권한을 만들 필요는 없습니다. 새로운 권한을 도입해야 하는 예시는 admin_project 처럼 권한 범위가 매우 광범위한 경우입니다. 이 경우 권한이 모호하며 프로젝트 Maintainer에게 부여됩니다. 이론적으로 이 권한은 Maintainer에게 해당 기능이 부여되므로 프로젝트의 CI/CD 변수 관리 접근을 제어하는 데 사용될 수 있습니다. 그러나 광범위한 권한을 사용할 때 권한 검사를 보면 무엇을 인가(authorize)하는지 명확하지 않습니다. 또한 admin_cicd_variable 이나 manage_cicd_variable 과 같은 권한은 인가되는 서로 다른 행위를 암시하므로 사용을 피해야 합니다. 대신 create_cicd_variable 이나 read_cicd_variable 처럼 행위가 구체적이어야 합니다. 세분화된 권한을 구현하면 커스텀 역할에 대한 최소 권한 원칙을 준수할 수 있고, 표준 역할에 대해 훨씬 더 세밀한 옵션을 제공합니다. 새로운 권한은 최소 권한 원칙을 지원해야 합니다. 단일 리소스에 대해 단일하고 명확하게 정의된 행위에 필요한 접근만 부여해야 하며, 그 이상은 안 됩니다. 제안된 권한이 두 개 이상의 행위에 접근을 부여하거나 관련 없는 기능을 묶는 경우, 별도의 권한으로 분리하세요. 이렇게 좁은 범위로 권한을 지정할 수 없다면, 도입 전에 설계를 재검토하세요. 권한은 역할 정의 YAML 파일 (기본 역할의 경우), 커스텀 ability YAML 파일 (커스텀 역할의 경우), 그리고 할당 가능한 권한 그룹 (세분화된 PAT 범위 지정의 경우)에서 참조됩니다. 권한 명명 # 모든 권한이 일관된 패턴인 action_resource(_subresource) 를 따르는 것이 목표입니다. 이 지침은 할당 가능한 권한(Assignable Permissions)과 원시 권한(Raw Permissions) 모두에 적용되지만, 공개 facing인 할당 가능한 권한에서 가장 엄격하게 준수되어야 합니다. 선호 행위(Actions) # 새로운 권한을 도입할 때는 다음 행위 중 하나를 사용하는 것을 선호합니다: 행위 기능 예시 create 새 객체를 생성함 create_issue read 객체를 조회하거나 검색함 read_project update 기존 객체를 수정함 update_merge_request delete 객체를 제거함 delete_issue 이 행위 집합이 제한적이며 모든 기능에 적용 가능하지 않다는 것을 인식하고