Support running of services as application users

[lfrancke]

Currently all our managed processes (e.g. ZooKeeper) are started as root.
We'd like to support also running all our services as non-root.

We'd like to let the user choose the username the services should run as.
So the CRDs need to be extended (but that's for operator specific issues).

We will follow what the systemk does which means that the Agent will need to look in each Pod for the desired username.

This is the field where the name can be found: pod.securityContext.windowsOptions.runAsUserName
Note: There is also a pod.securityContext.runAsUser field but that only takes an integer which is not enough for us.

• The agent needs to be extended to read the aforementioned property
• The username then needs to be propagated to the systemd unit
• Optional/Bonus: If the user does not exist it can be created automatically
  • If this is implemented it should be an optional feature, the Agent should have a configuration option disabling auto-creation of users
• When the agent creates directories for the services (via Volumes) they need to be owned by the same user
  • This might also be made configurable later but that's for another issue

Note: This is not about running the Agent itself as non-root!

[siegfriedweber]

Open questions:

1. Would a systemd dynamic user also be okay? If yes then the following questions about static users would disappear. Systemd automatically assigns the correct ownership to its directories (see https://www.freedesktop.org/software/systemd/man/systemd.exec.html#RuntimeDirectory=). It is possible to preserve the runtime directory (see https://www.freedesktop.org/software/systemd/man/systemd.exec.html#RuntimeDirectoryPreserve=). It is also a good thing that some of the directories are removed when the unit is stopped because each time the pod is created, a new service UID is generated and new directories are created.

2. Should static users really be created by the agent? This is an additional security risk. Another problem is that the UID will be random which makes the backup and restore process unreliable. Other systems define well-known IDs to tackle this problem (see https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/misc/ids.nix). The user would be assigned to the default group because no GID is given.

3. Is windowsOptions.runAsUserName really desired? A well-known UID and GID would be more reliable. The Kubernetes API is also designed for IDs on Linux. There is also no runAsGroupName.

4. Which directories should be owned by the service user?

• config -> This directory belongs to the service. It does not contain secrets. The service must be able to read it but it is not necessary to own it. The ConfigurationDirectory in systemd is not owned by the service.
• log -> This directory belongs to the service. The question is if it is really used.
• package/parcel -> This directory belongs to the agent and must be owned by them.
• service -> This directory belongs to the agent but is currently unused.

5. Should the agent create the log directory with the correct ownership?