When deploying a secure system it is important to ensure that each component only has access to the lowest level of privileges needed to perform its task. This concept should apply to any access in a system, including the user account and file system permissions need to spawn processes successfully.
Replicated runs in Docker containers on the host server(s). Docker currently requires root (or root-equivalent) to run. But Replicated doesn’t require root privileges to perform most tasks.
Starting with Replicated 2.5.0, we no longer run as root. Specifically, we’ve made the following changes when running the easy install script:
replicateduser on the host
/var/run/replicatedare owned by the replicated user and the docker group, instead of root
There are some times during execution that replicated requires higher level access than the
replicated user provides. When this happens, replicated will create a child process that executes as root. These processes are short lived and only created when needed. It does this by creating a new Docker container (this time as root) to execute a command. Some examples of when this might occur are:
For customers running
2.3.0 or later and using auto updates, installations will be upgraded to
2.5.0 but will continue to run as the root user. For current customers to opt in, they can simply run the easy install script (or airgap install script) at any point (before or after auto upgrading to 2.5.0). This will change the permissions on the filesystem and will create the replicated user.
All of the containers for the application that we deploy continue to run as the user identified in the Docker image (default is root). Today, you can customize the user in your Docker image with your
Dockerfile and make it the owner of your application’s processes. Going forward, we are working on features which allow you to configure Replicated to deploy containers with a custom user.