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) Sign a JWT with the service account (the IAM Credentials API, say)
#    Example: gcloud iam service-accounts sign-jwt payload.json signed.jwt --iam-account SA_EMAIL
# payload.json carries the standard claims iss/sub/aud/iat/exp (aud must match the Vault role)

# 2) Log in to Vault
vault write auth/gcp/login \
  role="app-iam-role" \
  [email protected]

# 3) Use the returned client_token to obtain a GCP token
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) Enable the GCP auth method
vault auth enable gcp

# 2) Create an IAM-type role (allow one SA only, keep the TTL short)
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) Enable the GCP secrets engine
vault secrets enable gcp

# 4) Configure the secrets engine (using ADC: works where Vault can authenticate to GCP)
#    Omitting credentials usually means ADC is used
vault write gcp/config \
  ttl="3600s" \
  max_ttl="43200s"

# 5) A role that issues access tokens (for one SA, with set scopes)
vault write gcp/roleset/app-role \
  project="PROJECT_ID" \
  secret_type="access_token" \
  [email protected] \
  token_scopes="https://www.googleapis.com/auth/cloud-platform"

# Example bindings.hcl (allowing SA impersonation)
# resource "//iam.googleapis.com/projects/PROJECT_ID/serviceAccounts/target-sa@PROJECT_ID.iam.gserviceaccount.com" {
#   roles = ["roles/iam.serviceAccountTokenCreator"]
# }

# 6) Policy (read on the secrets engine only)
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

# The SA the client signs with
CLIENT_SA="app-sa@PROJECT_ID.iam.gserviceaccount.com"
# The SA Vault uses to impersonate (assigned to the Vault server)
VAULT_SA="vault-sa@PROJECT_ID.iam.gserviceaccount.com"
# The target SA (the identity you actually want a token for)
TARGET_SA="target-sa@PROJECT_ID.iam.gserviceaccount.com"

# 1) Client side: allow CLIENT_SA to sign its own JWT (if required)
# Grant TokenCreator to whoever calls signJwt
gcloud iam service-accounts add-iam-policy-binding ${CLIENT_SA} \
  --member="serviceAccount:${CLIENT_SA}" \
  --role="roles/iam.serviceAccountTokenCreator"

# 2) Vault side: let VAULT_SA impersonate 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)

# Several conditions on an IAM-type role
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