권한 규칙
역사적 맥락
우리는 GitLab에서 DeclarativePolicy 프레임워크를 사용하여 권한 부여를 수행하며, 새로운 권한을 추가하는 것을 간단하게 만듭니다. 2024년까지 새로운 권한을 도입할 시기와 이름을 짓는 방법에 대한 명확한 지침이 없었습니다. 이러한 방향 부족이 권한 수가 관리 불가능한 주요 이유 중 하나입니다.
이 문서의 목적은 다음에 대한 지침을 제공하는 것입니다:
- 새로운 권한을 도입할 시기와 기존 권한을 재사용할 시기
- 새로운 권한의 이름을 짓는 방법
-
Policy클래스에 포함해야 할 내용과 포함하지 말아야 할 내용
새로운 권한 도입하기
정말로 필요한 경우에만 새로운 권한을 도입하세요. 항상 먼저 기존 권한을 사용하려고 노력하세요. 예를 들어, 이미 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로 재구성할 수 있습니다.
선호 동사
-
create는build나import보다 선호됩니다. -
read는access보다 선호됩니다. -
push는upload보다 선호됩니다.
예외
이러한 규칙을 따르지 않는 새로운 권한이 필요하다고 생각되면 Govern:Authorization 팀에 상담하세요. 우리는 항상 논의에 열려 있으며, 이러한 가이드라인은 엔지니어들의 작업을 더 쉽게 하기 위한 것이지 복잡하게 만들기 위한 것이 아닙니다.
정책 클래스에 포함할 내용
역할
정책 클래스는 미리 정의된 역할과 사용자 정의 역할에 대한 검사를 포함해야 합니다.
예시:
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
도움말