2015-04-14 00:56:59 +00:00
|
|
|
---
|
|
|
|
layout: "docs"
|
2017-03-17 18:37:01 +00:00
|
|
|
page_title: "Generic Secret Backend"
|
2015-04-14 00:56:59 +00:00
|
|
|
sidebar_current: "docs-secrets-generic"
|
|
|
|
description: |-
|
|
|
|
The generic secret backend can store arbitrary secrets.
|
|
|
|
---
|
|
|
|
|
|
|
|
# Generic Secret Backend
|
|
|
|
|
|
|
|
Name: `generic`
|
|
|
|
|
|
|
|
The generic secret backend is used to store arbitrary secrets within
|
|
|
|
the configured physical storage for Vault. If you followed along with
|
|
|
|
the getting started guide, you interacted with a generic secret backend
|
2015-09-21 15:22:48 +00:00
|
|
|
via the `secret/` prefix that Vault mounts by default. You can mount as many
|
|
|
|
of these backends at different mount points as you like.
|
2015-04-14 00:56:59 +00:00
|
|
|
|
2016-01-14 19:18:27 +00:00
|
|
|
Writing to a key in the `generic` backend will replace the old value;
|
2015-09-21 15:22:48 +00:00
|
|
|
sub-fields are not merged together.
|
2015-05-11 17:58:21 +00:00
|
|
|
|
2016-01-07 20:10:05 +00:00
|
|
|
This backend honors the distinction between the `create` and `update`
|
|
|
|
capabilities inside ACL policies.
|
|
|
|
|
2015-10-29 15:21:40 +00:00
|
|
|
**Note**: Path and key names are _not_ obfuscated or encrypted; only the values
|
|
|
|
set on keys are. You should not store sensitive information as part of a
|
|
|
|
secret's path.
|
|
|
|
|
2015-04-14 00:56:59 +00:00
|
|
|
## Quick Start
|
|
|
|
|
2016-06-09 00:14:36 +00:00
|
|
|
The generic backend allows for writing keys with arbitrary values. When data is
|
|
|
|
returned, the `lease_duration` field (in the API JSON) or `refresh_interval`
|
|
|
|
field (on the CLI) gives a hint as to how often a reader should look for a new
|
|
|
|
value. This comes from the value of the `default_lease_ttl` set on the mount,
|
|
|
|
or the system value.
|
|
|
|
|
|
|
|
There is one piece of special data handling: if a `ttl` key is provided, it
|
|
|
|
will be treated as normal data, but on read the backend will attempt to parse
|
|
|
|
it as a duration (either as a string like `1h` or an integer number of seconds
|
|
|
|
like `3600`). If successful, the backend will use this value in place of the
|
|
|
|
normal `lease_duration`. However, the given value will also still be returned
|
|
|
|
exactly as specified, so you are free to use that key in any way that you like
|
|
|
|
if it fits your input data.
|
2015-08-20 23:41:25 +00:00
|
|
|
|
2016-03-18 13:57:21 +00:00
|
|
|
As an example, we can write a new key "foo" to the generic backend mounted at
|
|
|
|
"secret/" by default:
|
2015-04-27 02:14:41 +00:00
|
|
|
|
|
|
|
```
|
2015-10-12 16:10:22 +00:00
|
|
|
$ vault write secret/foo \
|
|
|
|
zip=zap \
|
|
|
|
ttl=1h
|
2015-04-27 02:14:41 +00:00
|
|
|
Success! Data written to: secret/foo
|
|
|
|
```
|
|
|
|
|
2015-09-21 15:22:48 +00:00
|
|
|
This writes the key with the "zip" field set to "zap" and a one hour TTL.
|
|
|
|
We can test this by doing a read:
|
2015-04-27 02:14:41 +00:00
|
|
|
|
|
|
|
```
|
|
|
|
$ vault read secret/foo
|
2016-06-09 00:14:36 +00:00
|
|
|
Key Value
|
|
|
|
--- -----
|
|
|
|
refresh_interval 3600
|
|
|
|
ttl 1h
|
|
|
|
zip zap
|
2015-04-27 02:14:41 +00:00
|
|
|
```
|
|
|
|
|
2016-06-09 00:14:36 +00:00
|
|
|
As expected, we get the values previously set back as well as our custom TTL
|
2016-03-18 13:57:21 +00:00
|
|
|
both as specified and translated to seconds. The duration has been set to 3600
|
2015-09-21 15:22:48 +00:00
|
|
|
seconds (one hour) as specified.
|
|
|
|
|
|
|
|
## API
|
|
|
|
|
2017-03-09 02:47:35 +00:00
|
|
|
The Generic secret backend has a full HTTP API. Please see the
|
2017-03-17 18:06:03 +00:00
|
|
|
[Generic secret backend API](/api/secret/generic/index.html) for more
|
2017-03-09 02:47:35 +00:00
|
|
|
details.
|