18

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="vincent@serpoul.com"

# 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):

VsM
  • 710
  • 1
  • 10
  • 23
  • 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 :) – Jannis May 08 '20 at 12:55

3 Answers3

26

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.

Nishanth Kottary
  • 363
  • 3
  • 4
  • 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. – Paul S Mar 05 '22 at 21:40
  • 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. – David Aug 11 '22 at 02:39
  • 1
    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) – scott Jun 28 '23 at 18:23
1

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
Peter VanderMeer
  • 153
  • 7
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.

lependu
  • 1,160
  • 8
  • 18
  • 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 parity – VsM Nov 20 '18 at 07:50
  • Did you try to `chown` the added files? – lependu Nov 20 '18 at 07:54
  • Also note that in this case i think `COPY` is more appropiate than `ADD`. – lependu Nov 20 '18 at 07:58
  • 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). – VsM Nov 20 '18 at 08:59