npm은 되는데 Dependabot만 미러 접속 실패? .npmrc 밖에서 허용해야 한다

토큰을 바꾸기 전에 프록시 로그를 본다

개발 PC의 npm은 패키지를 받는데 Dependabot만 실패한다면, 같은 레지스트리 주소를 쓰는지뿐 아니라 요청이 어디서 막혔는지 확인해야 한다. GitHub의 차단 호스트 문서에 따르면 Dependabot 업데이트 작업은 프록시를 거치며, 허용 목록 밖의 호스트로 보내는 요청은 403으로 거절된다.

작업 로그의 proxy | 줄에서 egress not allowlisted와 뒤에 적힌 호스트를 찾는다. 이 표시가 있다면 패키지 관리자가 인증 오류처럼 보여 주더라도 먼저 해결할 것은 호스트 허용이다. 403이라는 숫자만으로 토큰 오류와 같은 문제로 판단하면 수정할 위치를 놓치게 된다.

.npmrc는 주소를 알려 주지만 접근 허용까지 맡지는 않는다

Dependabot 레지스트리 설정 문서는 .npmrc나 nuget.config에만 정의한 호스트를 허용 대상으로 보지 않는다고 설명한다. 패키지 관리자는 그 주소로 접속을 시도하지만, Dependabot의 프록시가 별도로 요청을 검사한다.

저장소별로 설정할 때는 dependabot.yml의 최상위 registries에 선언하고 해당 updates 항목에서 참조한다. 조직 단위로 같은 미러를 쓰려면 조직의 Private registries에 등록하고 접근할 저장소를 지정할 수 있다.

읽기에 인증이 필요 없는 미러는 Anonymous로 등록한다

GitHub는 10월 12일 조직 레지스트리의 Anonymous 인증 방식을 github.com에 정식 제공했다. 임시 토큰을 넣어 형식을 맞출 필요 없이, 자격 증명을 저장하거나 전송하지 않는 레지스트리를 만들 수 있다. 보안 업데이트만 사용해 dependabot.yml이 없는 저장소에도 조직 등록을 적용할 수 있다.

조직 소유자가 UI에서 등록하는 순서는 다음과 같다.

1. 조직 Settings에서 Secrets and variables → Private registries를 연다.
2. New private registry를 선택하고 URL과 Type을 입력한다.
3. 인증 방식으로 Anonymous를 선택한다.
4. 접근을 허용할 저장소 범위를 정하고 Add Registry로 저장한다.

이미 가짜 토큰을 넣어 등록한 항목은 인증 방식만 수정할 수 없다. 기존 URL·유형·적용 저장소를 확인한 뒤 항목을 삭제하고 Anonymous로 다시 만들어야 한다. 새 설정이 필요한 저장소에 적용됐는지와 다음 업데이트 작업의 성공 여부도 확인한다.

다른 다운로드 호스트와 사설망은 따로 해결한다

등록 후에도 차단된다면 같은 로그에서 실제로 막힌 호스트를 다시 읽는다. 레지스트리가 파일 다운로드를 다른 저장소나 CDN으로 넘겨 별도 호스트가 차단될 수 있다. 조직 전용 레지스트리는 조직·저장소 설정으로 관리하고, 여러 사용자가 필요로 하는 공개 다운로드 호스트는 공식 dependabot/proxy의 공용 허용 목록에 추가를 제안하는 경로가 있다.

회사 내부망에서만 열리는 서버라면 인터넷의 Dependabot 작업이 그곳에 도달할 네트워크 경로도 필요하다. GitHub 문서는 이런 레지스트리를 위해 접근 가능한 자체 호스팅 러너에서 Dependabot을 실행하는 구성을 안내한다. Anonymous는 인증이 없는 접근을 표현하는 설정이며 사설망 연결을 만들어 주지는 않는다.

따라서 수정 순서는 로그의 차단 호스트 확인, 맞는 범위에 레지스트리 등록, 해당 저장소의 업데이트 작업 재확인이다. 호스트가 허용된 뒤에도 레지스트리 자체가 인증을 요구한다면 그때는 실제 인증 방식에 맞게 설정해야 한다.