왜 이걸 고려해야 할까?
프로젝트에 개발팀이 하나만 있으면 상관 없지만 여러 개발팀이 참여하고 각각의 권한을 repo 별로 따로따로 가져가야 하는 경우가 발생한다.
현재 진행하고 있는 프로젝트에서 개발팀만 2곳 + 다른 파티들 까지 합치면 총 5파티가 한 프로젝트 안에서 부대끼며 프로젝트를 진행하고 있다. 특히나 개발팀들이 각각 다른 회사라 안에 들어간 코드를 서로 보게 하는건 상도덕상 또는 정책상 문제가 있어 보인다.
말로만 해야된다 하지말고, 그럼 이걸 어떻게 해?
repo 별로 어떻게 권한 부여를 할까?
기본 현 상황 파악
organization에 유저 추가하며, 해당 인원이 참여할 project를 선택하면, 해당 유저는 assign 되자마자 프로젝트 안의 모든 repo들을 들여다 보고 contirubuting 또한 가능하다. 어떻게 이게 가능한걸까?
1. 유저가 project에 추가되면 자동으로 contributor group으로 등록된다.
2. project의 기본 repo security에 contributor는, 전체 repo에 대해 자동으로 등록 되어져 있다.
위의 빨간 박스 안의 아이들은 프로젝트 생성되면 기본적으로 추가되는 그룹들이다.
3. contributor가 가지고 있는 기본 권한은 아래와 같이 그냥 바로 repo 투어 뿐만 아니라 contributing 또한 가능하다.
위와 같은 순서로 진행되기에, 새로운 유저가 추가 되었을 때, 추가된 유저는 모든 repo에 대하여 개발자 권한을 행사할 수 있다.
방향성
가장 편한 방법은 2가지가 있다.
- 전체 repo 대상의 repo security에서 contributor를 삭제한다.
- 전체 repo 대상의 repo security에서 contributor의 권한을 전부 not set으로 지정한다.
not set 관련하여 정확하게 파악하기 위해 검색을 조금 진행했다. 권한 관련하여 not set, allow, deny 총 3개의 선택지가 제공되며 not set은 보통 상위 그룹이나 팀의 설정을 상속 받을 때 많이 사용한다. 만약 상속받을 설정이 없으면 not set은 allow인지 deny인지는 아래와 같이 설명되어 있다.
그럼 위의 contributor를 전부 not set으로 하는 부분도 나쁘지 않아 보인다.
내가 선택한 방법은 2번 이다. 이유는 contributor가 들어가는게 default여서 지우기 싫은것도 있지만, 혹시 모를 상황에 자동으로 모든 사람이 다 추가되어 있는 그룹 하나 가지고 있으면 나중에 유용하게 사용될 일이 있지 않을까 라는 부분 때문이었다.
예를 들어 pipeline 설정의 오류로 tag를 만들면 안되는 경우, project 전체에 contributor에다가 create tag를 deny 한다거나... 다양한 시나리오가 가능하다. (allow와 deny 설정을 같이 상속 받을 경우, deny가 우선순위인 것을 보았었다.)
추가적으로, 각 개발 파티마다 팀을 만들어 주고 해당 팀을 각 repo security에 필요한 권한을 주는 형태로 쓰고 있다. pr 이후 merge 시 approver는 각 개발 파티의 책임자로 해놓았으며, 책임자 부재시 pr override를 위해 bypassing policy 옵션도 사용중이다.
예를 들자면 아래와 같다.
- contributor는 모두 not set
- 개발 파티 A contribute 관련 권한은 allow
- create tag만 not set (main base로 tagging 시 운영에 배포되게 devops 전략을 구성하였다.)
- 개발 파티 A의 책임자 1명을 따로 repo security에 등록하여 create tag를 allow (개발 파티 A의 멤버로 책임자 또한 포함되어 있음)
위와 같이 설정하면, 개발 파티 A에서 책임자만 create tag 권한을 가지고 있을 수 있다.
마치며
방법은 너무 많을 것이다. 방법을 찾았으니 권한을 최소한으로만 부여하여 사고를 미연에 방지하자!!
