시리즈: gcloud CLI 자동화 운영 플레이북 (총 11편) | 3회
gcloud 인증 체계 완전 정복: 사용자, 서비스계정, ADC 분리로 온보딩 장애를 없애는 법
“CLI에서는 되는데 코드에서는 안 돼요” — 온보딩 장애의 절반은 gcloud 인증과 ADC를 구분 못 해서 터져요. 이 글에서는 두 인증 트랙의 차이, 3가지 인증 패턴의 사용처, ADC 트러블슈팅, 키리스 운영 표준까지 한 번에 잡아드려요.
Summary
- gcloud 인증과 ADC(Application Default Credentials)는 목적이 다른 별개 트랙이야 — 이걸 분리 못 하면 온보딩 장애가 반복돼
- 인증 패턴 3가지(사용자 로그인/서비스계정/키리스 WIF)의 사용처를 명확히 구분해야 해
- ADC 트러블의 핵심 원인은
GOOGLE_APPLICATION_CREDENTIALS환경변수 혼선이야 - 서비스계정 키(JSON)는 기본 금지하고, 임시 위임(impersonation)과 WIF로 키리스 표준을 세워야 해
이 글의 대상
- “CLI는 되는데 코드가 안 돼요” 문제를 겪고 있는 개발자
- 팀의 인증 표준을 세우려는 플랫폼/SRE 엔지니어
- 서비스계정 키 관리가 고민인 보안/거버넌스 담당자
목차
- 핵심: gcloud 인증과 ADC는 다른 트랙이다
- 인증 패턴 1: 사용자 계정 로그인
- 인증 패턴 2: 서비스계정
- 인증 패턴 3: 키리스 표준 — 임시 위임과 WIF
- ADC 트러블슈팅: 환경변수 혼선 해결법
- 인증 상태 진단 루틴
- 팀 인증 표준 설계 가이드
핵심: gcloud 인증과 ADC는 다른 트랙이다
이건 교육에서 강제 주입해야 할 내용이야. 대부분의 온보딩 장애가 여기서 터지거든.
두 문장으로 정리하면 이거야
gcloud auth login은 CLI를 위한 로그인이야. gcloud 명령을 실행할 때 사용하는 자격이지.gcloud auth application-default login은 로컬 코드 테스트를 위한 ADC 설정이야. Python/Java/Go 같은 클라이언트 라이브러리가 사용하는 자격이야.
왜 이걸 구분해야 하나?
| gcloud CLI 자격 | ADC (Application Default Credentials) | |
|---|---|---|
| 용도 | gcloud 명령 실행 | 클라이언트 라이브러리(코드) 인증 |
| 설정 명령 | gcloud auth login |
gcloud auth application-default login |
| 저장 위치 | gcloud 내부 자격 저장소 | ADC 표준 경로 (OS별 다름) |
| 사용 주체 | gcloud CLI | Python/Java/Go SDK, Terraform 등 |
| 자동 연동 | 안 됨! | 안 됨! |
핵심은 이 둘이 자동으로 연동되지 않는다는 거야. gcloud auth login으로 로그인해도 코드에서 자동으로 인증이 되지 않아. 공식 문서도 “gcloud는 gcloud auth application-default 명령 그룹으로 ADC를 관리한다”고 명시하고 있어.
이 혼동이 만드는 실제 장애 시나리오
상황: 개발자가 gcloud auth login 후 Python 코드를 실행
결과: "DefaultCredentialsError: Could not automatically determine credentials"
원인: gcloud 로그인은 CLI 전용이라, Python 클라이언트 라이브러리는 ADC를 찾지 못함
해결: gcloud auth application-default login 실행
상황: gcloud auth application-default login 했는데 특정 API 호출이 실패
결과: "end-user credentials are not supported by this API"
원인: 일부 API는 사용자 자격(end-user credentials)을 허용하지 않음
해결: 서비스계정 기반 자격으로 전환
인증 패턴 1: 사용자 계정 로그인
언제 쓰나?
개발자가 로컬에서 리소스를 직접 조회/생성/디버깅할 때. 가장 기본적인 인증 방식이야.
표준 절차
방법 A: gcloud init (권장 — 인증 + 설정을 한 번에)
gcloud init
이 명령 하나로 로그인, 프로젝트 선택, 기본 리전/존 설정까지 한 번에 잡을 수 있어. 온보딩에서는 이걸 기본으로 써.
방법 B: gcloud auth login (계정만 추가)
gcloud auth login
프로젝트나 리전은 바꾸지 않고 계정만 추가/변경할 때 써.
방법 C: 헤드리스/원격 환경 (브라우저 없을 때)
gcloud auth login --no-browser
# 또는
gcloud init --console-only
SSH로 원격 서버에 접속해서 작업할 때, 브라우저 대신 URL을 복사해서 인증하는 방식이야.
운영 포인트
# 현재 로그인된 계정 목록 확인 (활성 계정에 * 표시)
gcloud auth list
출력 예시:
Credentialed Accounts
ACTIVE ACCOUNT
* jayden@company.com
admin@company.com
주의할 점:
- 로컬 자격은 ~/.config/gcloud에 저장돼. 여러 계정이 들어갈 수 있으니 gcloud auth list로 활성 계정을 수시 확인해야 해
- 세션이 만료되면 재인증이 필요할 수 있어. 관리자가 세션 길이를 정책으로 조정할 수 있거든
- 팀 온보딩 문서에 “세션 만료 시 재로그인 절차”를 포함시키는 게 좋아
ADC 설정 (로컬 코드 테스트용)
gcloud에 로그인했다고 코드가 인증되는 게 아니야. 로컬에서 코드를 테스트하려면 ADC를 별도로 설정해야 해.
# 로컬 코드 테스트를 위한 ADC 설정
gcloud auth application-default login
이 명령을 실행하면 ADC 파일이 표준 경로에 생성돼. 이후 Python/Java/Go 같은 클라이언트 라이브러리가 이 파일을 자동으로 찾아서 인증에 사용하지.
# ADC 파일 위치 확인
# macOS/Linux: ~/.config/gcloud/application_default_credentials.json
# Windows: %APPDATA%\gcloud\application_default_credentials.json
인증 패턴 2: 서비스계정
언제 쓰나?
자동화/CI에서 “사람이 아닌 워크로드”에 권한을 부여할 때. 서비스계정은 애플리케이션이나 VM이 Google Cloud API를 호출할 때 사용하는 신원이야.
방법 A: 키 파일(JSON)로 활성화 — 레거시, 가능하면 피해
gcloud auth activate-service-account SA_EMAIL --key-file=KEY.json
이 방식은 가능은 하지만 기본 정책에서는 피해야 해. 왜냐하면:
| 리스크 | 설명 |
|---|---|
| 키 유출 | JSON 파일이 코드 저장소, Slack, 이메일로 유출되면 즉시 악용 가능 |
| 장기 사용 | 키가 만료되지 않으면 영구적인 백도어가 될 수 있어 |
| 회전 실패 | 키를 주기적으로 교체하는 운영이 현실적으로 어려워 |
| 추적 어려움 | 키가 여러 곳에 복사되면 누가 어디서 쓰는지 파악이 안 돼 |
Google은 서비스계정 키를 “특권 자격증명”으로 보고, 최소화를 명확히 권고하고 있어. 조직정책으로 키 생성을 아예 차단하는 모델까지 제공하지.
방법 B: 서비스계정 생성과 최소권한 부여
키 파일 없이도 서비스계정을 만들고 사용할 수 있어.
# 서비스계정 생성
gcloud iam service-accounts create my-app-sa \
--display-name="My App Service Account" \
--project=my-project-id
# 필요한 최소 권한만 부여 (예: Storage 객체 관리)
gcloud projects add-iam-policy-binding my-project-id \
--member='serviceAccount:my-app-sa@my-project-id.iam.gserviceaccount.com' \
--role='roles/storage.objectAdmin'
최소권한 원칙:
- 기본 역할(Owner/Editor/Viewer)은 절대 지양해
- 사전정의 역할 중 가장 좁은 범위를 선택해
- 필요하다면 커스텀 역할을 만들어
인증 패턴 3: 키리스 표준 — 임시 위임과 WIF
왜 키리스(Keyless)인가?
서비스계정 키를 완전히 없애는 거야. 키가 없으면 유출도 없고, 회전도 필요 없고, 관리 부담도 없어지거든.
Google이 제공하는 키리스 방법은 두 가지야.
방법 1: 임시 위임(Impersonation)
“내 사용자 계정으로 로그인하되, 실행은 서비스계정의 권한으로 하겠다”는 개념이야. 키 파일 없이 서비스계정처럼 동작할 수 있어.
# 글로벌 설정 (모든 gcloud 명령에 적용)
gcloud config set auth/impersonate_service_account SA_EMAIL
# 또는 명령별로 지정
gcloud storage ls --impersonate-service-account=SA_EMAIL
사전 조건:
- 호출하는 사용자(또는 서비스계정)에게 roles/iam.serviceAccountTokenCreator 역할이 부여돼 있어야 해
장점:
| 장점 | 설명 |
|------|------|
| 키 없음 | JSON 키 파일을 만들 필요가 없어 |
| 임시 토큰 | 단기 토큰을 발급받아서 쓰니까 만료되면 자동으로 무효화 |
| 감사 추적 | “누가(사용자) 어떤 서비스계정으로 실행했는지” 감사 로그에 남아 |
| 통제 | serviceAccountTokenCreator 역할로 위임 가능 범위를 제한할 수 있어 |
실무 활용 패턴:
# 개발자 로컬에서 프로덕션 서비스계정 권한이 필요할 때
gcloud config set auth/impersonate_service_account prod-sa@my-project.iam.gserviceaccount.com
# 작업 완료 후 위임 해제
gcloud config unset auth/impersonate_service_account
방법 2: Workload Identity Federation (WIF)
외부 CI/CD(GitHub Actions, Jenkins, GitLab CI 등)에서 Google Cloud에 접근할 때 사용하는 키리스 방식이야.
동작 원리:
외부 CI → OIDC 토큰 발급 → Google Cloud에 토큰 교환 → 단기 자격 발급 → API 호출
| 특징 | 설명 |
|---|---|
| 키 없음 | JSON 키 파일이 CI에 저장되지 않아 |
| 자동 만료 | 토큰이 자동으로 만료돼 |
| 자동 회전 | 토큰 교환이 매 실행마다 새로 발생해 |
| CI 보안 모델에 적합 | GitHub Actions의 OIDC provider와 자연스럽게 통합돼 |
GitHub Actions 예시:
# .github/workflows/deploy.yml
jobs:
deploy:
permissions:
id-token: write # OIDC 토큰 발급 권한
contents: read
steps:
- uses: google-github-actions/auth@v2
with:
workload_identity_provider: 'projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID'
service_account: 'deploy-sa@my-project.iam.gserviceaccount.com'
- uses: google-github-actions/setup-gcloud@v2
- run: gcloud run deploy myservice --image=gcr.io/my-project/myapp:latest
키리스 운영 표준 요약
| 상황 | 권장 방식 | 이유 |
|---|---|---|
| 로컬 개발 | 사용자 로그인 + 필요 시 임시 위임 | 키 파일 없이 서비스계정 권한 사용 가능 |
| CI/CD (외부) | WIF (OIDC 기반) | 키 저장 불필요, 토큰 자동 만료/회전 |
| GCP 내부 워크로드 | Workload Identity (GKE), 기본 서비스계정 | 자동 할당, 추가 설정 불필요 |
| 예외 (레거시) | 키 파일 + 엄격한 회전/감사 | 조직정책으로 예외 범위를 최소화 |
키 생성 금지를 조직 표준으로 만들기
Google은 조직정책으로 서비스계정 키 생성을 원천 차단하는 제약조건을 제공해.
iam.disableServiceAccountKeyCreation = True
이 정책을 기본값으로 두고, 불가피한 예외 프로젝트만 허용하는 모델이 가장 안전해.
키를 써야만 하는 불가피한 경우:
# 키 생성 (최소한으로만)
gcloud iam service-accounts keys create key.json --iam-account=SA_EMAIL
# 키 목록 확인 (관리/감사용)
gcloud iam service-accounts keys list --iam-account=SA_EMAIL
# 키 삭제 (사용 후 즉시)
gcloud iam service-accounts keys delete KEY_ID --iam-account=SA_EMAIL
ADC 트러블슈팅: 환경변수 혼선 해결법
문제의 핵심: GOOGLE_APPLICATION_CREDENTIALS
ADC 트러블의 가장 흔한 원인은 GOOGLE_APPLICATION_CREDENTIALS 환경변수가 남아있는 거야.
ADC 우선순위 (이 순서대로 찾아):
1. GOOGLE_APPLICATION_CREDENTIALS 환경변수가 가리키는 파일
2. gcloud auth application-default login으로 생성된 사용자 자격
3. (GCP 환경) 연결된 서비스계정의 메타데이터
트러블 시나리오와 해결법
시나리오 1: 환경변수가 남아있어서 엉뚱한 계정으로 인증
# 문제 확인
echo $GOOGLE_APPLICATION_CREDENTIALS
# 출력: /home/user/old-key.json ← 이전에 설정한 키 파일이 남아있음!
# 해결: 환경변수 제거
unset GOOGLE_APPLICATION_CREDENTIALS
# 그리고 ADC 재설정
gcloud auth application-default login
시나리오 2: 사용자 자격으로 호출할 수 없는 API
# 에러: "end-user credentials are not supported by this API"
# 원인: 일부 API는 사용자 자격(end-user credentials)을 허용하지 않음
# 해결: 서비스계정 기반 자격으로 전환
# 방법 A: 임시 위임 사용
gcloud auth application-default login --impersonate-service-account=SA_EMAIL
# 방법 B: 키 파일 지정 (비추, 불가피할 때만)
export GOOGLE_APPLICATION_CREDENTIALS=/path/to/service-account-key.json
시나리오 3: quota project 에러
# 에러: "Quota project is not set"
# 원인: ADC에 할당량 프로젝트가 지정되지 않음
# 해결: quota project 설정
gcloud auth application-default set-quota-project my-project-id
ADC 트러블슈팅 치트시트
| 에러 메시지 | 원인 | 해결 |
|---|---|---|
DefaultCredentialsError |
ADC 미설정 | gcloud auth application-default login |
end-user credentials not supported |
해당 API가 사용자 자격 미허용 | 서비스계정 자격으로 전환 |
GOOGLE_APPLICATION_CREDENTIALS 관련 |
환경변수가 잘못된 파일을 가리킴 | unset GOOGLE_APPLICATION_CREDENTIALS |
Quota project not set |
할당량 프로젝트 미지정 | set-quota-project 명령 실행 |
| 인증은 되는데 권한 없음 | 계정에 필요한 역할 미부여 | IAM 역할 확인 및 부여 |
인증 상태 진단 루틴
문제가 생기면 이 순서로 진단해. 이 루틴을 팀 전체가 공유하면 인증 관련 장애 대응 시간이 크게 줄어들어.
3단계 진단 루틴
# 1단계: gcloud CLI는 누구로 로그인돼 있나?
gcloud auth list
# → 활성 계정(*)이 의도한 계정인지 확인
# 2단계: 현재 설정(프로젝트/리전)이 맞나?
gcloud config list
# → project, account, region, zone이 의도와 일치하는지 확인
# 3단계: 설치/자격 파일 위치 등 상세 정보
gcloud info
# → Python 경로, 자격 저장 경로, 로그 위치 등 확인
ADC 전용 진단
# ADC 상태 확인 (현재 어떤 자격이 ADC로 설정돼 있는지)
gcloud auth application-default print-access-token 2>&1
# → 성공하면 토큰 출력, 실패하면 에러 메시지
# 환경변수 확인
echo $GOOGLE_APPLICATION_CREDENTIALS
# → 비어있어야 정상 (gcloud auth application-default login 기반이면)
# ADC 파일 존재 여부 확인
# macOS/Linux:
ls -la ~/.config/gcloud/application_default_credentials.json
# Windows:
# dir %APPDATA%\gcloud\application_default_credentials.json
진단 결과에 따른 대응표
| 진단 결과 | 문제 | 조치 |
|---|---|---|
auth list에 의도한 계정 없음 |
로그인 안 됨 | gcloud auth login |
auth list에 활성 계정이 다름 |
잘못된 계정 활성 | gcloud config set account CORRECT_EMAIL |
config list에 프로젝트가 다름 |
잘못된 프로젝트 | gcloud config set project CORRECT_PROJECT |
| ADC 토큰 발급 실패 | ADC 미설정 | gcloud auth application-default login |
GOOGLE_APPLICATION_CREDENTIALS 설정됨 |
환경변수 혼선 | unset GOOGLE_APPLICATION_CREDENTIALS |
팀 인증 표준 설계 가이드
최소 합의사항 (이것만이라도 정해)
팀에서 보안팀과 플랫폼팀이 합의해야 할 최소 표준이 있어. 이 세 가지만 정해도 근본적인 인증 문제가 크게 줄어들어.
1. 로컬 개발: 사용자 로그인 + ADC (테스트 목적만)
2. CI/CD: WIF/OIDC 기반 단기 토큰 (키 파일 금지)
3. 서비스계정 키: 기본 금지 (조직정책으로 차단, 예외만 허용)
교육에서 반드시 주입해야 할 표준 문장
이 문장들을 팀 온보딩 문서에 그대로 넣어:
| 번호 | 표준 문장 |
|---|---|
| 1 | “gcloud auth login은 CLI를 위한 로그인이야” |
| 2 | “gcloud auth application-default login은 로컬 코드 테스트를 위한 ADC 설정이야” |
| 3 | “이 둘은 자동으로 연동되지 않아. 각각 따로 설정해야 해” |
| 4 | “서비스계정 키(JSON)는 기본적으로 만들지 않아. 필요하면 임시 위임을 써” |
| 5 | “CI에서는 WIF로 키리스 인증을 해” |
역할별 인증 매트릭스
| 역할 | gcloud CLI | ADC | 서비스계정 | 키 파일 |
|---|---|---|---|---|
| 개발자 (로컬) | gcloud auth login |
gcloud auth application-default login |
필요 시 임시 위임 | 금지 |
| CI/CD | WIF 기반 자동 인증 | WIF 기반 자동 설정 | WIF로 임시 토큰 | 금지 |
| 프로덕션 워크로드 | 해당 없음 | 서비스계정 자동 할당 | GKE Workload Identity 등 | 금지 |
| 레거시/예외 | 해당 없음 | 키 파일 지정 | 키 파일 활성화 | 최소화+엄격한 관리 |
핵심 정리
1. gcloud 인증(CLI용)과 ADC(코드용)는 별개 트랙이야 — 이걸 교육에서 분리하지 않으면 장애의 절반이 여기서 터져
2. 서비스계정 키는 "특권 자격증명"이야 — 기본 금지하고, 임시 위임(impersonation)이나 WIF로 키리스 운영을 표준으로 세워
3. ADC 트러블의 핵심은 GOOGLE_APPLICATION_CREDENTIALS 환경변수 혼선이야 — 진단 루틴으로 빠르게 잡을 수 있어
4. 팀 인증 표준은 "로컬은 사용자 로그인+ADC, CI는 WIF 키리스, 키 파일은 기본 금지" 세 줄이면 돼
FAQ
Q. gcloud auth login만 하면 Python 코드도 인증이 되는 거 아니야?
A. 안 돼. 이게 가장 흔한 오해야. gcloud auth login은 CLI 전용이고, Python/Java 같은 클라이언트 라이브러리는 ADC를 따로 찾아. 코드 테스트를 하려면 gcloud auth application-default login을 별도로 실행해야 해.
Q. 서비스계정 키를 쓰면 안 되는 거야?
A. “절대 안 된다”가 아니라 “기본 금지, 예외만 허용”이야. Google도 키를 “특권 자격증명”으로 분류하고 최소화를 권고해. 임시 위임이나 WIF로 대체할 수 있는 상황에서 키를 쓰는 건 불필요한 리스크야. 레거시 시스템이나 WIF 미지원 환경에서만 예외로 허용하되, 엄격한 회전/감사 체계를 갖춰야 해.
Q. 임시 위임(impersonation)을 쓰면 서비스계정 키가 완전히 필요 없어지는 거야?
A. 대부분의 경우 그래. 로컬 개발에서 서비스계정 권한이 필요할 때 gcloud config set auth/impersonate_service_account SA_EMAIL 한 줄이면 키 없이 서비스계정으로 실행할 수 있어. 다만 호출 주체에게 roles/iam.serviceAccountTokenCreator 역할이 필요하고, 네트워크/API 제약이 있는 환경에서는 검증이 필요해.
Q. WIF는 GitHub Actions에서만 쓸 수 있어?
A. 아니야. GitHub Actions 외에도 GitLab CI, Jenkins, CircleCI 등 OIDC 토큰을 발급할 수 있는 모든 외부 CI에서 쓸 수 있어. AWS 워크로드에서 Google Cloud에 접근할 때도 WIF를 쓸 수 있지. 핵심은 “외부 IdP의 토큰을 Google Cloud 자격으로 교환”하는 메커니즘이야.
Q. GOOGLE_APPLICATION_CREDENTIALS 환경변수는 언제 쓰는 거야?
A. 서비스계정 키 파일을 ADC로 지정할 때 쓰는 거야. 하지만 이 환경변수가 남아있으면 gcloud auth application-default login으로 설정한 사용자 자격보다 우선돼서 혼선이 생겨. 그래서 로컬 개발 환경에서는 이 환경변수를 설정하지 않는 게 원칙이야. 꼭 필요한 경우에만 설정하고, 작업이 끝나면 반드시 제거해.
Q. ADC의 우선순위가 어떻게 되는 거야?
A. ADC는 이 순서로 자격을 찾아: (1) GOOGLE_APPLICATION_CREDENTIALS 환경변수 → (2) gcloud auth application-default login으로 생성된 파일 → (3) GCP 환경의 메타데이터 서비스. 이 순서를 알면 대부분의 ADC 트러블을 진단할 수 있어.
Q. gcloud auth revoke는 언제 써야 해?
A. 공유 PC에서 작업했을 때, 퇴사자 계정을 정리할 때, 또는 인증 상태를 완전히 초기화하고 싶을 때 써. gcloud auth revoke ACCOUNT_EMAIL로 특정 계정을 제거하거나, gcloud auth revoke --all로 모든 자격을 제거할 수 있어. ADC도 별도로 gcloud auth application-default revoke로 제거해야 해.
Q. 팀에서 인증 표준을 도입하려면 뭐부터 해야 해?
A. 세 단계로 시작해. (1) 현재 팀에서 키 파일이 어디에 얼마나 있는지 감사 먼저 해. (2) 조직정책으로 키 생성을 차단하고, 기존 키에 만료 기한을 설정해. (3) 임시 위임과 WIF 가이드를 만들어서 대체 경로를 제공해. 한 번에 다 바꾸려 하지 말고, 신규 프로젝트부터 키리스를 적용하는 게 현실적이야.
Q. Terraform에서도 ADC를 쓰는 거야?
A. 맞아. Terraform의 Google Provider도 ADC를 지원해. gcloud auth application-default login으로 설정하면 Terraform이 자동으로 그 자격을 사용해. CI에서는 WIF로 인증하면 Terraform도 키 없이 실행할 수 있지. 즉 gcloud + Terraform + 코드가 모두 같은 ADC 체계를 공유하는 거야.
참고 자료 (References)
데이터 출처
| 출처 | 설명 | 링크 |
|---|---|---|
| Authorize the gcloud CLI | gcloud 인증 체계, ADC 관리 명시 | https://docs.cloud.google.com/sdk/docs/authorizing |
| ADC 개요 | Application Default Credentials 동작 원리 | https://docs.cloud.google.com/docs/authentication/application-default-credentials |
| 로컬 ADC 설정 | 로컬 개발 환경 ADC 설정 절차 | https://docs.cloud.google.com/docs/authentication/set-up-adc-local-dev-environment |
| ADC 트러블슈팅 | 환경변수 혼선 등 대표 원인과 해결 | https://docs.cloud.google.com/docs/authentication/troubleshoot-adc |
| SA 키 관리 베스트프랙티스 | 키 최소화 공식 권고 | https://docs.cloud.google.com/iam/docs/best-practices-for-managing-service-account-keys |
| 서비스계정 임시 위임 가이드 | impersonation 설정과 사전 조건 | https://docs.cloud.google.com/docs/authentication/use-service-account-impersonation |
| WIF 베스트프랙티스 | Workload Identity Federation 설계 권고 | https://docs.cloud.google.com/iam/docs/best-practices-for-using-workload-identity-federation |
| WIF 개요 | Workload Identity Federation 개념과 구성 | https://docs.cloud.google.com/iam/docs/workload-identity-federation |
| restricting service accounts (Org Policy) | 조직정책으로 키 생성 차단 | https://docs.cloud.google.com/resource-manager/docs/organization-policy/restricting-service-accounts |
| google-github-actions/auth | GitHub Actions WIF 인증 액션 | https://github.com/google-github-actions/auth |
핵심 인용
“The gcloud CLI provides support for managing Application Default Credentials (ADC) with the gcloud auth application-default command group.” — gcloud 인증 가이드
다음 편 예고
[4편] 구성(configurations) 운영: 프로젝트/환경 전환을 실수 없이 하는 법
- configuration이 왜 “사고 방지 장치”인지 실제 사례로 설명
- default는 보존하고, 목적별 configuration을 분리하는 실무 패턴
- CI에서 CLOUDSDK_ACTIVE_CONFIG_NAME 환경변수로 비대화형 전환을 강제하는 방법