Inject default user/group for Docker by Nomad client

Hello, I’m trying to solve the following problem. Configuration:

  • A pipeline produces 2 artifacts: docker image and nomad job definition for it. Both are immutable, versioned and stored on artifact repo. There are reasons for such setup, but basically job definition should stay immutable.
  • Both artifacts are promoted through environments, each running under different users.

Problem: I’d like to ensure that whichever environment the job is running in, that user will be the user who starts the process inside the container.

First I looked at templating the user, but template stanza works only inside task stanza, while container user is defined in job stanza.
Then I checked Docker plugin configuration on nomad client, but it doesn’t have an option to use default user either, thus USER statement from image is applied (or root if none)
The user from the image doesn’t have privileges that nomad user does.

This is definitely possible from Docker API perspective because docker-compose does exactly that (actually, it’s even better because it can use UID/GID only and unlike Nomad, doesn’t require the account to be pre-created inside the image)
Furthermore, docker-compose v2 has “group_add” statement, which would be really useful in Nomad as well…

Is there any other way to achieve that apart from tinkering with entrypoints, sudoers and other impractical workarounds?

Hi @RomanTheLegend! Setting the user isn’t in the Docker config block because it’s provided at the task level.

Try setting the task user in the job specification. We don’t currently support adding a group, but we do have an open PR from the community for it #8066 which unfortunately is tied up in CLA signing legalities.

Not exactly what I was asking, I’m more interested in scenario where username could be either templated from Consul’s KV or that I can preset default value inside Nomad Agent’s configs.

Looks like there’s no such possibility as of yet

Hm… you could most likely use HCL2’s variables and pass them in as a NOMAD_VAR_foo environment variable from wherever you’re submitting the jobs (i.e. your CI/CD system).

1 Like