[Cloud Run][운영] source deploy에서 build service account와 service identity를 같이 쓸 때 어떤 권한부터 분리하나

IT 리서치 노트

[Cloud Run][운영] source deploy에서 build service account와 service identity를 같이 쓸 때 어떤 권한부터 분리하나

Cloud Run에서 gcloud run deploy --source를 쓰기 시작하면 build와 deploy와 runtime 권한이 한 번에 처리되는 것처럼 보인다. 하지만 2026년 7월 30일 기준 Cloud Run 공식 문서를 다시 보면 source deploy에는 Cloud Build가 쓰는 build service account, 실행 중 Google Cloud API를 부르는 service identity, 그리고 둘을 붙이는 deployer 권한이 분리되어 있다. 이 글은 source deploy에서 어떤 권한부터 갈라야 least privilege가 덜 꼬이는지 정리한 것이다.

목차

1. 개요
2. 어디서 실제로 막히는가
3. 실무에서 적용하는 순서
4. 공식 문서와 예시 화면으로 확인하기
5. 주의사항과 리스크
6. 결론
7. 참고 링크

1. 개요

결론부터 말하면 Cloud Run source deploy는 deployer, build service account, runtime service identity를 셋으로 나누는 편이 안전하다. --source 한 줄이 build와 deploy를 묶어 주지만 IAM 책임까지 하나로 합치지는 않는다. build 계정은 이미지 생성에 필요한 권한만, runtime 계정은 실제 호출하는 Google Cloud API 권한만 갖게 두는 것이 기본이다.

또 Cloud Run 문서는 user-managed service account를 권장하고 default service account의 광범위 권한을 경계한다. source deploy를 빠르게 열었다가 default 계정이 넓게 남아 있으면 이후 감사와 권한 축소가 더 어려워진다.

2. 어디서 실제로 막히는가

실무에서 흔한 문제는 세 가지다. 첫째, 배포가 한 줄로 끝나니 build와 runtime 권한을 같은 계정에 몰아준다. 둘째, 서비스가 실제로 어떤 Google Cloud API를 호출하는지 모르는 상태에서 runtime 계정에 넓은 권한을 먼저 준다. 셋째, default service account로 시작한 뒤 나중에 어느 권한이 빌드용이었는지 실행용이었는지 분리하지 못한다.

Cloud Run build service account 문서는 source deploy에서 --build-service-account를 지원하고, service identity 문서는 실행 중 API 접근 권한은 runtime service identity에 줘야 한다고 설명한다. 즉 빌드와 실행은 같은 Cloud Run 작업처럼 보여도 권한 경계는 다르다.

특히 build 단계는 Artifact Registry, Cloud Build, 소스 읽기 권한과 닿고, runtime 단계는 Cloud SQL, Secret Manager, Pub/Sub 같은 실제 애플리케이션 호출 대상과 닿는다. 이 둘을 한 계정에 합치면 사고 범위가 커지고, 권한 축소도 훨씬 느려진다.

• 증상: source deploy는 되지만 어떤 서비스 계정이 무엇을 했는지 설명이 안 된다.
• 실패: build 권한과 runtime API 권한을 같은 계정에 몰아준다.
• 막힘: default service account에 광범위 권한을 남긴다.
• 누락: deployer, build 계정, runtime 계정을 별도 주체로 기록하지 않는다.

3. 실무에서 적용하는 순서

실무 순서는 네 단계가 가장 짧다. 먼저 deployer가 어떤 서비스 계정을 붙일 수 있는지 정한다. 다음으로 build service account를 지정해 소스 빌드 권한을 별도 계정으로 분리한다. 세 번째로 runtime service identity는 실제 호출하는 Google Cloud API 목록을 기준으로 최소 권한만 준다. 마지막으로 default service account의 기존 광범위 권한을 줄이거나 대체한다.

1. deployer 권한과 계정 부착 권한을 먼저 분리한다.
2. --build-service-account로 build 계정을 따로 둔다.
3. --service-account로 runtime identity를 명시한다.
4. default service account의 광범위 권한을 정리한다.

Cloud Console과 터미널에서는 deploy 명령, service account 필드, IAM 역할 표, 실행 로그를 같이 확인해야 한다. 어떤 계정이 빌드에만 쓰이는지, 어떤 계정이 런타임 응답과 로그에만 보이는지, 어떤 경로에서 권한 오류가 났는지, 어떤 파일과 명령이 배포를 만들었는지를 한 번에 기록해 두면 권한 축소가 훨씬 쉽다.

IAM 점검 메모 예시

deployer=ci-deployer@project
build_service_account=cr-build@project
runtime_service_account=cr-runtime@project
build_roles=run.builder
runtime_roles=secretmanager.secretAccessor,pubsub.publisher
default_service_account_review=scheduled

이 구조를 잡아 두면 IAM 요청이 훨씬 구체적으로 바뀐다. 어떤 서비스가 Cloud SQL만 쓰는지, 어떤 배포가 build만 필요한지 선이 생기기 때문이다. least privilege는 역할 이름이 아니라 작업 단계별 경계에서 시작하는 편이 더 실용적이다.

4. 공식 문서와 예시 화면으로 확인하기

첫 자료는 Cloud Run source deploy 기본 명령이다. --source로 배포를 시작하는 순간 build와 runtime 권한이 자동으로 한 덩어리처럼 느껴지기 쉽다.

Cloud Run source deploy는 <code>gcloud run deploy SERVICE --source .</code> 한 줄로 build와 deploy를 이어서 실행한다.

