[Cloud Run][운영] source deploy에서 cross-project Secret Manager secret를 붙일 때 deployer 권한과 runtime identity를 어디부터 다시 줄이나

IT 리서치 노트

[Cloud Run][운영] source deploy에서 cross-project Secret Manager secret를 붙일 때 deployer 권한과 runtime identity를 어디부터 다시 줄이나

Cloud Run source deploy를 이미 정리한 팀도 cross-project Secret Manager secret를 붙이는 순간 어디부터 권한을 다시 줄여야 할지 헷갈리기 쉽다. 2026년 8월 1일 기준 Cloud Run 공식 문서를 다시 읽어 보면 deployer, Cloud Build service account, runtime service identity, Cloud Run service agent, secret project IAM이 서로 다른 층으로 분리돼 있다. 이 글은 source deploy에서 다른 프로젝트 secret를 연결할 때 deployer 권한과 runtime identity를 어디부터 다시 줄이는 편이 덜 꼬이는지 정리한 것이다.

목차

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

1. 개요

결론부터 말하면 source deploy + cross-project Secret Manager 구성은 deployer, build service account, runtime service identity, secret project IAM을 네 칸으로 분리한 뒤 줄이는 편이 안전하다. build가 된다는 사실과 runtime secret 접근이 된다는 사실은 같은 신호가 아니다.

특히 deploy 시점에는 Cloud Run이 secret 접근 가능 여부를 확인하지만, runtime에서는 환경변수 secret와 볼륨 secret의 실패 시점이 다르다. secret 접근 문제를 하나의 IAM 실수로 뭉개면 재현이 길어진다.

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

실무에서 길어지는 원인은 세 가지다. 첫째, source deploy가 성공하면 runtime identity도 정리됐다고 본다. 둘째, 다른 프로젝트 secret를 참조하면서 runtime identity 권한만 보고 secret project 바인딩을 빼먹는다. 셋째, cross-project identity를 쓸 때 Cloud Run service agent Token Creator와 deployer 권한을 같은 층으로 본다.

Cloud Run secrets 문서는 deploy 단계와 runtime 단계의 secret 체크 시점이 다르다고 설명한다. service identity 문서는 다른 프로젝트 service account를 쓸 때 Token Creator와 org policy까지 다시 보라고 적는다. build service account 문서는 source deploy에서 build 주체를 따로 고정하는 것이 least privilege에 맞다고 권장한다. 세 문서를 같이 읽으면 실패가 한 지점이 아니라는 사실이 분명해진다.

• 증상: 배포는 되는데 instance startup에서 secret retrieval이 실패한다.
• 실패: 다른 프로젝트 secret인데도 같은 프로젝트 IAM 감각으로 접근한다.
• 막힘: build 계정, runtime 계정, service agent를 하나의 service account 문제로 묶는다.
• 누락: 환경변수 secret와 볼륨 secret의 실패 타이밍 차이를 기록하지 않는다.

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

실무 순서는 다섯 단계가 가장 짧다. 먼저 deployer의 source deploy 권한과 service-account attach 권한을 확인한다. 다음으로 build service account를 분리해 source build 실패를 떼어 낸다. 세 번째로 runtime identity에 Secret Accessor를 준다. 네 번째로 다른 프로젝트 service account라면 Cloud Run service agent Token Creator를 확인한다. 마지막으로 secret를 환경변수로 주는지 볼륨으로 주는지에 따라 startup failure와 read failure를 구분한다.

1. deployer attach 권한부터 본다.
2. build service account를 먼저 고정한다.
3. runtime identity Secret Accessor를 확인한다.
4. cross-project면 service agent Token Creator를 본다.
5. secret 주입 형태에 따라 실패 시점을 분리한다.

예를 들어 콘솔의 Variables and Secrets 탭에서 환경변수 secret를 확인하고, Volumes 탭에서 마운트 secret 경로를 확인하고, 배포 명령에서 --build-service-account 와 --service-account 값을 다시 확인하고, startup 로그와 runtime read 로그를 따로 조회하면 실패 위치가 더 또렷해진다. 메뉴, 탭, 필드, 경로, 로그를 같은 메모에 저장해 두면 재현 시간이 줄어든다.

checklist:
1. verify deployer attach permission
2. verify build service account flag
3. verify runtime service account binding
4. verify secret project accessor binding
5. inspect startup log vs mounted-file read log

이 순서를 문서로 고정하면 실패를 build, deploy, startup, runtime read로 나눌 수 있다. 권한 축소도 훨씬 쉬워진다. 어느 권한이 빌드용인지, 어느 권한이 runtime secret용인지 선이 생기기 때문이다.

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

첫 공식 화면은 deployment와 runtime 체크 타이밍을 보여 준다. 여기서 먼저 잡아야 할 점은 secret 접근 실패가 모두 같은 시점에 터지지 않는다는 사실이다.

