I wish the default UID/GID was configurable. All my existing data is owned by 1000/1000 which is the user on my self-built NAS/docker server. I replicate the data back and forth. So I run the apps that are going to need access to the data with that UID/GID combo.
And because I'm lazy, I leave the ones that don't need access to that data as 568.
Currently iX is reworking the code behind the "big blue button" for docker containers, previously that button and the Apps used 2 seperate codepaths, which made it hard to maintain, next version this would be one codepath for both. I'm pretty sure adding (pod)SecurityContext (to set UID and GID on native k8s) is on the agenda afterwards.
If those changes are merged it's about 5 hours of work to copy pasta from TrueCharts and thoroughly test.
But it would be silly to implement it during a refactor ;-)
Well, linuxserver.io has multiple docker containers ready with easy config path folders, UID/GID as 1000, etc. Also if you can't find an image there you can build your own starting with one you found there.
Please, try to evade linuxserver.io containers on k8s like the plague.
They are nice for home use or docker-compose, but they f'ed up terribly because they can't support native k8s methods of setting user, groups and permissions.
Let me explain why this is such a big issue:
1. k8s permissions, never booted a container as root. The whole pod is started as a limited user (which is more secure)
2. k8s permissions allow for multiple groups to be set for a user
3. k8s permissions autmatically handle the permissions for your PVC storage out-of-the-box, which does not have to be the same group that runs the container either (super neat)
4. If you want access to attached devices, k8s allows you to use those additional groups to give a container-user just access to those devicegroups. LSIO needs to be started as root and demands to handle it themselves.
5. All those steps to handle things themselves, create a needlessly complicated container (aka bloat)
For most containers I can advice to use the k8s-at-home container variants, which are build with k8s in mind. (which we also use for TrueCharts :) )
Why is the above rant relevant?
Using security context, one would have a number of options to handle this:
1. Set your own uid and gid as the one running the application instead of 568
2. Add your own GID as additional group to just grant access
3. Set your own GID as storage group
---
To be clear
@bodly 568 is
NOT the default user running your applications!
It's just an added blank-slate users appbuilders and users
CAN use for their applications!
So changing it's id, does nothing. because it isn't used by default. It's just a convenience number/name combo.
k8s doesn't work with usersnames anyway, it uses the UID and GID. So the default user is just for optics and convenience if someone want to use it, if you don't want to it isn't used*
*note: We at TrueCharts default to 568 which shows as the apps user. However: we (or rather: k8s) don't actually use it, it just creates a nice name for that number.