Make docker container images run as non-root users about developer-scripts HOT 8 CLOSED

I noticed that some services are still running as root user:

@hahattan , secretstore-setup and security-bootstrapper will always run as root. kuiper will run as non-root in the next release coming this month. consul, redis, vault, kong-db run as non-root. What you are seeing is the entry point scripts, not the actual process for those services which run as their own user.

from developer-scripts.

@bnevis-i are the UIDs unique with respect to a pod/namespace or with respect to a physical host? How does Kubernetes handle the issue of launching pods/containers in this non-root mode? In this early phase of only single node EdgeX instances with countably many microservices, this is not a significant issue, but concerned about multi-node, multi-tenancy, dynamic scaling, and user defined device services (could have a numbering convention here). What are the ramifications of 2 docker containers deploying with the same non-root user-id?

from developer-scripts.

Are the UIDs unique with respect to a pod/namespace or with respect to a physical host?

I am proposing unique with respect to the other EdgeX services. It is pretty much random whether or not this UID matches anything on the host, or the UID used in another container. For security services, it would add an additional layer of protection to ensure that one container could not read another containers secret store authentication token even if it found a way to read arbitrary files on the host file system with non-root privileges.

A well-written microservice would not know or care what UID it got mapped to on the host.

How does Kubernetes handle the issue of launching pods/containers in this non-root mode?

Kubernetes has a setting runAsUser as part of PodSecurityContext that allows specifying the UID under which to run a container. (In docker-compose it is called uid.) Kubernetes talks to a Container Runtime Interface (CRI) which abstracts away the actual container runtime. If the container runtime was docker with userns-remap enabled, then there would be an additional remapping of UIDs with respect to the host. Otherwise, containers will switch to the USER specified in the Dockerfile unless the container explicitly changes users (Vault does this). The UID in the container will map to the same UID on the host unless userns-remapping is enabled, in which case the UIDs will to the host appear as if a fixed offset had been added. This offset would be the same for all containers running on a particular host, but if the hosts are not identical, they could be remapped to different UIDs on different hosts.

What are the ramifications of 2 docker containers deploying with the same non-root user-id?

If two containers were sharing a bind mount to the host or sharing a docker volume, the services would be able to read/write each other's files. This may be OK if the services in question can share a trust boundary; otherwise care would need to be taken to ensure that the services could not see each other's files. This could mean that each service uses a different volume mount, or that that the service has a unique ID when talking to a storage layer like a database. (e.g. a service-specific username and password).

In a distributed system, one would be unlikely to use a file-system mediated data sharing mechanism. In the case of Kubernetes, the secret store authentication token would best be distributed as a Kubernetes secret; they could be updated at runtime and they new values would be reflected at runtime. Docker Swarm supports secrets but they are essentially constants. Plain Docker doesn't natively support secrets at all, which greatly limits the solution space.

The majority of the security benefit is achieved by not running container processes as root.

from developer-scripts.

Finally found the switch in Kubernetes that allows overriding of user ID. Updated above reply.

from developer-scripts.

pending edgexfoundry/edgex-docs#206 and should be compliant on the result

from developer-scripts.

ADR is done. Removing block label. Up for consideration for Ireland.

from developer-scripts.

address by #374

from developer-scripts.

@lenny-intel @beaufrusetta
I noticed that some services are still running as root user:
consul, redis, secretstore-setup, security-bootstrapper, vault, kong-db, kuiper

Are we planning to make them run as non-root user eventually or the root privilege is necessary for them ?

thanks

from developer-scripts.