Docker secrets file runtime access woes

The Render docs say Docker services can access secrets files at runtime. I kinda assumed that meant when the container was run, there was a volume mount for any such files, e.g. (in docker-compose syntax):

- .my-secret-file.json:/etc/secrets/my-secret-file.json:ro

or equivalent. Indeed, when I run docker compose on my containers with this, and refer to the file with an env var:
GOOGLE_APPLICATION_CREDENTIALS: /etc/secrets/my-secret-file.json

every thing works swimmingly. However, the same containers deployed to fail - the credentials file is not read (I think that’s the problem, I get a 401 unauthorized from Google).

I thought based on earlier topics here that the issue could be permissions-related, but I have tried Render deploys in which the Docker container had root privileges and ones where it did not.

Any suggestions gratefully received, and I’m happy to share my Dockerfile, or render config if it helps.

Richard R

Hi Richard,

Render doesn’t support docker-compose yet, but you should be able to access your secret files by making a few changes to your Dockerfile outlined in these docs. Let me know if that helps!

Hi Tyler,

Thanks for responding. I’m aware of those docs, but IIUC they pertain to a different use case - where the secrets file is made available to the container at build time. I need runtime access, and don’t want to embed the secrets in the container image (security problem). I only used docker compose as an example of a runtime configuration that works for me - sorry if I left the impression that I thought Render supported compose (or should), I realize it does not.

I’ll keep digging and experimenting, and please let me know if I misunderstood your point.

Regards and thanks again,

Hi Richard,

My apologies I misunderstood your question. Docker services should be able to access environment variables and secret files like other kinds of services at run time. All secret files you create are available to read at the root of your repo (or Docker context). They are also available to load by absolute path at /etc/secrets/. I am taking it that this is not the case for your service, do you mind sharing the name of the service so I can take a look?

Hi Tyler,

Not at all - it’s Let me know if there is anything else you’d like to examine.
Thanks, Richard

Hi Tyler:

Another data point: I just redeployed the service with the secrets file now embedded in the container, and it is processed correctly (read and passed to a Google service).
I can proceed with this work-around, but ultimately would like not to have to put secrets in code repositories. I’ll keep tinkering…