Gremlin Docs
Dashboard
Security

Container Security

Gremlin containers run as root

When Gremlin runs within a container, gremlin processes run as root. This is because there are several file resources that Gremlin must mount from the host which are owned by root on the host machine:

  • /var/lib/gremlin and /var/log/gremlin: These are mounted from the host into the Gremlin agent container and sidecar attacks. By default, container runtimes will set the ownership of these resources to root:root
  • Container runtime sockets (e.g. /var/run/docker.sock), which by default will be owned by root

Mitigating the privileges of root

Though Gremlin runs as root within the container in which it runs, Gremlin is restricted by the specific capabilities it requests, despite running as root. Here are some other mitigations system administrators can make to reduce the impact of Gremlin's usage of root:

  • While Docker's default seccomp profile is already fairly restrictive, you can remove any undesired syscalls by overriding this default, or provide a more restrictive seccomp profile to Gremlin containers.
  • Avoid running Gremlin within the network or process namespace of the host. For Docker, avoid docker run --net=host --pid=host). Note that this will disable Gremlin's ability to run host-level Network and Process Killer attacks.
  • Consider an extra layer of safety by enabling AppArmor, SELinux, GRSEC to harden all containers running on your systems

Alternatives

If you do not wish to run Gremlin as a root user, even with the restrictions described above, consider installing Gremlin directly onto the host where it runs under a dedicated Linux user: gremlin.

Other resources

Previous