You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, Nomad provides the ability to create dynamic environment variables using the template stanza. Due to the usage of the heredoc syntax, this makes the nomad file much more difficult to read and understand because the environment variables are not only set in two different places, but with completely different syntax.
It would be nice if the env stanza could be used for this purpose instead, improving readability, and consolidating all environment variable setup into a single stanza.
Use-cases
Inject Vault secrets into nomad jobs via the env stanza
The text was updated successfully, but these errors were encountered:
Hi @Arsen6331! I definitely agree we could do some interesting things with Vault secrets here.
There's a couple of architectural reasons we're not doing this today:
We'd likely end up needing to implement a subset of the consul-template template language in the jobspec, because a Vault API call doesn't necessarily map 1:1 to a string that's safe to use as an environment variable.
We embed consul-template to do all the template rendering and that's what currently owns the Vault API client here. We'd have to set up our own for each allocation with the appropriate derived token. We'd also have to reimplement all the logic for determining restarts when a value in Vault changes.
Keeping the env values (non-secret values) separate from secrets written to the environment has a few advantages in terms of safety as well. But this is probably worth further discussion, and I'll mark this issue as such.
(Note: this has some similarities to #7978 as well)
Proposal
Currently, Nomad provides the ability to create dynamic environment variables using the
template
stanza. Due to the usage of the heredoc syntax, this makes the nomad file much more difficult to read and understand because the environment variables are not only set in two different places, but with completely different syntax.It would be nice if the
env
stanza could be used for this purpose instead, improving readability, and consolidating all environment variable setup into a single stanza.Use-cases
env
stanzaThe text was updated successfully, but these errors were encountered: