Vault
Set up the key/value v2 plugin
Use vault secrets enable
to enable an instance of the kv
plugin. To specify
version 2, use the -version
flag or specific kv-v2
as the plugin type:
Additionally, when running a dev-mode server, the v2 kv
secrets engine is enabled by default at the
path demo/
(for non-dev servers, it is currently v1). It can be disabled, moved, or enabled multiple times at
different paths. Each instance of the KV secrets engine is isolated and unique.
Before you start
- You must have permission to update ACL policies.
- You must have permission to enable plugins.
Step 1: Enable the plugin
Use vault secrets enable
to establish a new instance of the kv
plugin.
To specify key/value version 2, use the -version
flag or use kv-v2
as the
plugin type.
Option 1: Use the -version
flag:
$ vault secrets enable -path <mount_path> -version=2 kv
Option 2: Use the kv-v2
plugin type:
$ vault secrets enable -path <mount_path> kv-v2
Step 2: Create an ACL policy file
Note
ACL policies for kv
plugins do not support the allowed_parameters
,
denied_parameters
, and required_parameters
policy fields.
Create a policy definition file based on your needs.
For example, assume there are API keys stored on the path /dev/square-api
for
a kv
plugin mounted at shared/
. The following policy lets clients read and
patch the latest version of API keys and read metadata for any version of the
API keys:
# Grants permission to read and patch the latest version of API keys
path "shared/data/dev/square-api/*" {
capabilities = ["read", "patch"]
}
# Grants permission to read metadata for any version of the API keys
path "shared/metadata/dev/square-api/" {
capabilities = ["read"]
}
Path prefix | Policy effect |
---|---|
data | Permissions apply to the latest version of the data. |
undelete | Clients can use un-delete commands and endpoints on any version of the data. |
destroy | Clients can use destroy commands and endpoints on any version of the data. |
metadata | Clients can use metadata commands and endpoints on any version of the data. |
Step 3: Save the ACL policy
Use vault policy write
to create a new ACL policy with the policy definition
file:
$ vault policy write <name> <path_to_policy_file>
For example:
$ vault policy write "KV access policy" ./kv-policy.hcl