Add a pelias user #2
Conversation
orangejulius
force-pushed
the
pelias-user
branch
2 times, most recently
from
f6de7b2 to
9f5cde7
Compare
|
Sounds like a good idea, couple questions:
|
orangejulius
force-pushed
the
pelias-user
branch
from
9f5cde7 to
07ffbe3
Compare
I think it will, thankfully. That was getting annoying
I really think we should stick to a roughly standard Linux filesystem layout in our containers, which would mean putting data owned by a user in
That was a change I made when I was trying out running |
There was a problem hiding this comment.
I am giving my 👍 on the principal of this, it's a good idea.
My personal preference would be to leave /data and /code at the root of the filesystem.
I know that some people might find it unconventional to add new top-level directories.
I personally find it super convenient because I don't have to dig around the filesystem looking for code and data.
I personally don't find /home/pelias/code as any more intuitive or convenient, nor is it a POSIX convention.
The symlinking is a compromise which avoids having to make a decision on a standard to adhere to.
IMHO symlinking represents the worst of the three options available because now the same thing exists in 2 places and scripts can pick and choose which place they prefer to target, which is kinda messy.
|
Eg: |
For security reasons, it's important that Docker containers run processes as non-root users where possible. After all, processes in a Docker container are just regular Linux processes, and we wouldn't run Pelias processes as the root user outside of Docker. This PR adds a `pelias` user, which is available for running processes later. Because images built with this baseimage may need to install additional dependencies, we can't run the `USER pelias` Docker command here, so each of our services/importers needs to do that. That means this PR should effectively be a no-op until individual services and importers opt-in to using a non-root user.
orangejulius
force-pushed
the
pelias-user
branch
from
07ffbe3 to
e4f372a
Compare
|
After thinking about it more, you're totally right, symlinks add complexity (especially around mounting volumes) without solving anything. I also agree that we don't want to give up the convenience of those easy mountable paths I've removed all the symlink stuff and strived to make this diff as small as possible. We can re-evaluate any other changes in separate PRs. Let me know if it still looks good. |
|
👍 |
|
I've tested this with the local Docker setup and it seems to work well. |
This is enabled by the work in pelias/docker-baseimage#2 and lets us ensure the API is run as a non-root user. Additionally the maintainer label is now set in the baseimage as of (pelias/docker-baseimage#8), so it can be removed here.
This is enabled by the work in pelias/docker-baseimage#2 and lets us ensure the API is run as a non-root user. Additionally the maintainer label is now set in the baseimage as of (pelias/docker-baseimage#8), so it can be removed here.
This uses the work in pelias/docker-baseimage#2 to run processes as the `pelias` user. Running as a non-root user is ideal from a security perspective.
This uses the work in pelias/docker-baseimage#2 to run processes as the `pelias` user. Running as a non-root user is ideal from a security perspective.
This uses the work in pelias/docker-baseimage#2 to run processes as the `pelias` user. Running as a non-root user is ideal from a security perspective.
This uses the work in pelias/docker-baseimage#2 to run processes as the `pelias` user. Running as a non-root user is ideal from a security perspective.
This uses the work in pelias/docker-baseimage#2 to run processes as the `pelias` user. Running as a non-root user is ideal from a security perspective.
This uses the work in pelias/docker-baseimage#2 to run processes as the `pelias` user. Running as a non-root user is ideal from a security perspective.
This uses the work in pelias/docker-baseimage#2 to run processes as the `pelias` user. Running as a non-root user is ideal from a security perspective.
This uses the work in pelias/docker-baseimage#2 to run processes as the `pelias` user. Running as a non-root user is ideal from a security perspective.
This uses the work in pelias/docker-baseimage#2 to run processes as the `pelias` user. Running as a non-root user is ideal from a security perspective.
This uses the work in pelias/docker-baseimage#2 to run processes as the `pelias` user. Running as a non-root user is ideal from a security perspective.
This uses the work in pelias/docker-baseimage#2 to run processes as the `pelias` user. Running as a non-root user is ideal from a security perspective.
By default, all Pelias images now have a user called `pelias` with UID 1000. However, running as a different UID may be best for different people. By setting the default in `.env` and using it in `docker-compose.yml`, we can allow people running Pelias to use whatever non-root user is best for them. Connects pelias/docker-baseimage#2
By default, all Pelias images now have a user called `pelias` with UID 1000. However, running as a different UID may be best for different people. By setting the default in `.env` and using it in `docker-compose.yml`, we can allow people running Pelias to use whatever non-root user is best for them. Connects pelias/docker-baseimage#2
By default, all Pelias images now have a user called `pelias` with UID 1000. However, running as a different UID may be best for different people. By setting the default in `.env` and using it in `docker-compose.yml`, we can allow people running Pelias to use whatever non-root user is best for them. Connects pelias/docker-baseimage#2 Connects pelias/pelias#745
By default, all Pelias images now have a user called `pelias` with UID 1000. However, running as a different UID may be best for different people. By setting the default in `.env` and using it in `docker-compose.yml`, we can allow people running Pelias to use whatever non-root user is best for them. Connects pelias/docker-baseimage#2 Connects pelias/pelias#745
This uses the work in pelias/docker-baseimage#2 to run processes as the `pelias` user. Running as a non-root user is ideal from a security perspective.
By default, all Pelias images now have a user called `pelias` with UID 1000. However, running as a different UID may be best for different people. By setting the default in `.env` and using it in `docker-compose.yml`, we can allow people running Pelias to use whatever non-root user is best for them. Connects pelias/docker-baseimage#2 Connects pelias/pelias#745
For security reasons, it's important that Docker containers run processes as non-root users where possible. After all, processes in a Docker container are just regular Linux processes, and we wouldn't run Pelias processes as the root user outside of Docker.
This PR adds a
peliasuser, which is available for running processes later.Because images built with this baseimage may need to install additional dependencies, we can't run the
USER peliasDocker command here, so each of our services/importers needs to do that.That means this PR should effectively be a no-op until individual services and importers opt-in to using a non-root user.