Cloud Run은 deploy 시점에 secret 접근 가능 여부를 확인하고, runtime에서는 환경변수와 볼륨 마운트에서 실패 시점이 다르다고 설명한다.

즉 source deploy가 성공했다고 해서 runtime secret 접근까지 끝난 것이 아니다. deployer, runtime identity, secret 형태를 따로 나눠 봐야 장애 위치가 빨리 잘린다.

두 번째 화면은 cross-project secret 참조 구간이다. 이 단계에서는 단순히 secret 이름이 아니라 어느 프로젝트의 서비스 계정이 실제 접근 주체인지가 핵심이다.

Cloud Run 문서는 다른 프로젝트 secret를 참조하려면 해당 프로젝트의 service account 접근 권한을 먼저 확인하라고 적는다.

같은 프로젝트 안에서 runtime service account만 갈아 끼우던 감각으로 접근하면 여기서 가장 자주 막힌다. secret 프로젝트 쪽 IAM과 runtime identity를 함께 봐야 한다.

세 번째 자료는 다른 프로젝트 service identity를 붙일 때의 조건이다. deployer 권한과 Cloud Run service agent의 Token Creator는 서로 다른 층이라는 점이 여기서 드러난다.

Cloud Run은 다른 프로젝트 service account를 쓸 때 Service Account User와 Token Creator 같은 추가 설정을 분리해서 요구한다.

이미 cross-project service account 글이 identity 부착 순서를 다뤘다면, 이번 글은 그 위에 Secret Manager 접근을 얹었을 때 어디부터 다시 최소권한을 줄이는지에 가깝다.

역할을 표로 나눠 놓으면 어떤 IAM을 누구에게 줘야 하는지 훨씬 빨리 정리된다. build, deploy, runtime, secret project를 한 칸에 섞어 두면 장애 원인도 같이 섞인다.

deployer, Cloud Build, runtime identity, secret project IAM을 분리한 표다.

같은 Cloud Run 계열이라도 build service account 분리 글과 연결해서 봐야 least privilege가 유지된다.

명령을 한 줄로 적어 두면 어떤 identity를 어디서 끼웠는지 다시 읽기 쉽다. source deploy와 secret 주입 옵션을 분리해서 메모하지 않으면 나중에 revision 재현도 느려진다.

build service account, runtime identity, cross-project secret 참조를 같이 적은 예시다.

환경변수 secret는 startup 시점, 볼륨 secret는 read 시점이라는 차이도 메모에 같이 남기면 재현 속도가 빨라진다.

마지막 자료는 실제 점검 순서다. 이 순서를 고정하면 source deploy 성공 뒤 runtime만 깨지는 상황을 secret 프로젝트와 identity 프로젝트로 분리해서 볼 수 있다.

cross-project Secret Manager를 붙일 때 권한 축소와 점검 순서를 정리한 체크리스트다.

deploy 시점과 runtime 시점을 같은 장애로 묶지 않는 것이 핵심이다.

5. 주의사항과 리스크

첫 번째 리스크는 build service account와 runtime identity를 다시 같은 계정으로 합치는 것이다. 두 번째는 다른 프로젝트 secret에 Secret Accessor를 줬다고 끝났다고 생각하는 것이다. 세 번째는 service agent Token Creator를 놓치고 runtime API 권한만 계속 조정하는 것이다.

운영 전에 확인할 때는 deployer, build service account, runtime identity, service agent, secret project 바인딩 다섯 항목을 한 표에 두는 편이 좋다. 그래야 어느 바인딩이 cross-project인지 바로 보인다.

• 배포 성공과 runtime secret 성공은 같은 뜻이 아니다.
• cross-project에서는 service agent 토큰 발급까지 따로 본다.
• 환경변수와 볼륨 secret는 실패 시점이 다르다.

6. 결론

Cloud Run source deploy에서 다른 프로젝트 Secret Manager secret를 붙일 때는 secret 이름보다 주체 분리가 먼저다. deployer, build, runtime identity, service agent, secret project IAM을 따로 적어 두면 실패를 훨씬 빨리 자를 수 있고 least privilege도 유지하기 쉬워진다.

다음 단계에서 헷갈리는 지점은 이 secret를 환경변수로 둘지 volume mount로 둘지, 그리고 latest를 어디까지 허용할지 정리한 후속 글에서 이어진다. 권한 주체를 분리한 뒤에는 startup 고정형 값과 runtime 회전형 값을 또 한 번 나누는 편이 incident와 rotation을 더 짧게 만든다.

• deployer와 service agent를 다른 층으로 본다.
• runtime secret 접근은 runtime identity로만 준다.
• cross-project secret는 secret project 바인딩까지 포함해 점검한다.

7. 참고 링크

1. https://docs.cloud.google.com/run/docs/configuring/services/secrets
2. https://docs.cloud.google.com/run/docs/configuring/services/service-identity
3. https://docs.cloud.google.com/run/docs/configuring/services/build-service-account