GCP Secret Manager: A Complete Guide to Secrets Management

GCP Secret Manager: when secrets live in code

In almost any infrastructure older than a year, secrets do not live in one place. Database passwords sit in configs next to code, keys to external services in environment variables on servers, access tokens in repositories and on developers' work machines. Some values are duplicated: the same value is changed in three files and the fourth is forgotten.

The cost of this picture does not show immediately. A secret leak in code is discovered only after the key has already reached a public repository or build log, and revoking access takes days: you need to find every place where the value is used, update configs, restart services.

Manual access rotation turns into a night operation with the risk of taking down the production environment, so it is postponed—and the same key lives for years. A separate problem is a dismissed employee: their access remains active until someone remembers it manually.

Infrastructure secret auditing in such a scheme also does not add up. You cannot quickly answer who and when got access to the value, which services read it, and what exactly will break when access is revoked.

GCP Secret Manager closes this gap: values are stored centrally, issued based on permissions, versioned, and recorded in an access log. Below we break down how this works and what changes in daily work.

What centralized secret storage gives

Secrets spread across a project unnoticed: a file with passwords in a repository, variables in build pipeline settings, copies in service configurations.

Each copy is a separate point where the key will survive an employee's dismissal, a release rollback, or an environment change. Centralized secret storage reduces everything to a single source: the service reads the value by reference at startup and does not store it itself.

Google Cloud Secret Manager issues a secret by name, and access is governed not by a file but by binding account permissions.

Therefore, the time to fully revoke access is measured in minutes: remove the role—and all services that read the secret through it lose access simultaneously, without visiting hosts or editing configurations by hand.

Secret versions are retained, so the value can be returned to a previous one without losing history.

Automatic rotation stops being a week-long campaign. The scheduler creates a new version, the application picks it up on the next read, and the old one remains available during the transition—there is no window when the service is left without a working key. Instead of manually going through dozens of services—one setting and a check of the result.

The secret access log shows which account, when, and which version was read or changed. Incident analysis turns from hypotheses into reading records: you can see whether a request came from an unexpected place.

A whole class of failures disappears when a key remains in a config, build logs, or container image—a centralized source does not create such copies.

Options for organizing access: comparing approaches

The method of delivering a secret to an application is usually chosen by inertia: whatever was at hand at the start stays in production.

The difference between the options shows during rotation and incident analysis—there you can see who reads the value, how quickly it is revoked, and whether a trace remains in access logs.

A managed storage such as GCP Secret Manager covers versioning, service-account-level permissions, and access auditing—but only if the application can read the value at runtime rather than during image build.

The working scheme in most mature environments is a hybrid: the value itself resides in the secret storage, while a short-lived access token issued at startup goes into an environment variable or file.

Then rotation does not require restarting the service, and a leaked variable stops being a problem after a few minutes.

Implementation stages: from audit to handover

We carry out the work in stages because secrets are accesses to the production environment, and there is no room here for a "let's try first, then see" approach.

The order is structured so that each step has a rollback point: first the full picture, then the access model, and only after that changes in production. Below is the sequence we follow to implement GCP Secret Manager.

1. Secret inventory: collect all places where keys currently reside—configuration files, environment variables, repositories, correspondence, and engineers' notes. The output is a registry with the owner, purpose, lifetime, and criticality of each entry.
2. Access policy design: mark out who needs rights to what, separate reading and administration, and tie access to service accounts rather than people. Separately record who can create new versions and delete old ones.
3. Migration planning: move secrets in batches by service, with dual reading during the transition period, so the application picks up the value from the new storage and does not depend on the old source.
4. Rotation setup: define the value change period and rules for retaining previous versions—scheduled rotation must not break a running service and must leave a rollback window.
5. Failure-based rotation testing: change the value on a live environment and see whether it was picked up without manual intervention. Separately test service behavior when storage is temporarily unavailable.
6. Handover to operations: hand over the secret registry, access scheme, rotation schedule, and incident response procedure. Record the responsible parties and the point of contact when the environment changes.

Set of documentation, diagrams, and regulations

Work with GCP Secret Manager does not end with configuring the storage—it is important that the customer's team maintains and develops the scheme without us.

Therefore, at the output we hand over a set of artifacts tied to the project's real configuration, not to a template from the documentation.

