Delivery method is part of rotation
Cloud Run can expose a Secret Manager value as an environment variable or as a mounted file. These are different application contracts. An environment variable is resolved when an instance starts. Updating the secret does not rewrite the environment of an already running process. Official guidance recommends using a particular version for this delivery method rather than relying on latest.
Mounted secrets offer a rotation-friendly access path, but application behavior still matters. A program that reads a file once and caches the credential indefinitely will continue using its cached value. A program that reloads safely can adopt a new version when the mounted reference permits it. Secret publication, dependency credential validity, and process reload are separate stages to coordinate.
Prepare a nonproduction secret and a test dependency account. Identify the Cloud Run service identity, secret version reference, environment or mount path, and application cache policy. Obtain read access to configuration without retrieving production secret payloads. Define how long the old and new credentials can overlap at the dependency.
Build the rollout procedure
- Inspect
gcloud run services describe payments --project=PROJECT_ID --region=REGION --format=export. Locate the secret reference and version on the relevant container. Check whether the deployed service actually uses the expected mount or environment variable, especially if multiple deployment systems have touched it. - Trace the application's read path. For environment variables, plan a new revision pinned to the new version. For mounted files, define when the process reopens the file and replaces active client connections. Avoid logging the value to prove it changed; use an approved version identifier or a harmless authentication probe.
- Publish a test credential through the normal rotation workflow, preserving an overlap period where the dependency permits it. Verify a new instance and an existing instance separately. They can behave differently if only startup reads are implemented.
- Move production through a reviewed staged rollout. Keep the previous secret version enabled until the rollback plan no longer needs it. Disable the old dependency credential only after confirming that all intended callers have adopted the new one.
Illustrative scenario
A fictional inventory API has long-lived Cloud Run instances and reads its database password from an environment variable at startup. An operator adds a new secret version and sees successful authentication from newly started instances, while older instances continue using the prior password. The correct fix is a deliberate pinned-version revision rollout with credential overlap, followed by verification across revisions. Merely waiting for an unpredictable instance replacement is an incomplete rotation plan.
| Symptom | Evidence | Corrective action |
|---|---|---|
| Only fresh instances use new credentials | Environment version and instance age | Roll out the pinned revision |
| Mounted value changes, application does not | Reload and client-cache behavior | Implement a controlled refresh |
| Rollback revision cannot authenticate | Old credential and version state | Preserve the rollback overlap |
| Some containers still use old settings | Container-specific references | Update the correct container contract |
Verify without exposing the secret
Confirm revision configuration, dependency authentication success, and application error rate. Exercise the real business operation with a safe test record. Use correlation identifiers rather than secret values in logs. If clients maintain connection pools, verify that replacement connections authenticate successfully; a healthy old connection can hide a broken new credential.
Rotation operating procedure
Document the secret owner, dependency owner, overlap window, reload mechanism, rollout checkpoints, and rollback requirement. Monitor authentication failures by revision during each rotation. Rehearse with test credentials after library or runtime changes. Remember that a Secret Manager rotation schedule sends notifications; the workflow must still change the dependency credential, publish the version, and coordinate adoption.
Explore Clouvenix cloud security for implementation and operational handover.