gcloud CLI / Terraform / SDK の認証体系・適用順序・管理方法
gcloud CLI・Terraform・SDK は、どれも GCP にアクセスするために認証情報が必要。
それぞれのツールは「認証情報をどこから取るか」の探す順番が決まっている。ツールごとに多少違うが、探す順番の土台部分は共通で、この共通部分を ADC（Application Default Credentials）と呼ぶ。
ADC は上から順番に探して、見つかった時点でそれを使う。見つからなければ次へ進む。
GOOGLE_APPLICATION_CREDENTIALS を確認export GOOGLE_APPLICATION_CREDENTIALS="/path/to/key.json"
gcloud auth application-default login を実行すると、認証ファイルが自動で作られる。~/.config/gcloud/application_default_credentials.json（Mac/Linux）
gcloud auth application-default login を実行すると認証ファイルが作られる。gcloud には2つの認証がある。よく混同されるので注意。
gcloud コマンド自体を使うための認証。
これを実行すると gcloud compute instances list のような gcloud コマンドが使えるようになる。
Terraform や SDK には影響しない。
Terraform や SDK（プログラム）が使うための認証。
これを実行すると ADC 用の認証ファイルが作られ、Terraform や Python/Node.js のプログラムが GCP にアクセスできるようになる。
gcloud 以外のツールに影響する。
gcloud auth login（gcloud コマンド用）と gcloud auth application-default login（Terraform / SDK 用）の2つ。
GCP では複数のプロジェクト（開発用、本番用など）を使い分けることが多い。切り替え方法は4つあり、上にあるほど優先される。
gcloud xxx --project=my-project のように、実行するときだけ一時的に指定する。export CLOUDSDK_CORE_PROJECT=my-project でシェルセッション中ずっと有効。gcloud config set project my-project で永続的に設定する。direnv というツールを使うと、フォルダに入るだけでプロジェクトが自動で切り替わる。フォルダを出ると自動で元に戻る。
やり方: プロジェクトのフォルダに .envrc というファイルを作り、中に設定を書くだけ。
# project-a/.envrc
export CLOUDSDK_ACTIVE_CONFIG_NAME=project-a
export CLOUDSDK_CORE_PROJECT=my-project-aTerraform も GCP を操作するときに認証が必要。Terraform は認証情報を以下の順番で探す。
access_token や credentials を provider ブロックに書く方法。GOOGLE_OAUTH_ACCESS_TOKEN、GOOGLE_CREDENTIALS、GOOGLE_APPLICATION_CREDENTIALS の順に確認する。
gcloud auth application-default login で作った認証ファイルが使われる。gcloud auth application-default login を一度実行 → あとは普通に terraform apply するだけ。
自分のアカウントで認証した上で、「Terraform 専用のサービスアカウント（SA）になりきって操作する」という方法。
これを使うと、秘密鍵ファイルを持ち歩かなくていいし、「誰が」「どの権限で」操作したかが記録に残る。
# 1. Terraform 用の SA になりきって ADC ログイン
gcloud auth application-default login \
--impersonate-service-account terraform@my-project.iam.gserviceaccount.com
# 2. あとは普通に apply（SA の権限で実行される）
terraform applyTerraform の状態ファイル（State）を Google Cloud Storage に保存する場合、Backend の認証は Provider とは別。ただし、ADC を使っていれば特別な設定は不要。
Node.js や Python のプログラムから GCP のサービス（Cloud Storage など）を呼ぶときも認証が必要。
keyFilename や credentials を渡している場合、それが使われる。gcloud auth application-default login で作った認証が使われる。| 言語 | 何も指定しない（推奨） | 明示的に指定する場合 |
|---|---|---|
| Node.js | new Storage() |
new Storage({ keyFilename: '...' }) |
| Python | storage.Client() |
Client.from_service_account_json('...') |
| Go | storage.NewClient(ctx) |
option.WithCredentialsFile("...") |
gcloud auth application-default login、本番では自動認証が使われる。
| 場面 | やること | |
|---|---|---|
| ローカル開発 | gcloud auth application-default login を実行するだけ |
簡単 |
| ローカル開発（より安全に） | 上のコマンドに --impersonate-service-account=SA名 を追加 |
推奨 |
| CI/CD（GitHub Actions 等） | Workload Identity Federation を設定する（秘密鍵なしで認証できる仕組み） | 設定が必要 |
| 本番サーバー（GCE / Cloud Run 等） | 何もしなくていい。Google が自動で認証してくれる | 自動 |
| 秘密鍵ファイル（JSON）を使う | 環境変数 GOOGLE_APPLICATION_CREDENTIALS にパスを設定 |
非推奨 |
gcloud initgcloud auth logingcloud auth application-default login