-
Notifications
You must be signed in to change notification settings - Fork 241
Provide ENV variable for runtime user? #86
Comments
I can certainly see an argument for making the user configurable, but we'd have to, somehow, dynamically create the user inside the container. Without that extra logic, once inside the container, there is no user that represents "me":
We explicitly create the If you really want to replicate your host-system user inside the container, you could consider making a custom image. You could do something like this: $ cat > Dockerfile <<EOF
FROM docker.elastic.co/elasticsearch/elasticsearch:5.5.0
USER root
RUN userdel elasticsearch
RUN groupadd -g ${UID} ${USER}
RUN adduser -u ${UID} -g ${UID} -d /usr/share/elasticsearch ${USER}
RUN chown -R ${USER}:${USER} .
USER ${USER}
EOF
$ docker build . -t my-es:5.5.0 Edit: Removed unneeded "ARG" statements from example. Really though, this is deliberately working around the isolation that the container environment is carefully trying to provide. I don't know anything about your use-case, forgive me, but is it worth considering simply running Elasticsearch on the host-system? That way, you'd avoid the extra complexity that the container environment introduces. |
For a bind mounted config dir (say, you want to provide a customized Observe the following example:
The key thing to note is that you don't need to override the entire conf dir, you can mount a specific file. For entire dirs, just ensure the dir has For the data dir ( |
The real issue here - IMHO - is that the security requirements for
production and development are significantly different. For efficient
development I need to manipulate things in a way I would never allow in
production. The use case goes something like this: I want to observe/test a
configuration change. I edit the bind mounted elasticsearch.yml or log
properties in my local development environment (IntelliJ), bounce the
elasticsearch server in the container, and observe the change.
Under the current scenario I am required to make the change, rebuild the
container and redeploy. Not horrific, but a nuisance.
Toby's solution - as he admits - is a hack that seriously compromises
container security in production.
The o+r bind mount option Dimitrous presents doesn't help because I need to
be able to modify the elasticsearch.yml or log4j properties file so I need
write privileges.
The Fluentd container provides another solution. The FluentD docker
container is structured such that for development I can run as any user I
want, while in production it will run as a given user: fluentd.They
accomplish this by defining a FLUENTD_UID environment variable and using
the entrypoint program to define a user and set permissions (See
https://github.com/fluent/fluentd-docker-image/blob/master/entrypoint.sh.erb)
rather than embedding it in the Dockerfile. For development purposes I use
a docker-compose.override.yml with my FLUENTD_UID set to my uid. In
production it remains unset and reverts to the default.
Thanks for the response!
…-steve
|
@snesbittsea You are welcome! Note that you don't lose your capability of editing files locally by granting If you are bind mounting dirs, you need to remember the |
This might be worth a new Github issue, but for my problem, I'd like to see this thread renamed as:
There is a genuine use case for a customisable uid/gid; having a mechanism to cater for this is pretty common in Docker-land. Having not thought about it particularly hard; would it be possible to actually implement this in a secure fashion with the stock container? ~# usermod -u 2005 elasticsearch
~# groupmod -g 3000 elasticsearch
~# find / -group 2000 -exec chgrp -h elasticsearch {} \;
~# find / -user 1005 -exec chown -h elasticsearch {} \; My containers run in a massively convoluted environment - on hosts that contain a standard operating environment out of my control that end up with hundreds of uid/gid combinations; in these cases I could end up with a conflict giving some random user or group the ability to destroy all our data. ~# lslogins | wc -l
251 @jarpy - Dockerfile and Jenkins are my current solution to addressing this and other non-standard changes to the stock Elastic containers. Whether or not this is addressed is not the end of the world to me. @dliappis - I agree, that using a Docker volume is an elegant solution to this problem and would remove the need for this specific requirement in the first place, however, in my specific example it's not practical for me to move 10's of TB of elasticsearch data into Docker named volumes; particularly when I haven't tested the extent of Docker named volume performance in my environment. Just adding some ⛽ to the 🔥 🚒. |
Closed by #125, support will come starting with version 6.0 |
@dliappis The documentation on 6.4.3 suggests that there is still no support for this. |
Is there a reason that the runtime user - elasticsearch - is hardcoded rather than set as an environment variable with a default value of elasticsearch.
Maybe my ignorance is showing, but for development having the owner of a bind mounted config directory someone other than me seems an unnecessary aggravation and burden.
Thx!
-steve
The text was updated successfully, but these errors were encountered: