Authorization to use Jobs API within running Nomad task

Nomad
1

Typically, devs and operators set the NOMAD_TOKEN environment variable to a newly-minted token retrieved via Vault in the correct role with the correct policies, etc.

Let’s say that I want to be able to use the Jobs API from a long-running task (e.g. a service workload expected to live beyond the Nomad token TTL). Should the job itself be able to mint new Nomad tokens using Vault? Or is there a better approach here I’m missing.

2

Hi @hntrmrrs! For this use case, you’ll probably want to use a template block to mint a Nomad token specific to the application inside the task. That way the token can be renewed by the template runner and your application will get updated with the new token with whatever you set as the change_mode.

(You might want to issue your application its mTLS certs this way as well.)

3

Hi @tgross thanks for the quick reply!

So if I understand correctly, the template will automatically use the Vault Renewer API to re-render the template at some point prior to the end of the secret TTL?

Thanks for the suggestion re: mTLS. We currently handle those renewals entirely outside of Nomad, but this approach is much simpler with easier-to-understand failure modes.

Thanks again!

4

So if I understand correctly, the template will automatically use the Vault Renewer API to re-render the template at some point prior to the end of the secret TTL?

Yup! IIRC it’ll try to do that at the halfway point of the TTL to give you some breathing room.

Also note that if you restart the Nomad client agent and there are templates with dynamic secrets, those will always kick off the change_mode signal once the client comes back up even if the TTL isn’t ready to expire. (Because Nomad can’t correctly handle the TTL once the client process goes offline, so we err on the side of caution rather than letting it just randomly expire later.)