Nomad secrets engine

Note: This engine can use external X.509 certificates as part of TLS or signature validation. Verifying signatures against X.509 certificates that use SHA-1 is deprecated and is no longer usable without a workaround starting in Vault 1.12. See the deprecation FAQ for more information.

Nomad is a simple, flexible scheduler and workload orchestrator. The Nomad secrets engine for Vault generates Nomad ACL tokens dynamically based on pre-existing Nomad ACL policies.

This page will show a quick start for this secrets engine. For detailed documentation on every path, use vault path-help after mounting the secrets engine.

Version information ACLs are only available on Nomad 0.7.0 and above.

Quick start

The first step to using the Vault secrets engine is to enable it.

$ vault secrets enable nomadSuccessfully mounted 'nomad' at 'nomad'!

Optionally, we can configure the lease settings for credentials generated by Vault. This is done by writing to the config/lease key:

$ vault write nomad/config/lease ttl=3600 max_ttl=86400Success! Data written to: nomad/config/lease

For a quick start, you can use the SecretID token provided by the Nomad ACL bootstrap process, although this is discouraged for production deployments.

$ nomad acl bootstrapAccessor ID  = 95a0ee55-eaa6-2c0a-a900-ed94c156754eSecret ID    = c25b6ca0-ea4e-000f-807a-fd03fcab6e3cName         = Bootstrap TokenType         = managementGlobal       = truePolicies     = n/aCreate Time  = 2017-09-20 19:40:36.527512364 +0000 UTCCreate Index = 7Modify Index = 7

The suggested pattern is to generate a token specifically for Vault, following the Nomad ACL guide

Next, we must configure Vault to know how to contact Nomad. This is done by writing the access information:

$ vault write nomad/config/access \    address=http://127.0.0.1:4646 \    token=adf4238a-882b-9ddc-4a9d-5b6758e4159eSuccess! Data written to: nomad/config/access

In this case, we've configured Vault to connect to Nomad on the default port with the loopback address. We've also provided an ACL token to use with the token parameter. Vault must have a management type token so that it can create and revoke ACL tokens.

The next step is to configure a role. A role is a logical name that maps to a set of policy names used to generate those credentials. For example, let's create a "monitoring" role that maps to a "readonly" policy:

$ vault write nomad/role/monitoring policies=readonlySuccess! Data written to: nomad/role/monitoring

The secrets engine expects either a single or a comma separated list of policy names.

To generate a new Nomad ACL token, we simply read from that role:

$ vault read nomad/creds/monitoringKey              Value---              -----lease_id         nomad/creds/monitoring/78ec3ef3-c806-1022-4aa8-1dbae39c760clease_duration   768h0m0slease_renewable  trueaccessor_id      a715994d-f5fd-1194-73df-ae9dad616307secret_id        b31fb56c-0936-5428-8c5f-ed010431aba9

Here we can see that Vault has generated a new Nomad ACL token for us. We can test this token out, by reading it in Nomad (by it's accessor):

$ nomad acl token info a715994d-f5fd-1194-73df-ae9dad616307Accessor ID  = a715994d-f5fd-1194-73df-ae9dad616307Secret ID    = b31fb56c-0936-5428-8c5f-ed010431aba9Name         = Vault example root 1505945527022465593Type         = clientGlobal       = falsePolicies     = [readonly]Create Time  = 2017-09-20 22:12:07.023455379 +0000 UTCCreate Index = 138Modify Index = 138

Tutorial

Refer to Generate Nomad Tokens with HashiCorp Vault for a step-by-step tutorial.

API

The Nomad secrets engine has a full HTTP API. Please see the Nomad Secrets Engine API for more details.