This article is based on reporting originally published at itproportal.com and official commentary from Google developer advocate Seth Vargo and product manager Matt Driscoll.
What Is Google Cloud Secret Manager?
Google Cloud Secret Manager is a managed service designed to give development and operations teams a single, secure location for storing sensitive data such as passwords, API keys, TLS certificates, and other credentials. Rather than scattering secrets across configuration files, environment variables, or disparate vaults, Secret Manager acts as a centralised secrets store that integrates directly with the broader Google Cloud ecosystem.
The service was introduced to address a problem that Google’s own engineers described plainly: “Many applications require credentials to connect to a database, API keys to invoke a service, or certificates for authentication. Managing and securing access to these secrets is often complicated by secret sprawl, poor visibility, or lack of integrations.”
The Core Problem: Secret Sprawl
In practice, secrets end up in many places: hardcoded in source repositories, copied into CI/CD pipeline variables, pasted into wiki pages, or stored in shared spreadsheets. This pattern — commonly called secret sprawl — creates several compounding risks:
- Poor visibility: No single audit trail shows who accessed which secret and when.
- Difficult rotation: Updating a credential requires finding and updating every location where it was stored.
- Over-privileged access: Without fine-grained controls, secrets are often shared more broadly than necessary.
- No versioning: Rolling back to a previous credential after a failed rotation becomes a manual, error-prone task.
Secret Manager is built specifically to eliminate these failure modes.
Key Features of Secret Manager
Replication Policies
Secret Manager supports both automatic replication and user-managed replication. Automatic replication lets Google decide the optimal regions for storing secret data based on availability requirements. User-managed replication allows teams to specify exactly which regions should hold copies of a secret, which is important for data-residency and compliance requirements.
First-Class Versioning
Every time a secret value is updated, Secret Manager stores it as a new version rather than overwriting the previous one. This makes safe credential rotation straightforward: deploy the new version, verify it works, then disable or destroy the old version. If something goes wrong, rolling back is as simple as pinning your application to the previous version identifier.
Least-Privilege Access via IAM
Access to individual secrets is controlled through Google Cloud Identity and Access Management (IAM). This means you can grant a specific service account the ability to read one secret without giving it access to any other. This principle of least privilege reduces the blast radius of a compromised credential or a misconfigured service account.
Audit Logging
Every access and administrative action on a secret is recorded in Cloud Audit Logs. Teams can answer questions like: Which service accessed this API key? Who rotated this database password and when? This audit trail is essential for security investigations and compliance reporting.
VPC Service Controls
Secret Manager integrates with VPC Service Controls, which allows organisations to define a security perimeter around their Google Cloud resources. This means secret access can be restricted so that it can only originate from within a defined network boundary, preventing exfiltration even if credentials are compromised.
Migration from Berglas
Before Secret Manager, Google offered Berglas, an open-source command-line tool that stored secrets in Cloud Storage buckets encrypted with Cloud KMS. Berglas was a popular community solution, but it required teams to manage the underlying storage and encryption infrastructure themselves. Google designed Secret Manager to offer a smoother, fully managed alternative, and Berglas was updated to support Secret Manager as a backend, giving existing users a migration path.
How Secret Manager Fits Into a DevOps Workflow
For a typical cloud-native application running on Google Kubernetes Engine (GKE) or Cloud Run, Secret Manager replaces the pattern of injecting secrets as environment variables at build time. Instead:
- Secrets are stored and versioned in Secret Manager.
- Application workloads are assigned a service account with IAM permission to read only the secrets they need.
- At runtime, the application calls the Secret Manager API (or uses an SDK) to fetch the current secret value.
- All access is logged automatically.
This approach means secrets never need to be embedded in container images, source code, or CI pipeline configurations — a significant improvement over common practices that regularly lead to credential leaks in source repositories.
Summary
Google Cloud Secret Manager addresses a genuine and widespread DevOps pain point. By providing centralised storage, strong IAM-based access controls, automatic versioning, full audit logging, and network perimeter controls, it gives teams a practical path away from secret sprawl. For organisations already invested in Google Cloud, it is a natural fit that integrates with existing identity, logging, and networking infrastructure.
“With Secret Manager, you can easily manage, audit, and access secrets like API keys and credentials across Google Cloud,” said Google — and for most teams running workloads on GCP, that is a meaningful improvement over the alternatives.