GitHub 저장소 생성 봇에 삭제 권한까지 줄 필요가 없어졌다

새 저장소를 만드는 일과 지우는 일을 분리했다

새 프로젝트가 생길 때마다 저장소를 만드는 GitHub App이라면, 그 목적만으로 삭제·이전까지 가능한 관리 권한을 받을 필요가 없어졌다. GitHub가 10월 13일 추가한 repository_creation:write는 GitHub App과 세분화된 개인 액세스 토큰에서 쓸 수 있는 생성 전용 권한이다.

앱은 자신이 생성한 저장소에 접근할 수 있다. 다만 생성 권한을 쓰는 앱의 조직 설치에는 여전히 관리자 승인이 필요하다. 권한이 작아졌다는 이유로 조직의 승인 절차가 사라지거나, 기존 앱에 있던 권한이 자동으로 줄어드는 변화는 아니다.

조직 저장소 생성 REST API도 이 구분을 반영한다. 세분화된 토큰은 Administration 쓰기 또는 Repository creation 쓰기 중 하나의 권한 세트를 사용할 수 있다. 새 저장소 생성이라는 작업을 위해 두 권한을 모두 요구하지 않는다.

저장소를 만들었다고 모든 후속 작업이 허용되지는 않는다

자동화가 빈 저장소만 만들고 끝난다면 구성이 단순하다. 하지만 템플릿을 복사하거나 초기 코드를 올리는 봇이라면 실제 수행하는 작업을 나눠 봐야 한다. 템플릿으로 생성하는 API는 생성 권한과 함께 Contents 읽기를 요구한다.

Git 접근 권한 문서는 HTTP 기반 Git 인증에 Contents, .github/workflows 파일 접근·수정에 Workflows 권한을 구분한다. 생성한 저장소가 앱의 접근 대상에 들어왔다는 사실과 그 안의 코드를 쓸 수 있다는 사실은 같은 뜻이 아니다.

사용자를 대신하는 토큰이라면 사용자의 권한도 함께 적용된다. 앱의 권한을 높였다는 이유만으로 그 사용자가 갖지 않은 권한까지 행사할 수는 없다.

기존 봇은 새 권한 승인부터 확인한다

기존 앱을 바꿀 때는 먼저 실제 호출하는 API와 Git 작업을 목록으로 만든다. 생성 이후 설정 변경까지 수행한다면 관리 권한이 다른 작업에 쓰이고 있을 수 있다. 생성 기능만 보고 Administration을 지우면 그 후속 작업이 멈출 수 있다.

설정 위치는 앱 소유 계정의 Settings → Developer settings → GitHub Apps → Edit → Permissions & events다. 권한 변경 문서에 따르면 새 저장소·조직 권한은 설치된 각 계정에서 승인해야 적용된다. 반대로 기존 권한 제거는 즉시 반영된다.

따라서 생성 전용 권한을 요청하고 설치별 승인 상태를 확인한 뒤, 통제된 환경에서 생성과 후속 작업을 검증하고 더 이상 필요 없는 관리 권한을 제거하는 순서가 적절하다. 새 권한을 추가하는 일과 기존 권한을 제거하는 일의 반영 시점이 다르기 때문이다.

줄일 수 있는 것은 봇이 실제로 하지 않는 일의 권한이다

이 권한이 가장 유용한 대상은 새 저장소를 만드는 것이 주목적인 봇이다. 저장소 삭제·이전·설정 변경까지 맡는 관리 도구는 그 작업에 필요한 권한을 계속 갖춰야 한다. GitHub도 생성 때문에만 Administration이 필요했다면 더 좁은 권한으로 바꾸라고 안내한다.

권한 축소를 마친 기준은 설정 화면에서 체크 하나가 줄었다는 사실이 아니다. 새 저장소와 필요한 초기 파일을 만들 수 있고, 맡기지 않은 관리 작업의 권한은 빠져 있어야 한다. 저장소 생성 봇의 역할을 그 범위로 한정할 수 있을 때 이번 변경의 이점도 분명해진다.