Google Cloud Secret Manager governance for GCP secrets at scale

At a glance

What this is: Google Cloud Secret Manager is a GCP-native secrets store whose main finding is that versioning and IAM help, but rotation, replication, and multi-cloud governance still require careful design.

Why it matters: IAM and security teams need to treat Secret Manager as one control point inside a broader secrets lifecycle, not as a complete governance model for NHI access, workload identity, or cross-cloud operations.

By the numbers:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 73% of vaults are misconfigured, leading to unauthorised access and exposure of sensitive data.
• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.

👉 Read Infisical's guide to Google Cloud Secret Manager setup and best practices

Context

Google Cloud Secret Manager is a managed secrets store for database passwords, API keys, OAuth tokens, and similar sensitive values, with access controlled through Google Cloud IAM and access activity logged in Cloud Audit Logs. The governance question is not whether it stores secrets safely, but whether teams can manage versioning, replication, and least-privilege access without creating new operational blind spots.

For IAM and platform teams, the important distinction is between storing a secret and governing its lifecycle. Secret Manager helps reduce secret sprawl inside GCP, but once workloads span Kubernetes, external clouds, Terraform state, and third-party integrations, the control model becomes more complex than simple storage and retrieval.

Key questions

Q: How should teams limit blast radius when using Google Cloud Secret Manager?

A: Use secret-level IAM bindings, not project-level grants, for production credentials. That keeps access tied to one workload and one secret, which makes reviews, incident response, and offboarding far more precise. Pair that with clear naming and logging so you can see which identity accessed which secret and why.

Q: When does Secret Manager create governance risk instead of reducing it?

A: Risk rises when teams assume storage equals control. If rotation is only partially automated, versions are left active indefinitely, or access is granted at the project level, Secret Manager can preserve old exposures instead of shrinking them. Governance improves only when lifecycle, access scope, and consumer updates are managed together.

Q: What do teams get wrong about secrets rotation in GCP?

A: They often treat the rotation schedule as the control, when the real work is updating the dependent service and proving the new credential is in use. In Secret Manager, the notification is only a trigger. If the downstream change is brittle or manual, the organisation still carries the operational risk.

Q: Who should own secrets governance when workloads span GCP and external systems?

A: The identity and platform teams should own it jointly, because GCP-native storage stops being enough once workloads move into Kubernetes, another cloud, or SaaS integrations. In that situation, the control problem is cross-environment lifecycle management, not just vault selection.

Technical breakdown

Versioning and secret state in Google Cloud Secret Manager

Secret Manager treats a secret as a container whose values live in numbered versions. That design supports auditability and rotation because applications can reference the latest alias or a pinned version, while old versions can be disabled before destruction. The operational trap is assuming deletion is immediate governance. Disabled versions are still present and reversible, which is useful for recovery but also means old secrets remain part of the control surface until they are explicitly destroyed. Version sprawl also creates billing and review overhead when rotations are frequent.

Practical implication: build a version lifecycle process that disables first, verifies breakage risk, and destroys only after downstream dependency checks.

Replication policy, residency, and immutable design choices

Replication in Secret Manager is not just a durability setting. Automatic replication delegates placement to Google, while user-managed replication fixes secrets to specific regions for residency or compliance needs, and that choice cannot be changed after creation. Regional secrets narrow placement further, which may help regulated workloads but adds more design constraints. The important governance point is that replication policy is an architectural decision, not an implementation detail, because it affects compliance, cost, and future portability from day one.

Practical implication: classify secrets by residency requirement before creation so you do not lock production data into the wrong replication model.

IAM bindings, workload identity, and least privilege for secrets

Access is controlled through IAM, with roles/secretmanager.secretAccessor granting read rights. The service supports secret-level bindings, which is the practical path to least privilege because project-level assignment gives a workload far broader access than most production systems need. For GKE, Workload Identity replaces static service-account keys with federated identity, and for external workloads, Workload Identity Federation avoids exporting long-lived JSON keys. This is the core governance pattern: authenticate by identity, then bind access to a single secret rather than a whole project.

Practical implication: move workloads off static keys and bind secret access at the secret level to reduce blast radius.

NHI Mgmt Group analysis

Secret Manager solves storage, not governance. The service gives GCP teams a cleaner place to keep credentials, but it does not remove the need for lifecycle controls, offboarding discipline, or recovery validation. The control gap appears when organisations assume that a managed vault automatically eliminates sprawl, rotation failure, or stale access. The practical conclusion is that Secret Manager should be treated as one enforcement point inside a broader identity programme, not as the programme itself.

Per-secret IAM is the right blast-radius model for production credentials. The article correctly distinguishes secret-level bindings from project-level access, because project-wide access turns one workload compromise into broad credential exposure. That distinction matters across NHI governance, PAM-adjacent controls, and cloud IAM design. A secrets platform only reduces risk when access can be traced to a single identity and a single secret. Practitioners should view broad project access as a design failure, not just a misconfiguration.

