워크플로 토큰이 저장소 전체에 쓰기 권한을 갖고 있던 것을 줄인 과정
문제 발생
빌드만 하는 워크플로의 토큰 권한을 확인해보니, 워크플로 로그에 이렇게 찍혀 있었습니다.
GITHUB_TOKEN Permissions
Actions: write
Contents: write
Packages: write
...빌드 job은 코드를 읽기만 하면 되는데, 그 토큰으로 브랜치를 지우거나 릴리스를 만들 수도 있는 상태였습니다.
원인 분석
기본값이 필요한 것보다 넓기 때문입니다. GitHub 문서의 권고는 명확합니다 — GITHUB_TOKEN의 기본 권한을 저장소 콘텐츠에 대한 읽기 전용으로 설정하는 것이 좋은 보안 관행이며, 이후 워크플로 파일 안에서 개별 job에 대해 필요한 만큼 권한을 올리면 됩니다.
넓은 권한이 위험한 이유는 워크플로가 실행하는 코드가 우리가 다 읽어본 코드가 아니기 때문입니다. 서드파티 액션, npm 의존성의 postinstall, 빌드 스크립트가 모두 그 토큰이 있는 환경에서 돕니다.
문서는 시크릿 전반에 대해서도 같은 원칙을 적습니다 — 저장소에 쓰기 권한이 있는 모든 사용자는 저장소에 설정된 모든 시크릿에 읽기 접근을 갖게 되므로, 워크플로에서 사용하는 자격증명은 필요한 최소 권한만 갖도록 해야 합니다.
해결 방안
- 워크플로 최상단을 읽기 전용으로 고정합니다.
permissions:
contents: read- 필요한 job에서만 올립니다. 릴리스를 만드는 job에만
contents: write, 이미지를 올리는 job에만packages: write를 줍니다.
jobs:
release:
permissions:
contents: write-
아무 권한도 필요 없는 job은 비웁니다.
permissions: {}로 두면 토큰이 사실상 아무것도 못 합니다. -
조직 기본값도 함께 바꿉니다. 저장소마다 잊지 않고 적는 것보다, 조직/저장소 설정의 기본 권한을 읽기 전용으로 두는 편이 확실합니다.
-
장기 PAT를 쓰고 있다면 대체를 검토합니다.
GITHUB_TOKEN은 job이 끝나면 만료되지만, PAT는 어딘가에 계속 살아 있습니다. 클라우드 배포라면 OIDC로 시크릿 자체를 없애는 방향이 더 낫습니다. -
실제 로그로 확인합니다. 워크플로 실행 로그의 "GITHUB_TOKEN Permissions" 블록이 지금 상태를 그대로 보여줍니다 — 설정을 바꾼 뒤 여기서 확인합니다.
댓글0
댓글을 남기려면 로그인이 필요해요. 로그인
아직 댓글이 없어요. 첫 의견을 편하게 남겨 보세요.