Improve documentation for first time users #187
Conversation
|
|
sseide
changed the title
| @@ -59,6 +59,8 @@ services: | |||
| !!! danger "" | |||
| Set strong passwords if the database is exposed to an external network. Never expose your database to the public Internet in this way, for example, if it is running on a cloud server. | |||
|
|
|||
| For increased security do not allow the "photoprism" user to access the database from every host (`'photoprism'@'%'`) but restrict it to the hosts photoprism is accessing the database from (e.g. `'photoprism'@'192.168.1.2'` or `'photoprism'@'192.168.1.%'` for entire subnet). | |||
There was a problem hiding this comment.
Removing ports would be better? It would limit access to the Docker network.
There was a problem hiding this comment.
Your hint implies running mysql with docker-compose in the same setup.
My suggestion is much more generic and preferred for all kind of database setups (not only Photoprism).
And you would not believe how much people i talked to do not even thought it is easily possible to restrict access in this way. So document it here might people start thinking about it...
Running MariaDB inside docker is (performance wise) the lease favored (aka slowest) variant. It is much better to use a common db host on real iron with some bit of tuning to get much faster SQL responses. And it is easier to maintain/backup/monitor than a dozen different DB container. For these setup restricting "ports " will not help.
And we do not talk about failover cluster or similar here... Or you can use a DBaaS from some places if you host the app somewhere else. Restricting access to defined IP addresses is also helpful not using docker at all but running Photoprism as "native" app.
Alternative: Running it in the same compose setup or running DB directly on the docker host a setup sharing Unix domain sockets (e.g. /var/run/mysql/mysqld.socket) would be much better than ports restriction to prevent foreign logins.
There was a problem hiding this comment.
Your hint implies running mysql with docker-compose in the same setup.
Yes a docker-compose setup is shown on the lines before this change.
About using or not using Docker, that may go in a different section since right now it only describes the common installation with a container for the database.
If ports are removed, the access from the host or external network won't work anymore, but Photoprism will work without any issue since it's on the same Docker network.
There was a problem hiding this comment.
Yes - the code snipped above shows the docker-compose-all-in-one setup. But this is also the exact place to configure the database connection properties using Photoprism only as docker image and with some external database.
And most of the other information are valid for combined compose setup as well as an divided setup.
Here its up to you if you want one file with database hints or different one for compose and others or just create different sections... I don't hang to, just realized its good to give people different hints on how to secure their setups. Some do, some do not...
And your remark about the port is good - this should be added to the compose file - either as active by default or uncommented and some comments added , similar to many other parameter and env vars within this compose file you can download for fast setup. And mentioned in the database readme here.
| @@ -48,6 +48,9 @@ docker compose stop | |||
| docker compose up -d | |||
| ``` | |||
|
|
|||
| Please keep in mind that the _numeric_ user and group ids are shared between the local docker host and the docker container (user/group _names_ are not). That means the user running inside the container can read and write all files on the host with the same user id as photoprism is running at. The container runtime tries restricts the available paths but as soon as a security vulnerability circumvents this docker imposed restrictions full access to the entire host with this user id is possible. Threfore nover run as root or with a low user id of regular users of the docker host. | |||
There was a problem hiding this comment.
Could you please share an example of this security vulnerability?
There was a problem hiding this comment.
A good writeup to test/understand this user feature can be found here:
https://medium.com/@mccode/understanding-how-uid-and-gid-work-in-docker-containers-c37a01d01cf
A way to "use" this (and get root) is written here:
https://flast101.github.io/docker-privesc/
Even as the examples above use root / UID 0. it is the same for docker running with all user ids - the process inside the container can potentially access all files outside available to the same user id. Using (for example) UID 1000 or 1001 will give potential access to the files of the primary Linux user (as most Linux distributions start numbering with 1000 for regular users).
Using a high user id not used anywhere else on the docker host is a forward-looking security technique to not get owned if there is a security vulnerability found inside the Linux kernel or Docker daemon or some other software running inside the container. And all Docker security best practices mention a privilege escalation attack as possible scenario to take care of.
There is no real attack right now but you never now - better safe than sorrow..
e.g.
- https://www.oreilly.com/content/five-security-concerns-when-using-docker/
- https://snyk.io/de/blog/10-docker-image-security-best-practices/ -> 2. use least privileges and it is part of the Synk Docker image security checks
- https://docs.docker.com/engine/security/userns-remap/#enable-userns-remap-on-the-daemon -> prevent problem with user namespace remap
- https://www.tigera.io/learn/guides/container-security-best-practices/docker-security/
...
There was a problem hiding this comment.
just a note: restricting the UID to some specific values prevents Photoprism from running inside OpenShift Clusters as OpenShift automatically assigns a high random user id to every container started. I have not tested it right now but would assume its not working there...
https://www.redhat.com/en/blog/a-guide-to-openshift-and-uids
|
btw. if you do want to merge some parts only or want to improve it yourself in another way - feel free to cherry pick some commits or (after my holiday) i can prepare a new PR with only parts of it... |
add some points to clarify some points around OpenID Connect configuration and users management.
Added some more points to the already very good security configuration to further improve it with additional hints