Replication policy is a governance decision disguised as a technical setting. Automatic, user-managed, and regional replication each encode assumptions about residency, portability, and operational overhead. Once a secret is created, that decision is fixed, which means the policy becomes part of the control architecture rather than a recoverable preference. The named concept here is immutable secret residency: the moment teams commit a secret to a replication model, they also commit to its compliance and cost consequences. Practitioners need to design that decision up front.

Workload Identity is the cleaner answer than exporting service-account keys. The article shows why federated identity matters: a static JSON key is itself a secret that must be stored, rotated, and protected. That is classic NHI risk, and it compounds when the same credential is copied into CI runners, manifests, or external environments. The key governance lesson is that authentication by identity is safer than distributing opaque credentials. Teams should re-evaluate any workflow that still depends on exportable service-account keys.

Rotation in Secret Manager exposes a common lifecycle assumption. Google Cloud provides the trigger, but the actual credential change has to be built and maintained elsewhere. That means the organisation must own the downstream workflow, not just the schedule. This is where many programmes fail: the secret changes are planned, but the consumer update, validation, and rollback path are not. Practitioners should treat rotation as an end-to-end identity workflow, not as a notification event.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• That is why lifecycle discipline and revocation automation matter, as explored in Guide to the Secret Sprawl Challenge.

What this signals

Immutable secret residency: once a secret is created with a replication policy, the organisation has already committed to a compliance and portability posture. That makes early classification essential, because later migration often means rebuild rather than adjustment.

Secret Manager is most effective when it is treated as one layer in a larger NHI control stack. With 28.65 million new hardcoded secrets detected in public GitHub commits in 2025 alone, secrets governance increasingly depends on finding and revoking exposure outside the vault as much as inside it.

Teams that still rely on static keys or broad project bindings should expect their access model to age badly under audit pressure. The better operating model is secret-level access, identity federation, and a revocation process that closes the loop before leaked credentials become long-lived risk.

For practitioners

• Bind access at the secret level Grant roles/secretmanager.secretAccessor only on the specific secret a workload needs. Avoid project-level bindings for production credentials because they expand blast radius and make access reviews too coarse to be meaningful.
• Replace static service-account keys Use Workload Identity for GKE and Workload Identity Federation for external workloads so applications authenticate by identity instead of exporting JSON keys that must later be tracked and rotated.
• Design replication before creation Classify secrets by residency and compliance requirement before you create them, because replication policy cannot be changed later and may force a costly or non-compliant rebuild.
• Treat rotation as a workflow, not a timer Automate the downstream credential update, validation, and rollback steps that follow a rotation notification, and verify that the consumer really switched before destroying the old version.

Key takeaways

• Google Cloud Secret Manager improves secrets handling in GCP, but it does not replace lifecycle governance, least privilege, or rotation discipline.
• Immutable replication choices, project-wide IAM grants, and notification-only rotation are the main places where operational risk accumulates.
• Teams that want lower blast radius should bind access per secret, remove static service-account keys, and automate the downstream work of rotation and revocation.

Key terms

• Secret version: A secret version is a numbered copy of a secret value stored under one secret container. It lets teams rotate credentials without changing the secret name, while preserving auditability and rollback options. In practice, version management becomes a governance task because old versions can remain active, billable, and reachable until they are disabled or destroyed.
• Replication policy: Replication policy defines where a secret is stored and how it is distributed across regions. In Google Cloud Secret Manager, this is a one-time design choice that affects residency, resilience, and compliance. The policy is not just an availability setting. It is part of the secret's governance posture and can force future rebuilds if chosen poorly.
• Workload Identity Federation: Workload Identity Federation lets external systems exchange their own identity tokens for cloud access without exporting a long-lived service-account key. That reduces secret handling risk because the credential is no longer copied into scripts, files, or CI environments. It is a stronger pattern than static keys, but it still requires tight IAM scoping and revocation discipline.
• Secret sprawl: Secret sprawl is the uncontrolled spread of credentials across code, configuration, tools, chat systems, and cloud services. It usually grows when teams add secrets faster than they can inventory, rotate, and revoke them. The result is not just exposure. It is a governance problem where nobody can confidently answer what exists, where it lives, and who can use it.

What's in the full article

Infisical's full blog post covers the operational detail this post intentionally leaves for the source:

• Step-by-step setup flow for Secret Manager in the Google Cloud console and gcloud CLI
• Terraform resource examples showing how secret containers and secret versions are managed
• Rotation mechanics built on Pub/Sub notifications, Cloud Functions, and new secret versions
• Practical comparison points for teams deciding when Secret Manager stops being enough in multi-cloud environments

👉 The full Infisical post covers versioning, replication, IAM bindings, rotation, and pricing details.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.