Replicated with Less Privileges

Marc Campbell
Feb 10, 2017

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:

  • A new replicated user is created on the host and added to the docker group
  • The replicated containers are started so that the process inside the container is owned by the replicated user on the host
  • Replicated dependencies such as statsd, graphite and premit all inherit the same user and group permissions
  • Filesystem permissions in /var/lib/replicated, /var/run/replicated are 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:

  • When gathering a support bundle, some logs on the file system aren’t accessible by the replicated user
  • When installing an application or an update, some volume definitions may require replicated to use a different user account to create
  • Snapshots might require elevated permissions, depending on the location of the source and destination


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.

Application Containers

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.