GitHub 앱 기업 설치, 모든 저장소 권한까지 얻을까?

세 줄 요약

기업 정책과 보안 설정을 앱으로 관리할 범위가 넓어졌다

GitHub의 10월 23일 발표는 기업 계정에 설치한 앱이 처리할 수 있는 API를 늘렸다. 기업 수준 저장소 정책·ruleset, 2단계 인증 요구 사항, 도메인 확인, IP 허용 목록, 접근 제한 등이 포함된다.

이 변화로 기존 classic PAT, 즉 개인 액세스 토큰에 의존하던 관리 작업 일부를 앱으로 옮길 수 있다. 기업 정책이 조직 전체에 영향을 미친다고 해서 앱에 각 저장소의 코드 접근 권한까지 생기는 것은 아니다.

GitHub Enterprise Server는 별도 일정이다. 발표는 이번 확장이 GHES 3.24에 제공될 예정이라고 명시한다.

기업에 앱을 설치할 수 있는 사람은 enterprise owner다. 앱 관리자라는 역할만으로는 부족하다. 앱이 조직·저장소 권한도 요청하더라도 기업 계정에 설치하는 단계에서는 기업 권한만 부여된다.

하려는 일	필요한 접근 범위
기업 수준 관리 작업	기업 설치와 해당 기업 권한이 필요하다.
특정 조직·저장소 자원 접근	해당 조직에 별도 설치하고 필요한 권한을 부여해야 한다.
설치 토큰으로 여러 계정 접근	설치 토큰은 특정 기업 또는 조직에 묶이므로 계정 경계를 넘지 못한다.

GraphQL 가이드도 이 경계를 명시한다. 예를 들어 기업 하나와 조직 두 곳에 앱이 설치됐다면 각 설치를 위한 토큰이 따로 필요하다. 중앙에서 앱을 관리하는 것과 모든 자원을 하나의 토큰으로 읽는 것은 다르다.

먼저 자동화가 호출하는 API가 GitHub Apps를 지원하는지 봐야 한다. GitHub는 지원되는 기업 GraphQL 작업에 앱 사용을 권장하지만, 모든 쿼리와 변경 작업이 앱 인증을 지원하는 것은 아니라고 설명한다. 미지원 작업에는 PAT가 필요하다.

앱의 설치 액세스 토큰과 사용자 액세스 토큰도 구별해야 한다. 전자는 특정 설치 계정에 묶인다. 사용자를 대신하는 후자는 사용자와 앱이 모두 접근할 수 있는 권한·자원 범위에서 작동한다. 사용자 토큰을 택한다고 앱에 없는 조직 접근 권한이 생기지는 않는다.

따라서 이관 목록에는 호출 API, 필요한 권한, 설치 대상, 인증 방식을 함께 적는 편이 낫다. ‘PAT를 쓰던 스크립트’라는 공통점만으로 토큰을 일괄 교체하기는 어렵다.

GitHub의 조직별 설치 자동화 예제는 앱 두 개로 역할을 나눈다. 기업 계정에 설치한 첫 앱은 다른 앱을 조직에 설치한다. 두 번째 앱은 조직 설치 토큰을 받아 그 조직에서 저장소 생성 같은 작업을 한다.

기업 토큰은 설치를 진행하고 조직 토큰은 조직 안의 작업을 수행한다. 여러 조직에 같은 자동화를 배포해도 각 토큰은 지정된 계정과 권한 범위 안에서만 사용할 수 있다. 두 앱은 공식 예제의 설계이며 모든 자동화에 강제되는 구성은 아니다.

이번 출시를 적용할 출발점은 기업 수준 관리 작업 중 앱 지원이 추가된 API를 고르는 것이다. 조직·저장소를 만지는 작업은 별도 설치와 권한을 확인한 뒤 같은 이관 계획에 넣어야 한다.

기업에 한 번 설치하면 모든 비공개 저장소를 읽을 수 있나?

아니다. 필요한 조직에 별도로 설치하고 저장소 접근 권한을 부여해야 한다.

이제 classic PAT를 전부 없애도 되나?

모든 기업 API가 앱 인증을 지원하지는 않는다. 자동화가 호출하는 작업별로 지원 여부를 구분해야 한다.

기존 GitHub CLI 자동 갱신 토큰과 같은 기능인가?

아니다. 이번 발표는 기업 계정에 설치한 GitHub App의 권한·API 지원에 관한 것이다.