Secretless GCP workload identity: are static keys still the default?

TL;DR: A GCP demo can authenticate a chat assistant with federated workload identity, short-lived tokens, and kernel-enforced credential delivery instead of stored service account keys, reducing secret sprawl and blast radius while preserving access to Vertex AI and Geocoding APIs, according to Riptides. The deeper lesson is that static credential workflows remain the weakest assumption in modern cloud identity governance.

NHIMG editorial — based on content published by Riptides: On demand credentials - Secretless AI assistant example on GCP

By the numbers:

• Only 38% have automated certificate lifecycle management in place.
• 69% of organisations now have more machine identities than human ones.
• 61% rely on spreadsheets or manual tracking for machine identity management.

Questions worth separating out

Q: How should security teams replace static service account keys in cloud workloads?

A: Start by binding each workload to a verifiable identity and exchanging that identity for short-lived cloud credentials at runtime.

Q: Why do static credentials create more risk than runtime-issued workload identity?

A: Static credentials persist after the decision to trust them, so they can be copied, reused, and forgotten across laptops, repos, and pipelines.

Q: What do IAM teams get wrong about secret rotation for machine identities?

A: They often treat rotation as the main control when the larger issue is credential portability.

Practitioner guidance

• Remove downloadable service account keys Eliminate JSON key files from application configuration and CI/CD paths.
• Map each workload to a verifiable subject Assign a stable SPIFFE-style subject to every workload that needs cloud access, then bind that subject to the minimum cloud role required for the task.
• Shift cloud access to federation and impersonation Use Workload Identity Federation or equivalent subject exchange so the cloud trusts the workload identity, not a copied token or locally stored file.

What's in the full article

Riptides' full post covers the operational detail this post intentionally leaves for the source:

• The exact GCP service account impersonation steps and IAM bindings required for the demo.
• The Kubernetes and sysfs mechanics behind kernel-projected credential delivery to the workload.
• The full Riptides resource definitions for CredentialSource, WorkloadIdentity, and WorkloadCredential.
• The connection-level token injection flow for geocode.googleapis.com and how the demo avoids persisted keys.

👉 Read Riptides' full walkthrough of secretless GCP workload identity →

Secretless GCP workload identity: are static keys still the default?

Explore further

View Full Forum →  |  NHI Foundation Course →