GCP Authentication with Vault: Service Account Integration and Associate Exam Prep

A setup where GCP workloads connect securely to Vault and fetch short-lived GCP credentials (access tokens or temporary keys) only when needed is a standard approach for combining zero trust with least privilege.

This article distills the essentials of designing, building, and operating service account integration with Vault's GCP Auth Method and GCP Secrets Engine, framed for Associate-level exam preparation.

Foundations: Auth Method vs. Secrets Engine

Vault cleanly separates authentication (who you are) from secret issuance (what is handed out). For GCP integration, the standard approach is to combine the GCP Auth Method with the GCP Secrets Engine, which issues dynamic credentials.

GCP Auth logs clients into Vault using either a GCE instance identity or a service account-signed JWT. The GCP Secrets Engine dynamically issues short-lived access tokens or service account keys based on the specified role.

• Auth Method: the entry point for obtaining a Vault token (authentication). Role and policy assignment are the keys.
• Secrets Engine: the exit point for secrets Vault issues and manages. TTL and role configuration are the keys.
• GCP service account: the principal on the GCP side. On Vault, "which SA's requests are allowed" is treated as a boundary condition.

Minimal policy example (allow reading GCP secrets in Vault)

path "gcp/token/app-role" {
  capabilities = ["read"]
}

Architecture and Authentication Flow (IAM/GCE)

The GCP Auth Method comes in two flavors. The GCE type uses the instance identity available from the metadata server on GCE or GKE nodes. The IAM type uses a JWT signed by a service account (or signed via the IAM Credentials API). In either case, Vault rigorously validates against Google's signing/public keys and the role's boundary conditions (such as bound_service_accounts).

The typical flow is for the application to log in to Vault, obtain a client token, and then use that token to fetch a short-lived access token from the GCP Secrets Engine. Avoiding the distribution of long-lived JSON key files is the recommended pattern in production.

• GCE type: instance ID token → Vault auth/gcp/login → Vault token issued
• IAM type: SA-signed JWT (including aud/exp) → Vault auth/gcp/login → Vault token issued
• Issued Vault token → call GCP Secrets Engine → obtain short-lived access token / key

Conceptual example of an IAM-type login

# 1) サービスアカウントでJWTを署名（IAM Credentials API など）
#    例: gcloud iam service-accounts sign-jwt payload.json signed.jwt --iam-account SA_EMAIL
# payload.json には iss/sub/aud/iat/exp 等の標準クレームを含める（audはVaultロールに合わせる）

# 2) Vaultにログイン
vault write auth/gcp/login \
  role="app-iam-role" \
  [email protected]

# 3) 返却された client_token を使用してGCPトークン取得
vault read gcp/token/app-role

Vault-Side Setup (Auth Method and Secrets Engine)

First, enable the GCP Auth Method and create a role to define the GCP service account and project boundaries. Next, enable the GCP Secrets Engine and use roles to control required scopes and impersonation targets. Finally, prepare a policy tied to the role that limits which paths the application can read.

Because the GCP Secrets Engine has Vault issue tokens and keys to GCP on behalf of clients, Vault itself must be able to authenticate to GCP. This is achieved via Application Default Credentials (for example, a service account attached to the Vault server) or by explicitly setting credentials in the Secrets Engine configuration.

• auth enable gcp → create a role (type=iam or gce)
• secrets enable gcp → create a role (access token or key)
• Use policies to restrict readable paths and enforce least privilege

Representative CLI workflow (example)

# 1) GCP Auth Method を有効化
vault auth enable gcp

# 2) IAMタイプのロールを作成（特定SAのみ許可、TTLを短く）
vault write auth/gcp/role/app-iam-role \
  type="iam" \
  bound_service_accounts="app-sa@PROJECT_ID.iam.gserviceaccount.com" \
  bound_projects="PROJECT_ID" \
  ttl="15m" \
  max_ttl="1h" \
  policies="app-gcp-read"

# 3) GCP Secrets Engine を有効化
vault secrets enable gcp

# 4) Secrets Engine の構成（ADCを利用する例: VaultがGCPへ認証できる環境で動作）
#    credentials を省略するとADCが使われる構成が一般的
vault write gcp/config \
  ttl="3600s" \
  max_ttl="43200s"

# 5) アクセストークン発行ロール（特定SAに対して所定スコープ）
vault write gcp/roleset/app-role \
  project="PROJECT_ID" \
  secret_type="access_token" \
  [email protected] \
  token_scopes="https://www.googleapis.com/auth/cloud-platform"