하지만 명령이 한 줄이라는 것과 IAM 책임이 한 개라는 것은 다르다. 여기서부터 build 서비스 계정과 런타임 service identity를 분리해 봐야 한다.

두 번째 자료는 build service account 문서다. Cloud Run은 source deploy에서 Cloud Build가 쓸 별도 서비스 계정을 지정할 수 있다고 적고 있다.

Cloud Run 문서는 source deploy에서 <code>--build-service-account</code>로 Cloud Build용 계정을 따로 지정할 수 있다고 설명한다.

즉 이미지 빌드에 필요한 권한과 서비스 실행 시 필요한 권한을 같은 계정에 몰아둘 필요가 없다. least privilege를 적용할 첫 분기점이 바로 여기다.

세 번째 자료는 서비스 identity 설정 문서다. Cloud Run 서비스가 다른 Google Cloud API를 안 쓰면 추가 권한 없이도 기본 계정을 쓸 수 있다는 설명이 나온다.

Cloud Run 서비스가 다른 Google Cloud API를 호출하지 않는다면 runtime service identity에 추가 역할이 필요 없을 수 있다.

이 문장이 중요한 이유는 모든 서비스 계정에 Editor 비슷한 광범위 권한을 먼저 주는 관성을 끊게 해 주기 때문이다. 런타임 계정은 실제 호출하는 API만 기준으로 잡아도 된다.

네 번째 자료는 service identity 개념 문서다. user-managed service account를 권장하고, default service account의 광범위 권한을 경계하라고 적고 있다.

Cloud Run 문서는 user-managed service account를 권장하고 default service account의 자동 권한 부여를 경계한다.

즉 배포가 성공하는지만 보고 default 계정으로 밀어 두면 나중에 서비스 호출 경계와 감사를 더 어렵게 만든다. source deploy라서 더더욱 분리가 필요하다.

다섯 번째 자료는 build 계정, deployer, runtime identity를 실제 역할별로 나눈 표다. 누가 무엇을 해야 하는지를 한 장으로 묶어 두면 IAM 요청이 훨씬 짧아진다.

deployer, build service account, runtime service identity를 나눈 역할 표다.

Cloud Run source deploy는 한 명령으로 끝나도 IAM은 셋으로 나눠 보는 편이 안전하다. build, deploy, runtime이 각각 필요한 권한이 다르기 때문이다.

여섯 번째 자료는 명령 예시다. --build-service-account와 --service-account를 따로 적으면 분리 의도가 배포 명령 자체에 남는다.

Cloud Run source deploy에서 build 계정과 runtime 계정을 분리한 gcloud 예시다.

이런 형태로 명령을 남기면 이후 IAM 변경 요청도 훨씬 구체적으로 할 수 있다. '배포가 안 되니 권한 좀 주세요' 대신 어느 계정에 어떤 역할이 필요한지 바로 적을 수 있다.

마지막 자료는 least privilege 흐름도다. 실제로는 어떤 API를 호출하는지 모르는 상태에서 runtime 계정을 먼저 넓히는 경우가 많아서, 시작 순서를 고정해 두는 편이 좋다.

Cloud Run source deploy에서 권한을 줄일 때의 우선순위 흐름도다.

기존 Cloud Run 성능 글들이 실행 중 병목을 다뤘다면, 이번 글은 그보다 앞선 배포 구조와 IAM 경계를 정리하는 출발점이다.

5. 주의사항과 리스크

첫 번째 리스크는 build service account와 runtime service identity를 같은 계정으로 두고 장기적으로 권한이 계속 늘어나는 것이다. 두 번째 리스크는 default service account의 자동 권한 부여 상태를 점검하지 않는 것이다. 세 번째 리스크는 deployer가 아무 서비스 계정이나 붙일 수 있게 두어 우회 경로를 만드는 것이다.

운영 문서에는 최소한 deployer, build 계정, runtime 계정, 각 계정의 역할 이유를 함께 남기는 편이 좋다. 그래야 다음 권한 감축 때 무엇을 제거해도 되는지 빨리 판단할 수 있다.

• 한 줄 배포 명령과 한 개의 IAM 책임은 같은 뜻이 아니다.
• build 권한과 runtime API 권한은 다른 계정으로 나누는 편이 안전하다.
• default service account 권한은 별도 감축 계획이 필요하다.

6. 결론

Cloud Run source deploy에서 least privilege를 적용하려면 deployer, build service account, runtime service identity를 셋으로 나누는 편이 가장 명확하다. --build-service-account와 --service-account를 명시해 배포 명령 자체에 경계를 남기면 이후 IAM 변경과 감사도 훨씬 쉬워진다.

만약 여기서 한 단계 더 나아가 runtime service account를 다른 프로젝트에 두려는 상황이라면, 후속 글인 cross-project service account 권한 순서 글로 이어 가면 deployer 권한과 Cloud Run service agent 토큰 발급 권한을 어떤 순서로 다시 나눠야 하는지 바로 연결해서 볼 수 있다.

• source deploy도 IAM은 build와 runtime으로 나눠 본다.
• runtime 계정은 실제 API 호출 기준으로 최소 권한만 준다.
• default service account 권한은 별도로 줄인다.

7. 참고 링크

1. https://docs.cloud.google.com/run/docs/deploying-source-code
2. https://docs.cloud.google.com/run/docs/configuring/services/build-service-account
3. https://docs.cloud.google.com/run/docs/configuring/services/service-identity
4. https://docs.cloud.google.com/run/docs/securing/service-identity