Notifications
Clear all
Topic starter
08/07/2026 6:55 pm
TL;DR: Google Cloud Secret Manager gives GCP teams versioned, IAM-governed storage for database passwords, API keys, and OAuth tokens, but its rotation is notification-only and its replication choices are immutable, according to Infisical. The real governance issue is that secrets management still depends on lifecycle discipline, per-secret access design, and external tooling once teams move beyond a single cloud.
NHIMG editorial — based on content published by Infisical: Google Cloud Secret Manager: Setup, Best Practices & GCP Guide
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.
Questions worth separating out
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.
Q: When does Secret Manager create governance risk instead of reducing it?
A: Risk rises when teams assume storage equals control.
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.
Practitioner guidance
- Bind access at the secret level Grant roles/secretmanager.secretAccessor only on the specific secret a workload needs.
- 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.
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
👉 Read Infisical's guide to Google Cloud Secret Manager setup and best practices →
Google Cloud Secret Manager: what IAM teams miss at scale?
Explore further
08/07/2026 7:18 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Google Cloud Secret Manager governance for GCP secrets at scale