# bindings.hcl の例（SAインパーソネーション許可）
# resource "//iam.googleapis.com/projects/PROJECT_ID/serviceAccounts/target-sa@PROJECT_ID.iam.gserviceaccount.com" {
#   roles = ["roles/iam.serviceAccountTokenCreator"]
# }

# 6) ポリシー（Secrets Engineの読み取りのみを許可）
cat <<'EOF' | vault policy write app-gcp-read -
path "gcp/token/app-role" {
  capabilities = ["read"]
}
EOF

GCP-Side Preparation: Service Accounts and Permission Design

For IAM-type authentication, the signing service account on the client side must be able to sign a JWT. When using the IAM Credentials API, the caller needs roles/iam.serviceAccountTokenCreator on the target SA. The recommended production practice is to use API-based signing rather than distributing key files.

When the Secrets Engine issues access tokens, Vault (on the server side) must be able to impersonate the target service account. Grant roles/iam.serviceAccountTokenCreator (or equivalent) on the target SA to the service account of the instance running Vault, or to the ADC configured for Vault.

• Avoid distributing keys; use signJwt/signBlob or SA impersonation instead
• Grant TokenCreator only on the bare minimum set of target SAs
• Track SA impersonation in audit logs (Cloud Audit Logs)

Representative gcloud configuration example

# クライアントが署名に使うSA
CLIENT_SA="app-sa@PROJECT_ID.iam.gserviceaccount.com"
# Vaultがインパーソネーションに使うSA（Vaultサーバに割り当て）
VAULT_SA="vault-sa@PROJECT_ID.iam.gserviceaccount.com"
# ターゲットSA（実際にトークンを取得したい主体）
TARGET_SA="target-sa@PROJECT_ID.iam.gserviceaccount.com"

# 1) クライアント側：CLIENT_SAに自身のJWT署名を許可（必要に応じて）
# signJwtを呼ぶ主体にTokenCreatorを付与
gcloud iam service-accounts add-iam-policy-binding ${CLIENT_SA} \
  --member="serviceAccount:${CLIENT_SA}" \
  --role="roles/iam.serviceAccountTokenCreator"

# 2) Vault側：VAULT_SAにTARGET_SAへのインパーソネーション権限
gcloud iam service-accounts add-iam-policy-binding ${TARGET_SA} \
  --member="serviceAccount:${VAULT_SA}" \
  --role="roles/iam.serviceAccountTokenCreator"

Operations and Best Practices: TTL, Boundary Conditions, Policies

Role boundary conditions and TTLs are your first line of defense for limiting blast radius in case of compromise. On a GCP Auth role, always specify at least bound_service_accounts and bound_projects, and tighten audiences and region/zone boundaries (for GCE) as far as feasible.

In the Secrets Engine, prefer issuing short-lived access tokens over long-lived service account keys. If keys are unavoidable, enable TTL and automatic expiration, and build pre-expiry rotation into operations alongside audit logging.

• Vault tokens: choose appropriately between ttl, max_ttl, and periodic tokens
• GCP Auth role: minimize bound_service_accounts, bound_projects, and audiences
• Secrets Engine: prefer access_token, minimize key issuance, automate rotation
• Policies: limit read paths and minimize the scope of list permissions as well
• Auditing: track activity through both Vault Audit Device and Cloud Audit Logs

Role configuration with tighter boundary conditions (example)

# IAMタイプのロールで複数条件を指定
vault write auth/gcp/role/app-iam-role \
  type="iam" \
  bound_service_accounts="app-sa@PROJECT_ID.iam.gserviceaccount.com" \
  bound_projects="PROJECT_ID" \
  audiences="vault-app" \
  ttl="10m" \
  max_ttl="30m" \
  policies="app-gcp-read"

Associate Exam Prep: Common Pitfalls and Comparisons

At the Associate level, the division of responsibilities between Auth Methods and Secrets Engines, the relationship between roles and policies, and the meaning of TTLs are frequently tested. What matters is being able to articulate the design principles of boundary conditions and short-lived credentials, not GCP-specific implementation minutiae.

Questions also probe the trade-offs between approaches that share the same goal (authenticating cloud workloads), such as AppRole and Kubernetes Auth. Organize your understanding by criteria so you can pick the right authentication method for given assumptions and trust boundaries.

• Authentication is "the step that obtains a Vault token"; secret issuance is "the step you invoke with a Vault token"
• Don't confuse GCP Auth role boundaries (like bound_service_accounts) with policies
• Prefer short-lived access tokens; avoid distributing long-lived keys
• Be able to explain the differences between TTL, max_ttl, and period

Test Your Understanding

Frequently Asked Questions