# Can nomad write to a consul key/val?

**URL:** <https://discuss.hashicorp.com/t/can-nomad-write-to-a-consul-key-val/21709>\
**Category:** Nomad\
**Created:** [March 4, 2021, 10:18pm UTC](https://discuss.hashicorp.com/t/can-nomad-write-to-a-consul-key-val/21709 "2021-03-04T22:18:12Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![traceypooh](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/traceypooh/32/8686_2.png) [@traceypooh](https://discuss.hashicorp.com/u/traceypooh)\
**Post date:** [March 4, 2021, 10:18pm UTC](https://discuss.hashicorp.com/t/can-nomad-write-to-a-consul-key-val/21709/1 "2021-03-04T22:18:12Z")

</div>

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 🙂 )

Thanks for any help!

---

<div class="post-metadata">

**Author:** ![jrasell](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/jrasell/32/5500_2.png) [@jrasell](https://discuss.hashicorp.com/u/jrasell)\
**Post date:** [March 5, 2021, 7:45am UTC](https://discuss.hashicorp.com/t/can-nomad-write-to-a-consul-key-val/21709/2 "2021-03-05T07:45:37Z")

</div>

Hi @traceypooh,

The Nomad template stanza uses the [consul-template](https://github.com/hashicorp/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

---

<div class="post-metadata">

**Author:** ![traceypooh](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/traceypooh/32/8686_2.png) [@traceypooh](https://discuss.hashicorp.com/u/traceypooh)\
**Post date:** [June 15, 2021, 11:35pm UTC](https://discuss.hashicorp.com/t/can-nomad-write-to-a-consul-key-val/21709/3 "2021-06-15T23:35:33Z")

</div>

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 😄