[feature]: Enable specifying user/group permissions in the template stanza

[danlsgiga]

It would be great to have user and group parameters to the template stanza. This would allow us to trim down the perms of templates handling secrets to just the user/group of the user running in the container.

Use case: We have few jobs running the docker driver and we are injecting a few config files using the template stanza with secrets from Vault. Right now we have to set perms = 444 in order to allow the task to read the rendered template. From a security standpoint, this is not optimal since 444 allows anyone to read the file. So, being able to specify an user/group combination in the template stanza would make things simpler since Nomad always create the templates with user and group = root.

Having to do manual steps on a docker entrypoint script to achieve that is ugly IMO.

This is related to #2091

[preetapan]

@danlsgiga could you not set perms=400 to restrict it to just the owner?

[danlsgiga]

@preetapan not really! The template is created with user / group set to root and I run my container using nobody / nobody (best practices heh!). Setting perms = 400 (Tried that and didn't work) will make the file readable by root only.

[ccakes]

Another use case here is certain software (eg PostgreSQL) enforces certain permissions for files like TLS keys and being able to get things working under Nomad can be problematic.

Using the docker executor template files are written as root but in the container we don't know what user we're running as, although it probably shouldn't be root. Postgres enforces that key files are 0400 (or 0640) if owned by root so I've had to build a new image with postgres in the root group in make things work.

Adding simple options to set file ownership to uids would solve this

[peimanja]

Any update on this issue?

[tgross]

Hi @peimanja. Sorry we don't have an update on this. I've made sure to put it onto our backlog for discussion though.

[AbhilashBalaji]

Hey , I would like to work on this issue , could someone give me any idea on where to start from ?

[AbhilashBalaji]

Would adding extra checks here make a feasible solution

[mr-karan]

+1. Trying to deploy gitea and using template stanza to mount the config file. But it gets mounted as a root user. Since gitea is started with a non root user, it's effectively unable to read the file.

[johnalotoski]

Similar use case as above: Nomad postgres job being run in the exec driver as the nobody user, with SSL, pulling PKI certs via consul template from the vault PKI secrets path. All Nomad job files are created as nobody:nobody in the job except for the consul template files which are root:root. Postgres demands perms on the cert secret key file of 0600 (for non-root ownership) or 0640 (for root ownership) which is incompatible with the nobody:nobody user if ownership can't be changed. We can of course copy the secret key and change the ownership by script at the startup of the postgres job, but then when PKI certs expire and are auto-refreshed, the consul template change_mode can't just be SIGHUP, but a more disruptive full job restart to ensure that the scripted change of ownership happens to be able to read the newly rotated private key again.

Maybe there is a way to have the consul template files be written as the nobody:nobody user rather than root:root when the nomad jobs are being run as nobody:nobody?

[MagicRB]

I'm trying to run HydraCI in a Nix built container, but HydraCI requires the pgpass file to be 600 or less, which means I have to change it's owner from root:root

[virtualshuric]

Another case for setting templated files ownership is running RabbitMQ containers as non-root user:

1. RMQ requires, that Erlang cookie has permission of 0600 (or 0400).
2. When running RMQ image as root user, entrypoint script simply chowns cookie-file to non-privileged rabbitmq user.
3. When running RMQ as non-root - it either can't read cookie-file (because of root:root owner and 0600 permissions), either RMQ fails to start because permission set don't match (e.g. when cookie file permissions are 0644).

[keslerm]

Ran into needing this a bunch already and it makes things really troublesome to get going sometimes.

[3nprob]

Support for setting uid and guid just got merged to consul-template, expected for next release: hashicorp/consul-template#1531

So this should be pretty straightforward to implement for nomad as of now

[jrasell]

Hi @3nprob and others. I have raised that internally and any updates will be posted as follow up comments.

[danlsgiga]

And, here it is: https://github.com/hashicorp/consul-template/blob/master/CHANGELOG.md#v0280-mar-04-2022

[3nprob]

@jrasell Got any news for us now that the prerequisites are in place with 1.3? :)

[github-actions]

I'm going to lock this issue because it has been closed for 120 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.