»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.
The first step to using the Vault secrets engine is to enable it.
$ vault secrets enable nomad Successfully mounted 'nomad' at 'nomad'!
Optionally, we can configure the lease settings for credentials generated
by Vault. This is done by writing to the
$ vault write nomad/config/lease ttl=3600 max_ttl=86400 Success! 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 bootstrap Accessor ID = 95a0ee55-eaa6-2c0a-a900-ed94c156754e Secret ID = c25b6ca0-ea4e-000f-807a-fd03fcab6e3c Name = Bootstrap Token Type = management Global = true Policies = n/a Create Time = 2017-09-20 19:40:36.527512364 +0000 UTC Create Index = 7 Modify 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-5b6758e4159e Success! 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=readonly Success! 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/monitoring Key Value --- ----- lease_id nomad/creds/monitoring/78ec3ef3-c806-1022-4aa8-1dbae39c760c lease_duration 768h0m0s lease_renewable true accessor_id a715994d-f5fd-1194-73df-ae9dad616307 secret_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-ae9dad616307 Accessor ID = a715994d-f5fd-1194-73df-ae9dad616307 Secret ID = b31fb56c-0936-5428-8c5f-ed010431aba9 Name = Vault example root 1505945527022465593 Type = client Global = false Policies = [readonly] Create Time = 2017-09-20 22:12:07.023455379 +0000 UTC Create Index = 138 Modify Index = 138
Refer to Generate Nomad Tokens with HashiCorp Vault for a step-by-step tutorial.
The Nomad secrets engine has a full HTTP API. Please see the Nomad Secrets Engine API for more details.