A non-root Cloud Run container starts but cannot read its mounted secret file

0 reputation · 15 Jun 2021, 09:00 UTC

126.5K views2

An example container was changed to run as a non-root user. It starts, but reading a mounted Secret Manager file fails. The team verified that the runtime service account has secret access. What should be checked next, and why is this different from an environment-secret startup failure?

Environment

Editorial worked example. See the question for the scenario and assumptions.

3,824 following

Keep exploring this topic

A Cloud Run revision deploys, but new instances cannot retrieve an environment secret

A worked Cloud Run example references an enabled Secret Manager version as an environment variable. The deployer’s account can access the secret. The service uses a dedicated runtime service account, and new instances fail around startup. Which identity and permission should be checked?

Why do Cloud Run instances see different values when an environment secret uses latest?

A fictional service exposes a secret through an environment variable using latest. After rotation, older instances keep working with the previous credential while newly started instances use the new one. The application team expected an immediate, simultaneous update. What deployment approach gives a more predictable result?

Google IAM Policy Troubleshooter says allowed, but a storage request still fails

A service’s storage request is denied. In this illustrative case, Policy Troubleshooter reports that the named principal has the permission on the resource. The team has not checked whether the actual call crosses a VPC Service Controls boundary. Does the allowed result settle the whole access question?

Public Access Prevention and Legacy ACL Evaluation Order

Public Access Prevention vs legacy ACLs: evaluation order and automatic revocation behavior for AllUsers read access.

Check the configured mount path, the application’s expected file path and access under the container’s actual user. Google’s documentation describes ownership differences across Cloud Run execution environments and deployment arrangements. Service-account permission and in-container file access are related but distinct checks.

A mounted secret can fail when the application reads it during runtime. That is different from environment-secret retrieval before instance startup. Capture the exact failure category without logging contents. Validate the fix with the same container user and deployment arrangement rather than testing only as root in a local shell.

A non-root Cloud Run container starts but cannot read its mounted secret file

2 answers

Your perspective belongs here.

0 question comments