권한 규칙
역사적 맥락
우리는 GitLab에서 권한에 대한 선언적 규칙 프레임워크(DeclarativePolicy)를 활용하여 새로운 권한을 쉽게 추가할 수 있습니다. 2024년까지 새로운 권한을 도입할 때와 그들의 이름을 지을 때에 대한 명확한 안내가 없었습니다. 이러한 부족한 내용은 권한의 수가 관리하기 힘든 이유 중 하나입니다.
이 문서의 목적은 다음에 대한 지침을 제공하는 것입니다.
- 새로운 권한을 도입할 때와 기존 권한을 재사용할 때
- 새로운 권한의 이름 짓는 방법
- Policy 클래스에 포함해야 하는 항목과 포함하지 말아야 하는 항목
새로운 권한 도입
절대적으로 필요할 때에만 새로운 권한을 도입합니다. 우선 기존 권한을 사용해 보세요. 예를 들어, read_issue가 필요한데 이미 read_issue가 있는 경우 read_issue_description 권한은 필요하지 않습니다. 둘 다 같은 역할을 요구합니다. 마찬가지로, create_pipeline을 사용할 수 있는 상황에서 create_build는 필요하지 않습니다.
새로운 권한을 도입할 때는 항상 이름 짓는 규칙을 따르도록 노력하세요. 특정한 것이 아닌 일반적인 권한을 만드는 것이 좋습니다. 예를 들어 create_member_role_name보다는 create_member_role 권한을 추가하는 것이 더 나은 방법입니다. 확신이 들지 않는다면 Govern:Authorization 팀의 백엔드 엔지니어에게 조언이나 예외의 승인을 상의하세요.
권한 이름 지어주기
우리의 목표는 모든 권한이 일관된 패턴을 따르는 것입니다: 동사-기능(-하위기능). 기능과 하위 기능은 항상 단수형이어야 합니다. 또한 명확성을 위해 사용되는 동사를 제한하는 것이 목표입니다. 선호되는 동사는 다음과 같습니다.
-
create- 객체를 만들 때 사용, 예:create_issue -
read- 객체를 읽을 때 사용, 예:read_issue. -
update- 객체를 업데이트할 때 사용, 예:update_issue. -
delete- 객체를 삭제할 때 사용, 예:delete_issue. -
push와download- 이는 파일 관련 권한을 위한 구체적인 동사입니다. 타업계용어는 정당화 후 허용될 수 있습니다.
이 동사들의 집합이 제한적이며 모든 기능에 적용되지 않을 수 있다는 것을 인지합니다. 아래는 필요하지만 위의 규칙에 부합되도록 다시 표현될 수 있는 일부 동사입니다.
-
approve- 예:approve_merge_request.approve는manage보다 낮은 역할을 나타내지만,create_merge_request_approval로 다시 표현될 수 있습니다.
선호되는 동사
-
build나import보다create를 선호합니다. -
access보다read를 선호합니다. -
upload보다push를 선호합니다.
예외사항
이 규칙을 따르지 않는 새로운 권한이 필요하다고 생각된다면 Govern:Authorization 팀과 상의하세요. 논의를 항상 열어놓고 있으며, 이러한 지침은 엔지니어의 작업을 어렵게 하는 것이 아니라 쉽게 하는 것을 목적으로 합니다.
Policy 클래스에 포함해야 하는 내용
역할
Policy 클래스에는 사전 정의된 역할뿐만 아니라 사용자 정의 역할에 대한 확인을 포함해야 합니다.
예시:
rule { developer } # 정적 역할 확인
rule { can?(:developer_access) } # 일부 클래스에서 사용되는 다른 접근
rule { custom_role_enables_read_dependency } # 사용자 정의 역할 확인
현재 사용자에 관련된 확인
현재 사용자와 객체의 관계에 따라 다양한 확인을 포함해야 합니다. 예를 들어 해당 사용자가 담당자나 작성자인 경우 등.
예시:
rule { is_author }.policy do
enable :read_note
enable :update_note
enable :delete_note
end
도움말