Vault GCP Secrets Engine: Automating Short-Lived Service Account Keys

The core use case for Vault's GCP secrets engine is replacing long-lived JSON keys with short-lived, per-job service account keys that are issued and revoked automatically.

This article focuses on stable, documented behavior and covers least privilege, TTLs and leases, revocation, choosing between secret types, and operational pitfalls — useful both in production and on the exam.

How It Works and What the Exam Tests

The GCP secrets engine uses an admin credential held by Vault to call the GCP IAM API, create a service account key on the fly, and return it to the client. A lease is attached at issue time, and when the TTL expires or the client revokes the lease, Vault calls the same API to delete the key. This eliminates long-lived shared keys and reduces both leak risk and audit overhead.

Unlike a static secret stored in KV, a key issued by the GCP secrets engine is a dynamic secret: generated on demand and invalidated when its TTL expires. The engine can also issue OAuth2 access_tokens and id_tokens, but this article focuses on the service account key flow.

• Minimize credential distribution: keys are issued only when needed and expire automatically via TTL
• Auditable: both the Vault audit log and the GCP audit log capture issue and revoke events
• Exam hotspots: the roleset's secret_type, TTL vs max_ttl, lease revoke behavior, and the GCP key limit (max 10 keys per service account)

End-to-end flow from issue to auto-revoke

Key API paths to remember

sys/mounts                     # enabling engines
gcp/config                      # GCP admin credentials
gcp/roleset/<name>              # the issuing policy (roleset)
gcp/key/<roleset-name>         # dynamically issued service account keys
#gcp/token/<roleset-name>      # access_token (for reference)
#gcp/id-token/<roleset-name>   # id_token (for reference)

Prerequisites and Least-Privilege Design (GCP and Vault)

For Vault to create and delete keys, you need an admin-side service account (hereafter the Vault admin SA) with least-privilege access to the target service account. Creating and deleting keys requires roles/iam.serviceAccountKeyAdmin. Issuing access_tokens additionally requires roles/iam.serviceAccountTokenCreator. As a rule, scope these grants to the individual target service account — never to the project, folder, or organization.

On the Vault side, grant applications only read access to the gcp/key/<roleset> issue path. Avoid write and list to keep the leak surface as small as possible.

• GCP: roles/iam.serviceAccountKeyAdmin for key create/delete, plus roles/iam.serviceAccountTokenCreator if you also issue tokens
• Constrain the scope to the target service account by binding the policy at the SA resource level
• Vault policy grants read only on the issue path; administrative operations live in a separate role

Concrete least-privilege examples (GCP and Vault)

# GCP: give the Vault admin SA key-management rights over the target SA
# Substitute: [email protected], [email protected]
#gcloud
gcloud iam service-accounts add-iam-policy-binding "SA_EMAIL" \
  --member="serviceAccount:VAULT_ADMIN_SA" \
  --role="roles/iam.serviceAccountKeyAdmin"

# Vault: a minimal policy that only lets the app issue keys
# Substitute: the roleset name is ci-builder
path "gcp/key/ci-builder" {
  capabilities = ["read"]
}
# Keep operational reads such as mount info in a separate policy

Setup Steps: Enable, Configure, Create a Roleset, Issue a Key

1) Enable the engine and register the Vault admin SA's JSON credential. 2) Create a roleset for service account keys. 3) Clients read gcp/key/<roleset> to obtain a key. The key is returned with a lease attached, and Vault deletes it when the TTL expires or the lease is revoked.

Set the roleset's secret_type to service_account_key. Specify the target service account and the TTL/max_ttl at the roleset level, and keep them consistent with the mount-level TTL.

• The roleset names the target SA explicitly; the key's effective permissions come from the IAM bindings already attached to that SA — the roleset itself does not grant them
• Prefer streaming the key into downstream tooling via stdin rather than writing to disk; if a file is unavoidable, use a temp file with tight permissions
• Keep TTLs short — a typical target is the build/deploy job duration plus a few minutes of buffer

End-to-end example (Vault CLI)

# 1) Enable the engine (at the path gcp)
vault secrets enable -path=gcp gcp

