docker secrets with non root user
Asked Answered
O

3

26

I have a docker container run with a non root user for better security, but it seems it can't access the secrets I'm sharing with it:

Importing account from "/run/secrets/authority.priv.json" failed: Permission denied (os error 13)

I tried different solutions in my docker compose: 1. Setting the uid and gid to 1000 (uid/gid if the user inside the container) 2. Settting the mode to 0444 and even 0777

But none of these have worked, only using root allows me to use these secrets.

Any idea?

Bonus question: will it be the same issue within kubernetes?

The dockerfile:

FROM parity/parity:v2.2.1
LABEL maintainer="[email protected]"

# SAD but It seems impossible to read the secrets otherwise
USER root

VOLUME ["/home/parity/.local/share/io.parity.ethereum"]

ADD ./configPoANode.toml /home/parity/configPoANode.toml
ADD ./PoA.json /home/parity/PoA.json
ADD ./entrypoint.sh /home/parity/entrypoint.sh

ENTRYPOINT ["/home/parity/entrypoint.sh"]

appendix: repository (with user ROOT in the dockerfile):

Oreopithecus answered 20/11, 2018 at 3:47 Comment(1)
I'm having the same problem. Secret needs to be read by non-root user, fails. chmod and chown are also not working since it's a "read-only filesystem". Copying the content to somewhere else or saving in an ENV var makes the secret-mechanism pointless. I'd be happy for a solution :)Thisbee
S
39

Use RUN --mount=type=secret,id=mysecret,uid=1000 cat /run/secrets/mysecret

Where mysecret is what you pass to docker build --secret id=mysecret,src=authority.priv.json and uid is the uid of parity user.

Sprang answered 19/1, 2021 at 7:27 Comment(3)
Thank you for some reason this answer was hard to find. I bet > 75% of docker containers out there run as root, there are so many gotchas.Gingery
This solved my Azure authentication issue with a non-root user, thank you. Totally unrelated to parity - I'm working with Selenium - but @PaulS is right that this is hard to find elsewhere.Luminal
You can also use an ARG so you don't have to hardcode the UID (use --build-arg to set the value of the ARG)Milburt
P
3

To expand on @nishanth-kottary's answer but for buildtools (very similar), you can:

  1. run the command docker run -it --rm <YOUR_IMAGE_HERE> bash -c 'id -u $(whoami)' to get the uid of your user. Or you can use some other variation of this to get uid

  2. next, in your Dockerfile you can do

RUN --mount=type=secret,id=mysecret,uid=<THE_ID_FROM_STEP_1>,target=/run/secrets/mysecret.json \
    cat /run/secrets/mysecret.json
  1. Your build command would look like docker buildx build --secret id=pipconf,src=/run/secrets/authority.priv.json
Paedo answered 5/7, 2023 at 19:46 Comment(0)
A
0

This is because you are setting root user in the docker container and root owns all the monted volumes and files, not the parity user which I am not sure even exists.
I would dothe following:

Remove USER root from the dockerfile. It is root by default.

Check if parity user even exists in the container.

If not create it with the /home/parity directory.

Mount the volume and files as you did.

RUN chown -R parity:parity /home/parity gives the ownership of the newly created user.

Then tell the container to use the newly created user by default with USER parity

Add the entrypoint you might need to RUN chmod ug+x /home/parity/entrypoint.sh Which makes it executable for sure.

You are good to go (hopefully), you don't need to set any user when running the container, with the line USER parity it will use the parity user by default.

Agree answered 20/11, 2018 at 7:13 Comment(4)
The user is actually parity by default (from the parent image). I wanted to keep it but this is my issue, it doesnt work, which is why i added the user root. User parity already exists and owns the home/parity folder and the entrypoint is already executable. Now the issue with all that is that the secret doesnt seem to be accessible by the user parityOreopithecus
Did you try to chown the added files?Agree
Also note that in this case i think COPY is more appropiate than ADD.Agree
Thanks for the COPY, it's a good advice indeed. The issue doesnt come from the COPIED files but comes from the secrets that are mounted later on (mounted on /run/secrets).Oreopithecus

© 2022 - 2024 — McMap. All rights reserved.