The first step to using the vault backend is to mount it.
Unlike the generic backend, the nomad backend is not mounted by default.
$vault secrets enable nomadSuccessfully mounted 'nomad' at 'nomad'!
$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=3600max_ttl=86400Success! Data written to: nomad/config/lease
$vault write nomad/config/lease ttl=3600max_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
$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
$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
$vault write nomad/role/monitoring policies=readonlySuccess! Data written to: nomad/role/monitoring
The backend 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:
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
$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