# 2) Configure the GCP admin credentials (store the JSON safely)
vault write gcp/config [email protected]

# 3) Create the roleset (issues service account keys)
# Substitute PROJECT_ID, SA_EMAIL and TTL to match your requirements
vault write gcp/roleset/ci-builder \
  project="PROJECT_ID" \
  secret_type="service_account_key" \
  service_account_email="SA_EMAIL" \
  ttl="1h" max_ttl="24h"

# 4) Issue a key (with a lease)
# The output contains the lease_id and the key material (the key is JSON)
vault read -format=json gcp/key/ci-builder > key.json

# Extract private_key from the JSON and pass it to your tooling if needed

Leases, TTLs, and Revocation: How Auto-Revoke Actually Works

Every dynamic secret carries a lease. The client holds the lease_id and can renew or revoke it as needed. When the TTL expires, Vault calls the GCP IAM delete-key API to invalidate the key — that call is the core of auto-revocation. If renewal is enabled, lease renew extends only the expiration time; the key material itself stays the same.

If revocation fails — due to a network outage or a permission change, for example — Vault's revocation queue retries automatically. When failures persist for a long time, an operator must revoke manually, either in Vault or by deleting the key directly in GCP. For the exam, remember two key facts: lease revoke lets you invalidate a key immediately, and renewal cannot extend a lease beyond max_ttl.

• Both TTL and max_ttl are constrained at the roleset level and the mount level
• Renew does not rotate the key material; rotating the material requires issuing a new key
• There is a hard ceiling of 10 keys per service account — avoid long-lived leases and over-issuance

Common operations (immediate revoke and renew)

# Use the lease_id from when you issued it (example)
LEASE_ID="gcp/key/ci-builder/abcd-efgh-..."

# Revoke immediately (deletes the key straight away)
vault lease revoke "$LEASE_ID"

# Extend the TTL (where allowed)
vault lease renew "$LEASE_ID"

# Force-revoke every lease under a roleset (high impact, be careful)
vault lease revoke -prefix gcp/key/ci-builder

Which Should You Use: Key vs Access Token vs ID Token

Vault's GCP secrets engine can issue service account keys (JSON), access_tokens, and id_tokens. JSON keys offer the broadest compatibility but require distributing private key material. Tokens are short-lived and far less risky to hand around, so the modern default is to prefer tokens. Reach for dynamically issued keys with a very short TTL only when an existing tool requires a JSON key.

Inside GCE or GKE, combining Vault with Workload Identity or runtime metadata-based tokens is also a solid pattern. For the exam, be ready to justify why you picked a given secret_type for a given workload.

• Keys exist for legacy compatibility; tokens carry far less distribution risk and are easier to operate with least privilege
• Use access_tokens for short CI/CD jobs; fall back to keys only when an external tool forces you to
• Use id_tokens for authentication to services that expect OIDC/JWT on the receiving end

Operations and Troubleshooting: Auditing, Limits, Incident Response

Auditing: enable a Vault audit device to preserve issue and revoke metadata. GCP also records key creation and deletion in the Admin Activity log. Cross-referencing the two logs gives you the strongest traceability.

Limits and rates: each service account is capped at 10 keys. Keep TTLs short, revoke aggressively, and balance job concurrency against the key budget. Plan for keys to linger briefly when revocation fails.

Incident response: when revocations pile up because of a network outage or a permission change, retry lease revoke and fall back to manual deletion in GCP if needed. From a DR standpoint, it is practical to keep the TTL below your acceptable failure window.

• Stream issued credentials downstream via stdout and avoid writing to disk wherever possible
• Use response wrapping to wrap the secret in a temporary token and unwrap only at consumption time
• In CI environments, handle the secret in a tmpfs scratch directory with the tightest possible permissions

Concrete examples for auditing and health checks

# Send the Vault audit log to a file (mind the permissions and where it is kept)
vault audit enable file file_path=/var/log/vault_audit.log

# GCP: check for leftover keys and remove them by hand
gcloud iam service-accounts keys list \
  [email protected]

gcloud iam service-accounts keys delete KEY_ID \
  [email protected]

Check Your Understanding

Frequently Asked Questions