GitHub Personal Access Token 권한을 최소로 줘야 하는 이유

GitHub PAT(Personal Access Token)를 만들 때 습관적으로 repo 스코프 전체에 체크한다. 설정이 간단하고 일단 다 된다. 문제는 그 토큰이 어딘가에 노출됐을 때다.

repo 스코프는 비공개 저장소의 코드 읽기·쓰기, 웹훅 설정, 콜라보레이터 초대까지 포함한다. 내 개인 레포 전체를 상대가 읽을 수 있고, 강제 push로 커밋을 날릴 수도 있다. 그게 찝찝한 이유다.

Fine-grained PAT로 범위를 좁힌다

GitHub는 2022년 말부터 fine-grained PAT를 지원한다. 기존 classic PAT는 스코프가 뭉텅이로 나뉘어 있는 반면, fine-grained는 저장소 단위로, 그리고 액션별로 권한을 고를 수 있다.

예를 들어 CI에서 패키지를 내려받기만 하면 Contents: Read-only 하나면 충분하다. 특정 레포의 이슈에만 댓글을 달아야 한다면 그 레포만 골라서 Issues: Read and write만 주면 된다.

설정 경로:
GitHub → Settings → Developer settings
→ Personal access tokens → Fine-grained tokens

Actions secrets에 토큰을 넣을 때

GitHub Actions에서 외부 API를 호출하거나 다른 레포에 push해야 할 때 PAT를 secrets에 넣는 경우가 있다. 이때는 토큰의 만료일도 같이 신경 써야 한다.

• 만료 없는 토큰은 편하지만 위험하다. 90일 정도로 끊어두고 캘린더에 갱신 알림을 걸어둔다.
• Secrets는 fork된 PR에서는 기본적으로 전달되지 않는다. 외부 기여자의 PR이 자동으로 내 토큰을 쓸 수 없다는 뜻이다.
• GITHUB_TOKEN으로 충분한 경우에는 PAT를 새로 만들 필요가 없다. 레포 내 액션에서 쓰는 기본 토큰이라 권한이 그 레포로 제한된다.

유출됐을 때 대응

토큰이 public 레포 커밋에 노출되거나, 로그에 찍혔다는 걸 알게 된 경우 즉시 폐기해야 한다.

GitHub → Settings → Developer settings
→ 해당 토큰 선택 → Delete

GitHub는 스스로 스캔해서 토큰처럼 생긴 문자열이 커밋에 들어가면 이메일로 알려준다. 이 기능이 실제로 작동한다. 나는 한 번 .env 파일을 실수로 커밋했을 때 5분 안에 메일을 받았고, 그 토큰은 이미 비활성화돼 있었다.

권한을 넓게 주는 건 그냥 나쁜 습관이다. fine-grained PAT가 조금 불편하더라도 필요한 권한만 주는 게 맞다.