Before diving into settings, let us understand what counts as a secret and what problem a vault solves.

What is a secret?

A secret is any small piece of sensitive information that proves identity or grants access. Examples include database passwords, keys for outside programming interfaces, authentication tokens, private signing keys, certificates and encryption passphrases. If someone unauthorized learns a secret, they can act as your application, read your data or spend your money.

The one-sentence definition

Secret Manager is Google Cloud’s fully managed service for storing, accessing, managing and auditing secrets. It keeps each secret encrypted, controls who may read it with Identity and Access Management, records every access in audit logs and supports versions and rotation so secrets can be changed safely over time.

The problem it solves

Without a vault, secrets leak in predictable ways: committed into source code repositories, baked into container images, left in configuration files, pasted into chat tools, stored in plain environment files on developer laptops or copied into spreadsheets. Once a secret is copied into many places, you cannot know who has it, you cannot change it without hunting down every copy and you cannot prove who used it.

Many of the most damaging security incidents begin with a leaked credential rather than a sophisticated attack.

A handful of terms appear in every Secret Manager conversation. Learn them once and the rest becomes easy.

flowchart TD
  P[Google Cloud Project] --> S[Secret: db-password]
  S --> V1[Version 1: Disabled]
  S --> V2[Version 2: Enabled]
  S --> V3[Version 3: Enabled, Latest]
  S --> M[Settings: Replication, Rotation, Labels, IAM]
        

Versions are immutable

Once a version is created, its payload cannot be edited. To change a secret you add a new version. This design gives you a history, makes rollbacks possible and ensures that a reference to a specific version always returns exactly the same value until you disable or destroy it.

Understanding the journey of a secret from creation to use shows where the protections apply.

Storing a secret

When you add a version, the service receives the payload over an encrypted connection, encrypts it before writing it to storage and stores it according to your replication policy. By default, the data is encrypted with keys managed by Google. If you choose customer-managed keys, the encryption uses a key in Cloud Key Management Service that you control, so revoking that key makes the secret unreadable.

Reading a secret

When a workload asks for a secret, it authenticates with its identity, usually a service account. The service checks IAM to confirm the identity holds permission to access that secret, decrypts the payload and returns it over an encrypted connection. The access is recorded in audit logs if data access logging is enabled.

sequenceDiagram
  participant W as Workload
  participant SM as Secret Manager
  participant IAM as IAM
  participant KMS as Encryption Key
  participant L as Audit Logs
  W->>SM: Access secret version with service account identity
  SM->>IAM: Does this identity have Secret Accessor?
  IAM-->>SM: Yes
  SM->>KMS: Decrypt payload
  KMS-->>SM: Plaintext payload
  SM-->>W: Secret value over encrypted channel
  SM->>L: Record access event
        

Where a secret’s data is stored affects availability, latency and compliance.

Automatic replication

With automatic replication, Google decides where to store the secret’s data and replicates it across locations for high availability. This is the simplest option and suits most cases where there are no strict rules about data location.

User-managed replication

With user-managed replication, you choose the specific regions where the secret is stored. This helps when regulations require data to stay in certain regions, or when you want the secret close to the workloads that use it. You can choose more than one region for resilience.

Regional secrets

Google Cloud has also introduced regional secrets, which are created and served within a single chosen region using regional endpoints. They suit strict data residency needs, because requests and storage stay in that region. Check the documentation for the current features and differences between global and regional secrets before choosing.

The strength of a vault depends on who holds the keys. Secret Manager uses IAM for fine-grained control.

The main roles

Principles for granting access

Encryption is the lock on the vault door. Secret Manager offers choices about who holds the key.

A secret that never changes becomes a liability. Secret Manager helps you change secrets safely.

Why rotate secrets?

Rotation limits how long a leaked secret stays useful. If a password is changed every ninety days, a stolen copy from six months ago is already worthless. Rotation also forces your systems to prove they can handle secret changes without outages, which is valuable practice before a real emergency.

How rotation works in Secret Manager

Secret Manager does not itself change passwords in your databases or programming interfaces. Instead, you set a rotation schedule on a secret, and when the time arrives, the service publishes a notification to a Pub/Sub topic. A function or automation listening to that topic generates a new credential in the target system, adds it as a new version of the secret and, after confirming everything works, disables the old version.

sequenceDiagram
  participant SM as Secret Manager
  participant PS as Pub/Sub Topic
  participant R as Rotation Function
  participant DB as Target System
  SM->>PS: Rotation due notification
  PS->>R: Trigger rotation
  R->>DB: Create new credential
  R->>SM: Add new secret version
  R->>DB: Verify new credential works
  R->>SM: Disable old version later
        

A safe rotation pattern

Expiration and delayed destruction

One of the most common design questions is whether an application should ask for a specific version or for the newest one.

Choosing between them

For secrets that change often and where your application can handle changes smoothly, using the latest alias reduces manual work. For critical systems where you want controlled rollouts and easy rollback, pinning versions and updating the reference as part of a deployment gives more control. Many teams pin versions in production and use latest in development.

A vault is only useful if your applications can get secrets easily and safely. Google Cloud services offer several ways.

Three delivery styles

