Cloud Run secrets: choose predictable startup and rotation behavior

A Cloud Run deployment can be syntactically correct while instances fail because a secret cannot be retrieved. Secret configuration is part of the runtime dependency graph. The important questions are which service account reads it, when the value is resolved and what the application does if access disappears.

Establish the runtime identity

Confirm the service account configured for the Cloud Run service. Grant only the necessary secret-access permission at the intended scope, commonly Secret Manager Secret Accessor for the particular secret. Permission held by the person deploying the service does not automatically provide secret access to the container’s identity.

If the secret lives in another project, verify the full resource reference and permissions in that project. Check whether the chosen secret version is enabled. Use metadata and access checks during diagnosis; do not copy secret values into deployment output to prove that they exist.

Choose a resolution model deliberately

For an environment variable, Cloud Run retrieves the secret before starting an instance. Retrieval failure prevents that instance from starting. Google recommends selecting a specific version for this method. Pinning makes a revision’s configuration understandable and avoids different instances acquiring different values merely because they started at different times.

Mounted secret files offer a different rotation path. The platform fetches the secret when the mounted value is read, and an inaccessible secret can produce a read failure during runtime. Application behavior still matters: a process that reads the file once and caches the result will not necessarily adopt a later value just because the file-backed mechanism supports rotation.

Make rotation an application change

Decide whether the downstream service can accept both old and new credentials during a transition. Introduce the new version, verify access and test a revision or limited traffic path before moving all requests. Keep a documented rollback option while the older credential remains valid, then retire it deliberately.

For mounted files, verify file paths and access under the container’s actual execution user. Ownership differs across execution environments and deployment arrangements. A non-root image is useful, but it still needs permission to read the mounted file.

Test both success and failure in a safe environment. Confirm how startup failure appears, how an in-process read error is handled and whether logs remain free of secret material. Document the version-selection policy next to the deployment configuration so future rotations do not depend on memory.