I am working on documenting this whole install and will add this to it.
This appears to work, not sure it is best practices.
Yea that would work! Couple of small tips/thoughts:
- Instead of
770, I would recommend
440- which means “user and group can read, everyone else can’t do anything”. This is a bit more secure than
770which means “user and group can write, everyone else can’t do anything”. Not a huge difference in practice, probably, but it just means that if an attacker “broke into” the Docker container, they would only be able to read the key (which IS bad), but they wouldn’t be able to modify it (which maybe would be worse). It’s also possible to make the volume itself read-only in your
docker-compose.ymlfile, which would achieve the same thing. This can be done by adding
:roto the end of the volume definition (eg:
- Be sure to mount that directory as a volume! If the keys get recreated from one container to the next, then it would break all existing OAuth2 tokens (I believe).
- You can also run
chmodon the directory outside of the container - doesn’t need to be done inside. This brings up a subtle but important consideration, though. On Linux user/group names are just shortcuts that point to numeric user/group ID. It it a widely used standard convention on most Linux flavors that
www-dataalways corresponds to an ID of
33(both user/group). Although it might not be safe to assume that all the time! So eg: if you run
chown www-data:www-dataoutside of the Docker container, and your host system uses a different ID for whatever reason, then it will NOT have an owner/group of
www-datainside the container. This is probably enough of an edge case that we don’t need to worry about it though. (I do wonder how it would behave on Windows though…)