Can nomad write to a consul key/val?

Nomad
1

So nomad can read consul key/vals in project hcl files during nomad plan/validate/run.

( eg: template stanzas fetching {{ key "service-name/key-name" }} )

can nomad write/update consul key/vals?

For context, I’m wondering for situations where I am not in the nomad + consul cluster, and have NOMAD_ADDR and NOMAD_TOKEN (and can thus speak to the cluster w/ nomad – but don’t have any similar CONSUL variables (and let’s assume that I can’t for purposes of this question :slight_smile: )

Thanks for any help!

1 Like
2

Hi @traceypooh,

The Nomad template stanza uses the consul-template library for performing these actions and unfortunately it does not seem writing to Consul KV is supported. I would suggest raising the feature request against that repository so the owner team can provide better feedback on the request.

Thanks,
jrasell and the Nomad team

3

thanks @jrasell !

I wound up solving my particular issue (using consul instead of vault for secrets) via the following, FWIW:

  • during out customized GitLab [deploy] phase, inspect CI/CD env vars and filter to just those starting with NOMAD_SECRET_ (they’re all nicely protected and masked in GitLab) – and push them into a JSON-like hashmap string into an .env file
  • send that env file as cmd-line arg to nomad validate/plan/run
  • in (generic) project.nomad file we use for our deployments, if NOMAD_SECRETS env var hashmap is set, add a 2nd task as lifecycle sidecar/prestart, that uses exec driver and runs /usr/bin/consul kv put ... hashmap string for that project’s deploy
  • main task in job spec simply then uses consul like normal to get the secrets and stuff them into a secrets/kv.env file, with env = true
  • keys/tokens are now available as environment variables in the main task

easy, right? (hehe)

I modeled it after the GitLab + Kubernetes integration, carefully noting the exposure/risk was no worse than what they were up to.

Now we don’t have to sort out dual auto-unsealing vault clusters for our secrets for our entirely on-prem clusters :smile:

3 Likes