Why is it ElasticSearch is not allowed to run as root


(Lin Zhao) #1

I'm deploying ElasticSearch inside of a Docker container, which usually run processes as root user. I get "org.elasticsearch.bootstrap.StartupError: java.lang.RuntimeException: can not run elasticsearch as root" error when trying to start ElasticSearch, and there doesn't seem to be a way to get around it (alpha5).

What's the reason ElasticSearch can't run as root? Inside of the docker container things are isolated and root processes are considered safe. I may be able to configure my image to run as non-root but it requires lots of heavy lifting and is anti-pattern to our deployment model.


(Nik Everett) #2

Running Elasticsearch as root is an anti-pattern in every other deployment model. So much so that we added the check. Elasticsearch is a networked component that has already had critical vulnerabilities (all fixed) but we've grown a healthy paranoia about this kind of thing.


(Lin Zhao) #3

"Running Elasticsearch as root is an anti-pattern in every other deployment model."

I agree in non-docker environment it's absolutely necessary to be extra cautious. But Dockerized ElasticSearch is one use case where the benefit of forcing non-root user doesn't apply. Any particular reason not to let the user decide? The old "es.insecure.allow.root" would be nice.


(Jörg Prante) #4

This is wrong. Running root processes in Docker are far from safe. If the container is compromised, the root user can do anything, because root in the container is also root on the host. This is the reason why Docker 1.10 introduced user namespaces https://success.docker.com/Datacenter/Apply/Introduction_to_User_Namespaces_in_Docker_Engine


(Lin Zhao) #5

With namespace inside of the container the processor is run by root, while outside of the container the processor is not root. So it would appears as "root" to elasticsearch and be wrongfully terminated.

Even without namespace, the docker container can only access storage mounted to the container, share of cpu/memory assigned to the container. This root user would be much safer than, for example, ec2-user in most cases.

It's simply wrong that a user must be unsafe just because it's called "root". And vice-versa. The decision should be made by the people making the deployments.


(Nik Everett) #6

At this point i think the easiest way you are going to be able to run
elasticsearch as root is to build it yourself, patching out that test.


(Jorg Heymans) #7

I agree with @lin-zhao, this should be left to the deployment peeps. I fully understand the reasoning behind it though, but not running ES as root does not make the deployment system as a whole more secure. It seems like a strang thing to impose.


(Jörg Prante) #8

The deployment system as a whole is a lot more secure if an application in a docker container is not running as root.

These are the facts:

  • a dockerized environment is not a virtual machine, so docker security is equivalent to the security of the host

  • there is a reason why only the Docker daemon runs as root and brings a lot of security mechanisms with it to defend against containers that want to escalate privileges. Only with kernel namespaces you can tackle the challenge to isolate dockerized applications https://docs.docker.com/engine/security/security/ Running as root breaks the principle of isolation, and without isolation, no security. The container infrastructure will get compromised if not secured well.

  • it's a common misconception that docker root user is safe just because the docker container can only access storage mounted to the container. What? It' s not a storage mount problem. It's a privilege problem based on kernel capabilities for the root user regarding signals, drivers, devices, and process control, even the BIOS and the system boot routine. If you are root, well then you can do whatever you want. Many attack vectors are lurking when a privileged root user runs an application in a container.

  • in the stone age of Linux, the kernel had no capability feature. Back then, you had to use the root user for even ordinary system management. These times are gone. For over a decade it's common to assign capabilities to non-root users. Even if applications want to access signals, drivers, devices, processes, they can have full control when properly being set up running as a non-root user with the exact capabilities needed. In addition to that, the Linux kernel comes with security extensions like grsec, and SELinux adds another layer of security.

  • There is no requirement for Elasticsearch to run as root user at all. Elasticsearch is not designed to be operating system specific, it does not require access to operating system specific hardware functions. All functions operate through the Java virtual machine (JVM). The JVM API is portable and hides the operating system specific APIs.

The decision not to run as root is not an option for the deployment department, it's an obligation for everyone who runs applications. This holds also for applications in docker containers. The only difference running docker is you have to ensure the same level of security for the host and the docker containers as well.


(Wkozaczuk) #9

There is one more case where requirement to run elastisearch as non-root is unnecessary and even impossible - unikernels. Unikernels run single process on hypervisor and provide single user environment. And from a Posix app perspective like JVM it would be a root user.

I am one of the contributors to OSv unikernel (http://osv.io) that allows running posix applications and JVM. I have been successful running elasticsearch on OSv and would love if old feature to allow run as root would still available. I understand that I can alway patch the code.

My 2 cents,
Waldek


(David Pilato) #10

@jasontedor Any thoughts about this last comment? I know this OS is not officially supported (and tested) - but is there a workaround to run ES 5 on it?


(system) #11