GitHub Actions 허용 목록, 새 저장소 호스트 120개 추가

호스트를 하나씩 등록한 네트워크가 점검 대상이다

GitHub의 변경 공지는 github.com의 Actions blob 저장소를 사용하는 조직에 접속 허용 목록을 확인하도록 안내한다. 작업 요약과 로그가 새 저장소로 오갈 때 통신이 막히는 일을 예방하기 위한 변경이다.

이미 productionresultssa*.blob.core.windows.net을 허용한다면 이번 호스트 추가 때문에 규칙을 바꿀 필요는 없다. 호스트 이름을 개별 등록하는 방식이라면 새 주소를 반영해야 한다. 이는 허용 방식에 따른 차이이며 모든 조직에 동일한 방화벽 변경을 요구하는 공지가 아니다.

30~49번과 100~199번, 양 끝을 모두 포함한다

추가 대상은 연속된 하나의 범위가 아니라 두 묶음이다. 아래 첫 묶음은 20개, 둘째는 100개로 합계 120개다.

120개는 이번에 발표한 두 범위의 합계다. Actions 전체 엔드포인트 수가 아니며, 두 구간 사이의 50~99번을 이번 추가 목록에 포함해서도 안 된다.

문서 예시 대신 현재 Meta API를 조회한다

GitHub Meta API는 서비스의 IP 주소뿐 아니라 도메인 정보도 제공한다. 다음은 공개 메타데이터를 조회하는 읽기 전용 요청 예시다.

curl -L -H "Accept: application/vnd.github+json" https://api.github.com/meta

이 공개 자료 조회에는 인증이 필요하지 않다. GitHub 문서도 응답 예시의 값을 그대로 쓰지 말고 API에 직접 요청해 최신 값을 받도록 명시한다. 예시 코드를 실행한다고 방화벽 규칙이 자동 갱신되는 것은 아니다.

IP 주소 안내에는 IP 기반 허용 목록의 한계도 나와 있다. Meta API의 IP 목록은 모든 GitHub 서비스를 빠짐없이 포함하는 목록이 아니다. GitHub는 IP 주소 기반 허용을 권장하지 않으며, 해당 방식을 쓰면 API를 정기적으로 살피도록 권고한다. IP 대역만 복사하는 것과 이번 공지의 저장소 도메인을 허용하는 것은 같은 작업이 아니다.

runner 연결과 결과 전송은 따로 확인해야 한다

자체 호스팅 runner 문서는 기본 동작에 필요한 도메인과 결과 전송에 필요한 도메인을 구분한다. 작업 요약·로그·아티팩트·캐시 업로드 및 다운로드에는 results-receiver.actions.githubusercontent.com과 *.blob.core.windows.net을 제시한다.

이번에 추가된 호스트를 반영했다는 사실만으로 runner의 모든 통신 요건을 충족했다고 판단할 수는 없다. 일부 도메인은 CNAME을 사용하며, 방화벽에 따라 그 대상까지 따라가며 규칙을 추가해야 할 수 있다.

운영 담당자는 현재 허용 방식이 개별 호스트인지 패턴인지 확인하고, 누락된 호스트를 추가한 뒤 실제 작업의 로그와 요약이 전달되는지 확인하는 순서로 점검할 수 있다. runner가 작업을 받아 실행했다는 사실과 결과가 정상적으로 저장됐다는 사실을 각각 확인해야 한다.

자주 묻는 질문

이번 점검의 출발점은 기존 허용 규칙의 방식이다. 개별 목록이라면 두 범위를 반영하고, 결과 전송까지 확인해야 한다.