• Inventory of storages and secrets — purpose, owner, environment, consumers. You can see what production holds and what can be cleaned without risk.
• Role matrix — a table of "role / what it reads / what it changes / who grants access": service accounts receive read access only to their own secret.
• Service access diagram — how the application obtains the value, where permissions are checked, what happens on revocation, with failure points marked.
• Rotation regulation — frequency, the "new first, then revoke old" switchover procedure, the responsible person, and how to verify that consumers have picked up the value.
• Emergency revocation procedure — step-by-step order during a leak: what to block first, how to reissue, and how to make sure old values no longer work.
• Instructions for connecting a new service — how to create a secret and grant access according to the matrix without reading internal correspondence.
• Audit and monitoring — which log records to review to notice extra reads or access outside the regulation.

We keep this in the same repository as the configuration: the document is updated with the same change as the setting. Otherwise, in six months the scheme diverges from reality—and people stop reading it.

Case: rotating access keys without stopping services

The client is a payment service, eight applications in the production environment, and access to databases and external APIs was stored in environment variables and partly in the configuration repository.

Rotating one key took 3–4 days: an engineer changed the value, restarted applications one by one, and went around to teams so no one forgot to update a local file. Over a quarter, 14 active keys accumulated whose owners no longer worked on the project.

What changed

Secrets were moved to GCP Secret Manager and applications were switched to reading the value at startup with periodic refresh from the storage—a restart for key change is no longer needed.

Rotation became a secret version change: a new version is enabled for one application, verified via access logs, then for the next. Access was granted via service accounts with rights only to the required secrets, and each secret got an owner and a lifetime.

Result

The previous secret version remains available, so rollback on failure is a reference switch, not a restore from backup. Access logs show which application read the secret and when—incident analysis no longer hinges on polling the team.

If your rotation is tied to a calendar and manual tasks, describe the current scheme—we will come back with a plan for migrating to versioned storage.

How does managed storage differ from environment variables?

Environment variables are a snapshot of configuration at process startup: the value ends up in the pod description, memory dump, and debug logs. While there is one environment and one secret, this goes unnoticed.

As soon as there are three environments and four services need database access, the differences show across four axes.

The difference in revocation is fundamental: during a leak, the secret is disabled in the storage, and consumers get a denial on the next request, without a release.

With environment variables, workloads must be restarted—and the window when the leaked key is still valid stretches for the duration of deployment.

The read log closes the investigation: you can see which service and under which account took the secret—this cannot be reconstructed from manifests.

At the same time, environment variables are not bad in themselves: it is easier to keep a service address in a manifest, and move only what grants access to data into storage—Secret Manager or an equivalent.

Technical doubts: isolation, revocation, audit

Doubts about isolation and revocation surface not at the start, but when several teams and environments use secrets at the same time. Below are answers to the four questions most often asked before moving production keys to Secret Manager.

Who sees the contents, and can I encrypt with my own keys?

Values are encrypted on the service side, and if necessary a key from your key storage is attached—then access to the data is closed even to the platform. Rotation of such a key happens without reissuing the secrets themselves; old versions remain readable.

What goes into the access log?

Every read, change, and permission grant is recorded in the audit: who, when, which secret, and which version was accessed. The log resides separately from secrets and is exported to external storage, so access to a secret does not make it possible to clean up traces.

What about backup and rollback?

Versions are immutable: the previous value remains available, and rollback is a switch to the previous version, not a restore from a copy. We separately keep an export of the secrets configuration and access policies—it covers the scenario of complete project loss.

Let's discuss your task: where to start

So that the estimate is substantive and not "plus or minus a quarter," the first conversation starts with a review of the current scheme.

We need only a description of how secrets live now: where keys to databases, payment and external services are stored, who reads them, and what happens on change.

This way we understand the scope of work for migration to GCP Secret Manager and come back with a plan and a time estimate in business days.

What to send before the meeting:

• list of services and environments—development, test, production—that need secrets;
• current storage locations: files in the repository, build system environment variables, manual insertions during deployment;
• access scheme: which service accounts and employees read which secrets;
• rotation procedure: how often keys are changed, who does this manually, and what breaks after a change;
• audit and isolation requirements: whether separate storages per environment and secret version history are needed;
• list of external systems for which access needs to be coordinated on your side.

The first conversation takes about an hour and follows your scheme, not our presentation.

Based on its outcome, you receive a migration plan: in what order to move services, where to leave old keys during the transition period, how to verify that the application starts with new secrets, and at what point to disable the previous method.

Timelines come with a breakdown by stage—you can see what our engineers handle and what depends on your team.