This article is based on reporting originally published by devclass.com.
What Is Google Cloud Secret Manager?
Google Cloud Secret Manager is a managed service that lets developers securely store, access, and manage sensitive data such as API keys, passwords, and TLS certificates. When it entered public beta (January 2020), it represented Google Cloud’s first fully integrated secret management offering, bringing GCP in line with comparable services from AWS (Secrets Manager) and Azure (Key Vault).
Before Secret Manager existed, GCP users who needed programmatic secret storage typically relied on Berglas, an open-source command-line tool built by Google. Berglas encrypts secrets and stores them in Cloud Storage, using Cloud KMS for key management. Secret Manager is not a replacement for Berglas—both can coexist—but it provides a purpose-built API and deeper platform integration that Berglas cannot match.
Migrating from Berglas
Teams already using Berglas do not need to abandon it immediately. However, the Berglas release that accompanied the Secret Manager beta introduced a migrate command that moves existing secrets into Secret Manager. This gives teams a low-friction path to the newer service while keeping Berglas available for workloads that depend on it. Using both tools in combination is explicitly supported.
Key Features
API and Client Libraries
Secret Manager exposes a REST and gRPC API for creating, accessing, and deleting secrets. Official client libraries are provided for common languages, and the Cloud SDK (gcloud) can be used as an alternative for scripting and automation workflows.
Encryption
Secret data is protected with TLS in transit and AES-256-bit encryption at rest. These are baseline Google Cloud platform guarantees applied to Secret Manager storage, consistent with how other GCP services protect data at rest.
Versioning
Every time a secret payload is updated, Secret Manager stores it as a new secret version rather than overwriting the previous value. This makes secret rotations auditable and reversible. Operators can pin applications to a specific version or reference the latest alias to always retrieve the most recent value. Older versions can be disabled or destroyed independently.
Global Names and Replication Policies
Secret names are scoped globally within a GCP project. This avoids the regionalisation friction of per-region secret stores and simplifies application configuration when services run across multiple regions.
For teams with compliance requirements that mandate data residency in specific regions, Secret Manager supports replication policies. Customers can either let Google automatically replicate secret data across regions or supply an explicit list of allowed regions, giving compliance teams the control they need without sacrificing availability.
Access Control and Audit Logging
By default, only project owners can access secrets. All other identities must be granted explicit IAM permissions before they can read or manage secret data. This follows the principle of least privilege and avoids accidental secret exposure to developers who only need access to other project resources.
Cloud Audit Logs integration means every access and mutation event is recorded. Security teams can query these logs to detect anomalous access patterns—such as an unexpected service account reading a production credential—that may indicate a compromise.
Pricing (at Beta Launch)
Secret Manager was not free at beta launch. The published pricing at the time of this writing was:
- $0.03 per 10,000 API operations
- $0.06 per active secret version, per regional replica, per month
The per-replica charge is relevant for teams using custom replication policies: storing a secret version in three regions costs three times the per-version fee. Teams using automatic replication should confirm with Google Cloud documentation how replicas are counted for billing purposes, as this can affect cost projections for secrets that change frequently.
Note: Pricing listed here reflects the beta period (early 2020). Always verify current pricing in the official Google Cloud Secret Manager documentation before budgeting for production use.
When to Use Secret Manager vs. Alternatives
| Scenario | Recommended Tool |
|---|---|
| New GCP project needing managed secrets with IAM integration | Secret Manager |
| Existing Berglas users with no compliance-driven migration timeline | Berglas (or both in combination) |
| Secrets that must be auditable and versioned for compliance | Secret Manager |
| Lightweight scripting where a full API client is overkill | Berglas or environment variable injection via Cloud Run/GKE |
Summary
Google Cloud Secret Manager fills a genuine gap in the GCP platform by providing a first-party, API-driven secret store with versioning, audit logging, replication control, and fine-grained IAM integration. It is architecturally comparable to AWS Secrets Manager and Azure Key Vault, making multi-cloud teams’ operational practices more consistent. The service carries a cost even in beta, so teams should account for both the per-operation and per-version-replica charges when planning adoption at scale.