- Published on
GitHub Actions ARC 운영 가이드: Ephemeral Runner, Scale Set, 보안 경계
- Authors
- Name
- Youngju Kim
- @fjvbn20031
- 들어가며
- 왜 Ephemeral Runner가 기본값에 가까운가
- Scale Set 경계는 workload와 trust boundary 기준으로 나눈다
- 보안은 runner 자체보다 주변 경계가 좌우한다
- 이미지 전략은 "빠른 시작"과 "깨끗한 실행" 사이 균형이다
- 네트워크와 시크릿은 최소 권한 원칙으로
- 운영 지표와 체크리스트
- 흔한 안티패턴
- 마무리
- References
들어가며
GitHub Actions를 조직 규모로 운영하기 시작하면 self-hosted runner는 단순 비용 절감 수단이 아니라 실행 격리와 보안 경계를 설계하는 인프라가 됩니다. 특히 Kubernetes 환경에서는 Actions Runner Controller, ARC를 쓰는 순간 다음 질문이 중요해집니다.
- runner를 장수형으로 둘 것인가, ephemeral로 둘 것인가
- scale set은 조직별, 저장소별, workload별로 어떻게 나눌 것인가
- 빌드 이미지, 캐시, 시크릿, 네트워크를 어디까지 분리할 것인가
이 글은 GitHub 공식 ARC 문서를 기준으로 운영 관점의 판단 기준을 정리합니다.
왜 Ephemeral Runner가 기본값에 가까운가
장수형 runner는 빠르게 시작할 수 있지만, 시간이 지날수록 상태가 누적됩니다.
- 이전 job의 파일과 캐시가 남을 수 있음
- 도구 버전이 drift할 수 있음
- 침해나 오염이 있었을 때 영향 범위가 커짐
반면 ephemeral runner는 job 또는 짧은 수명 주기 후 사라지므로 다음 장점이 있습니다.
- 작업 간 격리가 좋아짐
- 이미지 기반 표준화가 쉬워짐
- 오염된 상태를 다음 job으로 넘기지 않음
운영 난이도는 조금 올라가지만, 보안과 재현성을 생각하면 기본 선택지로 두는 편이 더 안전합니다.
Scale Set 경계는 workload와 trust boundary 기준으로 나눈다
ARC를 처음 도입할 때 흔한 실수는 조직 전체를 하나의 giant scale set으로 묶는 것입니다. 이렇게 하면 자원 공유는 쉬워 보여도, 보안 경계와 우선순위 제어가 약해집니다.
더 나은 기준은 다음과 같습니다.
- 신뢰 수준이 다른 저장소는 분리
- 빌드 성격이 다른 workload는 분리
- 네트워크 접근 범위가 다른 job은 분리
예시:
| scale set | 용도 | 분리 이유 |
|---|---|---|
public-ci | 외부 기여 PR 검증 | 신뢰되지 않은 코드 격리 |
internal-build | 내부 서비스 빌드 | 내부 패키지, 캐시 접근 허용 |
deploy-ops | 배포와 운영 자동화 | 강한 자격 증명과 승인 경계 필요 |
보안은 runner 자체보다 주변 경계가 좌우한다
runner 보안은 단순히 컨테이너 이미지를 최신으로 유지하는 문제보다 넓습니다.
꼭 봐야 할 보안 경계
- job이 접근 가능한 시크릿
- 러너 Pod의 서비스 계정 권한
- 컨테이너 이미지 provenance
- 아웃바운드 네트워크 정책
- artifact와 cache 저장소 경계
특히 untrusted pull request를 처리하는 runner와 배포 자격 증명을 가진 runner를 같은 경계에 두는 것은 피해야 합니다.
이미지 전략은 "빠른 시작"과 "깨끗한 실행" 사이 균형이다
ephemeral runner를 쓰면 이미지 전략이 중요해집니다. 이미지가 너무 비어 있으면 매 job 설치 비용이 커지고, 너무 무거우면 pull 시간이 커집니다.
실무적으로는 다음 방식이 균형이 좋습니다.
- 언어 런타임, 공통 빌드 도구는 베이스 이미지에 포함
- 프로젝트별 종속성은 cache나 job 단계에서 복원
- runner 이미지는 버전 태그와 변경 이력을 명확히 관리
네트워크와 시크릿은 최소 권한 원칙으로
ARC runner는 CI 워크로드지만, 실제로는 매우 강한 권한이 붙기 쉬운 실행 환경입니다. 따라서 다음 기준을 권장합니다.
- scale set별 egress 정책 분리
- 배포 runner에만 cloud credential 접근 허용
- 단순 test runner는 read-only 수준으로 제한
- GitHub OIDC를 사용할 수 있으면 long-lived secret보다 우선 고려
운영 지표와 체크리스트
운영 중에는 다음을 봐야 합니다.
- job 대기 시간
- runner 생성 시간
- Pod scheduling 실패율
- 이미지 pull 시간
- 실패한 job 후 cleanup 상태
- scale out과 scale in 지연
운영 체크리스트
- untrusted workload와 privileged workload가 분리되어 있는가
- ephemeral runner가 기본 동작인가
- runner 이미지 버전이 추적 가능한가
- scale set별 네트워크 정책이 분리되어 있는가
- OIDC 또는 최소 권한 secret 전략이 있는가
흔한 안티패턴
모든 저장소를 하나의 runner 그룹에 넣는다
운영은 단순해 보여도 보안과 우선순위 제어가 무너집니다.
장수형 runner에 상태를 많이 남긴다
빠른 빌드처럼 보이지만, drift와 오염 가능성이 커집니다.
배포 자격 증명과 외부 PR 검증을 같은 경계에서 처리한다
가장 피해야 할 구성입니다.
마무리
ARC 운영의 핵심은 Kubernetes 위에서 runner를 띄우는 기술이 아니라, 어떤 job을 어떤 신뢰 경계에서 실행할지 결정하는 운영 모델입니다. ephemeral runner, 분리된 scale set, 최소 권한 네트워크와 시크릿 전략이 그 모델의 중심입니다.