flowchart LR
  SM[Secret Manager] --> CR[Cloud Run Service]
  SM --> GKE[GKE Pods]
  SM --> VM[Compute Engine Application]
  SM --> CB[Cloud Build Step]
  CR --> APP1[Application Uses Secret in Memory]
  GKE --> APP2[Application Uses Secret in Memory]
        

A vault without a visitor log is only half a vault. Secret Manager integrates with Cloud Audit Logs.

What gets logged

Enabling data access logs for Secret Manager is strongly recommended for sensitive environments, because it answers the key question after any incident: who read this secret and when? Because logs can be large for chatty workloads, plan for the volume and storage cost.

What to alert on

Besides identity checks, you can limit where secret access requests can come from.

The best secret is the one you never have to store. Many modern designs avoid static secrets for access to Google Cloud itself.

Prefer identity over secrets where possible

When one Google Cloud service calls another, you do not need a password or key. The calling workload uses its attached service account and receives short-lived tokens automatically, with IAM deciding what it may do. External workloads can use workload identity federation to exchange their own identity for a short-lived Google Cloud token. Secret Manager is best reserved for credentials that cannot be replaced by identity, such as third-party programming interface keys, database passwords and signing secrets.

flowchart TD
  Q1{Does the app need to prove identity to Google Cloud?} -->|Yes| A1[Use a service account or federation, no secret needed]
  Q1 -->|No| Q2{Is the value sensitive?}
  Q2 -->|No| A2[Use normal configuration]
  Q2 -->|Yes| Q3{Can the operation be done by KMS without exposing the key?}
  Q3 -->|Yes| A3[Use Cloud KMS]
  Q3 -->|No| A4[Store in Secret Manager]
        

Several places can hold sensitive values. Knowing the differences helps you choose.

A few secrets are easy to manage. Hundreds across many teams need structure.

Naming and labeling

Choose a clear naming standard that includes the application, environment and purpose, such as “payments-prod-database-password”. Add labels for owner, environment, data sensitivity and rotation policy. Good naming and labels make access reviews, cost analysis and incident response much faster.

Project strategy

Provisioning with infrastructure as code

Define secrets, their settings and permissions in version-controlled infrastructure configuration, but keep the secret values themselves out of that code. Create the secret containers through automation and add the values through a secure process, such as a rotation job or a one-time controlled entry by an authorized person.

Secret Manager is built for reliability, but how your application uses it affects speed, cost and resilience.

Avoid asking on every request

Fetching a secret from the API takes a network call. If your application fetches the same secret on every user request, you add delay, increase cost and risk hitting request quotas. Instead, read the secret once at startup or periodically, keep it in memory and refresh it on a schedule or when authentication fails.

Plan for outages and quotas

Secret Manager costs are usually small, but they scale with the number of versions and the volume of access.

Ways to manage cost

Even good teams sometimes leak secrets. A prepared response limits the damage.

Patterns capture what experienced teams repeatedly find works; anti-patterns capture what goes wrong.

Helpful patterns

Anti-patterns to avoid

An honest view of strengths, limits and where teams actually use Secret Manager.

Real-world examples

A checklist to carry into every project, followed by answers to common beginner questions.

A secret is the named container with settings and permissions. A secret version holds an actual value. You add new versions to change the value, and each version is immutable.

No. Versions cannot be edited. You add a new version with the new value and then disable or destroy older versions as appropriate.

Not by itself. It can notify your automation when rotation is due through Pub/Sub. Your function or workflow creates the new credential and adds it as a new version.

Use latest where automatic pickup of rotations is valuable and your application can handle changes safely. Pin versions for critical systems where you want controlled rollouts and easy rollbacks.

Only the specific workloads that need each secret, through dedicated service accounts with the Secret Accessor role on that secret. Human access to payloads should be rare, justified and logged.

Yes. They are encrypted in transit and at rest by default. You can also use customer-managed encryption keys if your policies require control over keys.

Cloud Run can expose a secret as an environment variable or a mounted file, and GKE can deliver secrets through integrations or fetch them using workload identity. Check current documentation for the options.

Usually not. Use attached service accounts and IAM, which provide short-lived credentials without storing any secret.

Secret Manager stores and delivers secret values such as passwords and tokens. Cloud KMS manages cryptographic keys and performs encryption and signing without exposing the key itself.

Enable data access audit logs for Secret Manager. They record which identity accessed which secret and when, though they never record the secret value.

Not after destruction completes. If you configured a delayed destruction period, you may be able to recover during the delay. Disable versions first and destroy only when sure.

Treat it as compromised: create a new credential, add it as a new version, switch workloads, revoke the old credential, review logs and fix the cause. Removing it from a repository is not enough.

Secret Manager is Google Cloud’s managed vault for sensitive values such as passwords, tokens and keys. Each secret is a named container with its own settings and permissions, while the values live in immutable, numbered versions that can be enabled, disabled or destroyed. Encryption, IAM at the secret level, audit logging, perimeters and customer-managed keys protect them, while replication and regional options address availability and residency. Rotation is supported through scheduled notifications that drive your own automation, and workloads on Cloud Run, Functions, GKE, Compute Engine and Cloud Build can read secrets using their own identities. The strongest designs combine the vault with habits outside it: use identity instead of secrets wherever possible, grant narrow access, separate environments, cache carefully, never log secrets and practice rotation before an emergency. Because features, limits and prices change, confirm specifics in current Google Cloud documentation.