GitHub Actions 자체 호스팅 Mac Runner는 안전할까? 2026 검수 체크리스트
서명 키를 둔 Mac Runner에 외부 PR이나 여러 저장소의 작업을 연결하려는 개발자를 위한 보안 검수 안내입니다. 작업을 신뢰도별로 나누고, 토큰 권한과 키 접근, 작업 뒤 잔여 상태를 확인해 프로덕션 출시를 맡길 수 있는지 판단합니다.
목차
외부 PR을 검사하려는데, 서명 키가 있는 Mac Runner까지 작업을 실행할까 걱정되시나요?
이번 주에는 PR 격리, 토큰 최소 권한, 서명 키 접근, 작업 뒤 정리 상태를 확인하세요. 이 조건을 증명할 수 없다면 해당 Runner로 프로덕션 출시 작업을 실행하지 마세요.
GitHub Actions 자체 호스팅 Mac Runner는 iOS 빌드에 쓸 수 있지만, 저장소가 비공개이거나 환경 승인을 켰다는 이유만으로 안전하다고 볼 수는 없습니다. 위험은 코드를 누가 실행시키는지, 작업이 얼마나 격리되는지, 비밀 정보에 누가 접근하는지에 달려 있습니다. GitHub도 자체 호스팅 Runner가 신뢰할 수 없는 워크플로 코드의 영향을 받을 수 있다고 안내합니다. 자체 호스팅 Runner의 보안 주의사항을 먼저 확인하세요.
이 글은 GitHub Actions로 iOS 앱을 빌드하고 서명하는 독립 개발자, 소규모 팀, 여러 저장소의 출시를 관리하는 담당자를 위한 검수 기준입니다. 워크플로 설치법이 아니라, 프로덕션 작업에 맡겨도 되는지 판단하는 데 초점을 둡니다.
PR 검증 작업은 서명 환경과 분리합니다
공개 저장소의 PR 검증에는 빌드나 테스트에 필요한 코드만 실행하고, 배포 키와 토큰은 전달하지 않는 구성이 적합합니다. PR 작성자가 제출한 변경 코드가 Runner에서 실행될 수 있다고 전제하고, 해당 작업에 민감 정보가 보이지 않는지 확인하세요.
공개 저장소의 PR을 자체 호스팅 Runner에서 검사해도 되나요?
검사할 수는 있지만, 신뢰할 수 없는 PR 코드가 서명 정보나 접근 권한이 있는 작업 환경에 닿지 않도록 분리해야 합니다. PR 이벤트와 실제 체크아웃 대상이 무엇인지 함께 살펴보세요. 이벤트 이름만 보고 안전하다고 판정하지 말고, 실행되는 코드와 해당 Runner가 가진 권한을 확인해야 합니다. 워크플로 이벤트별 동작과 pull_request_target 보안 지침을 대조하면 트리거와 권한의 차이를 검토할 수 있습니다.
환경 승인은 배포 절차의 통제 수단이지, PR 코드와 Runner 호스트를 격리했다는 증거는 아닙니다. 저장소가 비공개여도 구성원이나 자동화 앱이 실행할 수 있는 코드의 신뢰도는 따로 검토해야 합니다.
주의:
pull_request_target은 기본 브랜치의 워크플로 문맥에서 높은 권한을 얻을 수 있으므로, 검토되지 않은 PR 코드를 가져와 실행하도록 연결하지 마세요. 구체적인 위험과 안전한 사용 조건은 GitHub의 보안 지침에서 확인할 수 있습니다.
신뢰된 브랜치도 토큰과 워크플로 권한을 제한합니다
내부 브랜치에서만 작업하더라도 토큰 권한은 필요한 범위로 설정해야 합니다. 저장소의 모든 워크플로가 Runner를 호출할 수 있는지, 서드파티 Action이 어떤 코드인지도 함께 확인하세요.
iOS 지속적 통합에서 토큰 권한은 무엇을 확인해야 하나요?
먼저 워크플로 파일의 permissions를 확인하고, 작업에 필요한 권한만 남기세요. 예를 들어 소스 체크아웃만 필요한 작업이라면 contents: read처럼 읽기 권한으로 제한할 수 있습니다. 실제 배포 단계에 쓰기 권한이 필요하다면 그 권한을 별도 작업에만 부여하세요. 이 설정 항목과 권한 동작은 GitHub 워크플로 권한 문서에서 확인할 수 있습니다.
서드파티 Action은 출처를 검토하고, 변경 가능한 태그 대신 검증 가능한 버전 고정 방식을 사용하세요. Runner 그룹이나 저장소 접근 설정도 살펴서 허가되지 않은 저장소와 워크플로가 호스트를 선택하지 못하게 해야 합니다. Runner 접근 관리 문서의 설정과 현재 저장소 권한을 비교하세요. 빌드가 성공했다는 사실은 이런 권한 설정이 적절하다는 뜻이 아닙니다.
서명 작업은 일반 빌드와 분리합니다
인증서 파일만 따로 보관해도 서명 정보가 보호되는 것은 아닙니다. Apple은 코드 서명에 개발자 인증서와 그에 대응하는 개인 키가 필요하다고 설명합니다. 따라서 인증서, 개인 키, App Store Connect 인증 정보를 각각 목록으로 만들고, 실제로 배포해야 하는 작업만 접근할 수 있는지 확인하세요. Apple의 서명 인증서 동기화 안내를 기준으로 서명 신원의 구성도 검토할 수 있습니다.
iOS 서명 인증서와 개인 키를 자체 호스팅 Runner에 둘 수 있나요?
둘 수는 있지만, 모든 빌드 작업에 노출하지 말고 서명과 출시가 필요한 제한된 작업에서만 사용하세요. 비밀 정보가 로그에 출력되거나 임시 파일과 실패한 빌드 산출물에 남는지도 확인해야 합니다. 실제 키나 토큰 값을 로그에 넣어 테스트하지 말고, 비밀 정보가 전달되는 경로와 작업 종료 뒤 삭제되는지를 검증하세요.
작업 사이에 남는 상태를 실제로 확인합니다
같은 Mac에서 작업을 연속 실행한다면 한 작업의 권한이 끝난 뒤에도 다음 흔적이 남을 수 있는지 살펴야 합니다. 워크스페이스, 키체인 상태, 임시 인증 파일, 빌드 산출물, 로그를 각각 확인하세요. GitHub는 자체 호스팅 Runner를 깨끗하게 격리된 환경으로 가정하지 말라고 안내합니다. 자체 호스팅 Runner 안내를 운영 방식과 대조하세요.
앞선 작업의 인증 정보가 다음 작업에 남지 않는지 어떻게 확인하나요?
작업이 끝난 뒤 워크스페이스와 임시 파일이 어떻게 처리되는지 확인하고, 다음 작업에서 이전 작업의 파일이나 키체인 항목을 읽을 수 없는지 검증하세요. 실패한 작업의 로그와 산출물도 점검 대상입니다. Runner 등록을 한 번의 작업 뒤 없애는 방식만으로는 호스트의 디스크나 키체인까지 정리됐다고 증명할 수 없습니다. 실제 정리 절차와 자원 재사용 방식을 기록으로 남기세요.
여러 저장소가 한 호스트를 공유하면 접근 범위를 좁힙니다
여러 워크플로가 한 대의 Mac Runner를 함께 써도 되나요?
워크플로와 저장소의 신뢰 수준이 같고, 서로의 파일과 비밀 정보에 접근하지 못한다는 점을 확인할 수 있을 때만 검토하세요. Runner 등록 범위, Runner 그룹, 저장소 접근 정책, 관리 권한을 살펴야 합니다. 서로 무관한 프로젝트가 같은 호스트를 호출할 수 있거나, 작업 사이 잔여 상태를 검증할 수 없다면 공유 범위를 줄이거나 출시 환경을 분리하세요.
이번 주 검수 기록에 남길 항목
다음 항목을 대표적인 PR 검증과 출시 작업으로 직접 확인하세요.
- PR 트리거와 체크아웃되는 코드가 예상한 범위인지 기록합니다.
- 각 작업의
GITHUB_TOKEN권한과 서드파티 Action의 출처 및 고정 버전을 확인합니다. - Runner를 호출할 수 있는 저장소와 팀, 관리자를 확인합니다.
- 서명 인증서와 개인 키, App Store Connect 인증 정보에 접근하는 작업을 각각 기록합니다.
- 작업 성공과 실패 뒤 워크스페이스, 키체인, 임시 파일, 로그, 산출물의 처리 결과를 확인합니다.
- 확인하지 못한 항목과 출시를 막는 위험을 적고, 해결 전에는 해당 Runner에 프로덕션 비밀 정보를 제공하지 않습니다.
아래 점수는 공식 인증 기준이 아니라 팀 내부에서 증거의 빈틈을 드러내기 위한 자체 판정 도구입니다. 각 항목을 충족하면 2점, 일부만 확인하면 1점, 증거가 없으면 0점으로 기록하세요. 총점이 높더라도 서명 키 노출이나 외부 PR 격리 실패가 있으면 출시를 승인하지 마세요.
| 검수 영역 | 0점 | 1점 | 2점 |
|---|---|---|---|
| PR 코드와 서명 환경 | 경계 불명 | 일부 분리 | 코드와 비밀 정보 접근을 검증 |
| 토큰과 Action 권한 | 범위 불명 | 일부 제한 | 필요한 권한과 출처를 확인 |
| 서명 정보 접근 | 작업 구분 없음 | 제한 일부 적용 | 출시 작업만 접근함을 확인 |
| 작업 뒤 정리 | 증거 없음 | 일부 상태 확인 | 파일·키체인·로그 처리 기록 보유 |
| Runner 접근 범위 | 허가 범위 불명 | 일부 제한 | 저장소·팀 접근 정책을 검증 |
결정 조건으로 프로덕션 사용 여부를 정합니다
- PR 코드가 서명 키와 출시 토큰에 접근하지 못하고, 작업 뒤 정리 결과까지 검증했다면 해당 분리 구조를 유지하면서 대표 작업을 재검수하세요.
- 토큰 권한이나 Runner 접근 범위를 확인하지 못했다면, 우선 권한을 줄이고 호출 가능한 저장소를 제한하세요.
- 같은 Mac에서 신뢰 수준이 다른 작업이 실행되거나 작업 뒤 민감 상태가 남을 가능성이 있다면, 서명 출시 작업을 다른 환경으로 옮기세요.
- 신뢰된 코드와 서명 작업을 분리할 방법이 없다면, 해당 Runner에 프로덕션 출시 자격 증명을 맡기지 마세요.
자체 호스팅 Mac은 호스트 접근과 정리 책임이 팀에 남고, Runner를 여러 프로젝트가 공유하면 코드와 자격 증명의 경계를 직접 증명해야 합니다. 별도 Mac을 구매하면 하드웨어 관리와 유휴 시간 비용을 감당해야 하고, 기존 호스트를 계속 쓰면 격리와 유지보수 책임도 계속됩니다. 임시 또는 프로젝트 단위 환경이 필요하다면 VPSMAC의 Mac 환경 선택 정보를 살펴보고, 서울 환경 안내 등에서 실제 제공 내용과 접근 조건을 확인하세요. 렌탈이 보안 검수를 대신하지는 않지만, 별도 장비를 구매하고 직접 상시 운영하는 방식보다 필요한 기간에 Mac 환경을 마련하는 선택지가 될 수 있습니다.