file access and user id philosophy in containers.

[petersilva]

I'm new to docker and cloud in general, so just doing the default thing (everything is root) for now, similar to how the demo doesn't bother with SSL) and not worrying about it. I had some discussions with @tomkralidis about the topic, and I don't really have any conclusion so I thought I would document the concerns/issue. Each container often needs access to local files, and they will use a user id to establish their permission to write files, and allow other processes using the same files to read them, or prevent same.

It's unclear if this is important or not. Some say this is not an issue because in true cloud environments, the username does not matter and there is no possibility of corrupting the calling host.

Normal development environments avoid the use of the root account, and it is longstanding best practice to develop code without requiring root access at all, or at least minimizing it. Default docker uses root for everything, and root of the container is pretty close to root on the host. As a long-time unix/linux admin, this is surprising, violating the https://en.wikipedia.org/wiki/Principle_of_least_astonishment.

Files Are Shared

Whatever is done, one must also contend with the current design of wis2node, where the data consumer and the wis2node containers read and write files in common directory trees, and likely a third container, responsible for cleaning out old files will also access the same file areas. So the user-id approach among at least these three containers need to be consistent, in that they must allow appropriate reading and writing of files created by other containers. To eliminate sharing of files is simple, put all the wis2node/data-consumer and cleaning functionality into a single container. That's straightforward to do... but unsure if it is desirable.

AllRoot: Default Docker Behaviour

So if you have a linux server/workstation as the host on which you run the docker containers, and you run a container that does nothing for set it's effective uid, it will run as root be able to read/write "anything". The definition of the container is all that constrains where it can write to... so... no problem :-)

benefits:

• dead simple, one can always write to the files on needs.

disadvantages:

• basically this has all the downsides of running an application as root, considered poor security practice
  • violation of https://en.wikipedia.org/wiki/Principle_of_least_privilege in that uid's are shared among container and host... so root in the container is root in the host... albeit with some limitations.
  • avoid use of root when you just need a privileged port, etc... principle of https://en.wikipedia.org/wiki/Privilege_separation
• if developing as non-root account on host, one must use sudo to clean up/manage: slight inconvenience.
• incorrect 'volumes' configuration can make sensitive areas of host vulnerable to corruption, either by inadvertant or malevolent actors . Security concern for availability (inadvertance) and Integrity (malevolence.) ability to take down host, violation of container isolation.

HostUser: Import user from Host

This is what I expected to happen with container... I expected that the container would run root in the container, but mapper to my userid in the host, so it would have the same file permissions as my user. One has to configure docker to behave this way.

references:

• https://jtreminio.com/blog/running-docker-containers-as-current-host-user/#ok-so-what-actually-works

This results in adding something like:

ARG USER_ID=`id -u -n`
ARG GROUP_ID=`id -g -n`

RUN  groupadd -g ${GROUP_ID} wis2node &&\
    useradd -l -u ${USER_ID} -g wis2node &&\

USER wis2node

This doesn't actually work for me so far... the container always exits immediately.

benefits:

• writing on host os works as expected (principle of least surprise.)
• container code runs as 'wis2node' fixed username, can be used in containers (e.g. ~wis2node)
• container code does not run as root (many security benefits.)
• id is consistent among different containers (each one must define the user.)
• does not rely on host user scheme (say in LDAP) so does not require container to understand entire authentication architecture of host, it just uses host user and group-id as given, and provides a fixed name for use in the application.
• all code

disadvantages:

• every container needs the above code to provide consistent user definition.
• if the code really does use root, this would be a problem.

FixedUser: Define a user for use in the host

One coulde define a specific uid/gid combination to be used by all containers... difference to the above approach would be to fix USER_ID and GROUP_ID to 1000, for example, so all files would be written as uid & gid 1000, rather than importing from the host.

Benefits:

• perhaps can define directory permissions to be more constrained, so container cannot write in any host user file directories.

Disadvantages:

• still need sudo (root access) to manage files, as current development user may not have rights to clean up.

There may be other options... these are the ones I noticed.

General disadvantages (all approaches so far):

• username is set at image build time. Some people might want to distribute images, and have the user chosen at container run time.

[petersilva]

wrinkles: alpine linux has only a rudimentary 'adduser' whereas full fledged linux distributions have useradd... the options are all different. Meaning different containers, with different baseOS, might require different methods to create users...

[petersilva]

@webb-ben mentioned 'rootless mode' so looked that up... https://docs.docker.com/engine/security/rootless/

[webb-ben]

@petersilva I didn't see this! But yes I am having trouble figuring out the test workflow in Github Actions because the actions vm user is not root. However, like you said, the default docker deployment run containers as root which causes permission errors. I am still orienting myself with docker but happy to try to think through this however possible... especially once I figure out my own issue :)

[petersilva]

@webb-ben fwiw... I ended up switching my images to use root for now. Maybe later, we can figure out non-root... this issue just documents the exploration.