Mar 24, 2026

마지막 업데이트 Mar 30, 2026

GCP Permission Denied: 무엇부터 확인할까?

GCP 에서 Permission denied 가 나오면 진짜 문제는 보통 플랫폼 장애보다 IAM scope 문제인 경우가 많습니다. 실패하는 principal 이 잘못된 service account 일 수도 있고, project 가 다를 수도 있고, role binding 이 있기는 한데 실제 요청이 평가되는 위치와 어긋나 있을 수도 있습니다.

짧게 말하면 핵심은 이것입니다. 누가 요청하고 있고, 어디에서 권한이 평가되는지 먼저 찾아야 합니다. permission failure 는 겉보기엔 비슷해도 실제 원인은 완전히 다를 수 있습니다.

caller identity 와 resource scope 부터 본다

같은 denial 증상도 여러 mismatch 에서 나올 수 있습니다.

잘못된 active principal
잘못된 project
잘못된 resource path
다른 scope 에 부여된 role
상위 policy constraint

그래서 caller identity 와 resource hierarchy 가 가장 먼저 중요합니다.

`Permission denied` 는 보통 무엇을 뜻하나

실전에선 보통 이런 경우가 많습니다.

workload 가 생각과 다른 service account 로 실행된다
role 은 있는데 잘못된 project 또는 resource scope 에 있다
exact API permission 이 빠져 있다
org policy 또는 상위 제어가 action 을 막는다

그래서 “role 은 이미 줬는데요” 가 끝이 아닌 경우가 많습니다.

흔한 원인

1. 다른 service account 가 실제 요청을 보낸다

하나의 identity 를 가정했는데 실제 runtime 은 다른 identity 인 경우가 GCP 에서 아주 흔합니다.

특히:

Cloud Run runtime identity
GKE workload identity
로컬 gcloud 세션과 배포된 service account 차이

2. role 이 잘못된 scope 에 부여되어 있다

권한이 한 project 또는 resource layer 에는 있어도, 실제 failing request 가 평가되는 위치에는 없을 수 있습니다.

GCP IAM 은 한쪽에서 맞아 보여도 exact resource boundary 에서 틀린 경우가 많습니다.

3. 필요한 service-specific permission 이 없다

이름만 보면 충분해 보이는 role 이 실제 API 가 요구하는 permission 을 빠뜨릴 수 있습니다.

“거의 맞는” role 이지만 API 가 체크하는 exact permission 은 아닌 경우가 많습니다.

4. organization 또는 policy constraint 가 간섭한다

로컬 IAM 은 거의 맞아 보여도 상위 제약이 action 을 막을 수 있습니다.

5. 로컬 설정과 배포 환경이 서로 다르다

터미널의 account 나 project 가, 실제 서비스가 쓰는 runtime context 와 다를 수 있습니다.

그래서 디버깅 명령은 멀쩡해 보이는데 실제 서비스는 계속 실패하는 상황이 생깁니다.

실전 점검 순서

1. calling principal 과 active project 를 확인한다

기초 단계입니다.

누가 호출하는지, 어떤 project 문맥인지 모르면 IAM 디버깅은 거의 추측에 가깝습니다.

2. failing resource path 와 granted IAM scope 를 비교한다

permission 이 실제로 평가되는 exact 위치에 role 이 붙어 있는지 봐야 합니다.

3. exact API permission 이 있는지 확인한다

role 이름은 넓어 보여도 API 가 필요한 permission 이 빠져 있을 수 있습니다.

4. runtime configuration 의 service account 선택을 점검한다

“로컬에서는 되는데 Cloud Run / GKE 에서는 안 된다” 의 많은 원인이 여기 있습니다.

5. 계속 실패하면 상위 org / policy constraint 를 본다

local IAM 이 맞아 보이는데도 denial 이 남는다면 blocker 는 project 위쪽에 있을 수 있습니다.

빠른 명령

gcloud auth list
gcloud config list
gcloud projects get-iam-policy <project-id>

active identity, active project, IAM scope 가 failing resource 와 얼마나 가까운지 확인하는 데 좋습니다.

잘못된 active account, project drift, broad access 는 있어 보이는데 빠진 service-specific permission 을 보세요.

permission gap 을 찾은 뒤 무엇을 바꾸면 좋나

잘못된 identity 가 호출한다면

role 을 손보기 전에 runtime identity selection 을 먼저 고쳐야 합니다.

role 이 잘못된 scope 에 있다면

실제 failing resource 가 평가되는 수준에 role 을 부여해야 합니다.

service-specific permission 이 빠졌다면

role 이름보다 실제 API action 에 맞는 permission 세트를 써야 합니다.

org policy 가 막는다면

이건 project IAM bug 가 아니라 상위 governance 이슈로 다뤄야 합니다.

로컬과 배포 컨텍스트가 다르다면

변경 전 디버깅 문맥부터 runtime reality 와 맞춰야 합니다.

장애 중에 던져볼 질문

이 질문이 꽤 유용합니다.

실제 caller 는 누구이고, 정확히 어떤 resource 에 접근 중이며, hierarchy 의 어느 수준에서 permission 이 deny 되는가?

이 질문이 IAM 문제를 빠르게 줄여 줍니다.

FAQ

Q. 결국 role 이 부족한 문제 아닌가

항상은 아닙니다. wrong identity, wrong project, service-specific permission, 상위 constraint 도 같은 증상을 만듭니다.

Q. 가장 빠른 첫 단계는 무엇인가

실제 caller identity 와 permission 이 검사되는 exact project / resource 를 찾는 것입니다.

Q. 로컬에서 되면 프로덕션 IAM 도 맞는 것 아닌가

아닙니다. 로컬 gcloud auth 와 배포된 service account identity 는 자주 다릅니다.

Q. 이건 Cloud Run 문제인가

Cloud Run 에서 자주 드러나긴 하지만, 본질은 IAM scope 또는 identity selection 문제인 경우가 많습니다.

먼저 읽어볼 가이드

검색 유입이 많은 핵심 글부터 이어서 보세요.