권한 규칙
역사적 맥락
우리는 GitLab에서 권한에 대한 DeclarativePolicy 프레임워크를 활용하여 새로운 권한을 추가하기 쉽게 만들었습니다. 2024년까지 새로운 권한을 도입할 때와 명명하는 방법에 대한 명확한 안내가 없었습니다. 이러한 방향성 부족은 권한의 수가 관리하기 어렵게 만든 중요한 이유입니다.
이 문서의 목적은 다음과 같은 지침을 제공하는 것입니다:
- 언제 새로운 권한을 도입하고 기존 권한을 재사용해야 하는지
- 새로운 권한을 명명하는 방법
- Policy 클래스에 포함해야 하는 내용 및 포함해서는 안 되는 내용
새로운 권한 도입
절대적으로 필요할 때에만 새로운 권한을 도입합니다. 먼저 기존 권한을 사용해 보세요. 예를 들어 read_issue가 이미 있는 경우에는 read_issue_description 권한이 필요하지 않습니다. 둘 다 같은 역할을 요구합니다. 마찬가지로 create_pipeline이 있는 경우 create_build는 필요하지 않습니다.
새로운 권한을 도입할 때는 항상 명명 규칙을 따르려고 노력하세요. 구체적인 것이 아닌 일반적인 권한을 추가하는 것이 좋습니다. 예를 들어, create_member_role_name보다는 create_member_role 권한을 추가하는 것이 좋습니다. 확신이 없는 경우 Govern:Authorization 팀의 Backend 엔지니어에게 상담하거나 예외에 대한 승인을 받으세요.
권한 명명
모든 권한이 일관된 패턴을 따르는 것이 목표입니다: 동사-기능(-하위기능). 기능과 하위 기능은 항상 단수형이어야 합니다. 또한 명료성을 위해 사용하는 동사를 제한하려고 노력합니다. 선호하는 동사는 다음과 같습니다:
-
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
도움말