Every Vault operation performed through the command-line interface (CLI), API, or web UI require that the authenticated client is granted access; access defined through policies. Everything in Vault is stored at different paths, like a filesystem, and every action in Vault has a corresponding path and capability. Policies provide a declarative way to grant or forbid access to paths and the capabilites at each path.
In this tutorial, you will learn Vault's policy language and how to query an audit log to define policies.
»Prerequisites
»Start Vault
Start a Vault dev server with root
as the root token.
The Vault dev server defaults to running at 127.0.0.1:8200
. The server is
initialized and unsealed.
Insecure operation: Do not run a Vault dev server in production. This approach starts a Vault server with an in-memory database and runs in an insecure way.
In another terminal, export an environment variable for the vault
CLI to
address the Vault server.
Export an environment variable for the vault
CLI to authenticate with the
Vault server.
The Vault server is ready.
»Enable audit logs
Audit devices keep a detailed log of all requests and response to Vault. The file audit device appends these events to a file.
Enable the file audit device at a file named vault_audit.log
in the current
directory.
The file audit device is enabled and immediately appends a test message to the audit log file.
Display the contents of the audit log file.
The output displays two entries similar to these ones.
The audit log appends JSON objects to the log file. The first object describes an audit test message. The second object describes the operation that enabled the audit log.
»Enable transit secrets engine
The transit secrets engine handles cryptographic functions on data in-transit through keys that Vault manages.
Enable the transit secrets engine at the default path.
The transit secrets engine is enabled and the operation that performed it was written to the audit log.
View only the last entry in the audit log file.
The output displays an entry similar to this one.
The object describes the time, the authorized token, the request, and the response.
Display the request
of the last logged object.
The output displays an entry similar to this one.
The request describes the operation that was performed on the path.
Display the request's path
and the request's operation
.
The output displays that this operation performed an update
on the path
sys/mounts/transit
.
Define a policy that grants the capability to update
at path
sys/mounts/transit
.
To learn more about querying the Audit Log, read the Querying Audit Device Logs tutorial.
»Create an encryption key
Create a encryption key named user-data
.
Display the request path
and the request operation
of the last logged
object.
»Challenge
Define a policy that grants the capability to update
at path
transit/keys/user-data
.
»Encrypt plaintext with the key
The user-data
key is capable of encrypting base64 encoded plaintext and
returns the ciphertext.
Encrypt user sensitive data with the user-data
key.
Display the request path
and the request operation
of the last logged
object.
»Challenge
Define a policy that grants the capability to update
at path
transit/encrypt/user-data
.
»Decrypt ciphertext with the key
The same key is used to decrypt the ciphertext and return the base64 encoded plaintext.
Create a variable named USER_SECRET_DATA
that stores the cipher text
generated.
Decrypt the user sensitive data with the user-data
key.
Display the request path
and the request operation
of the last logged
object.
Define a policy that grants the capability to update
at path
transit/decrypt/user-data
.
»Next steps
In this tutorial, you performed an operation and then queried Vault's audit logs to discover the path and action. Learn more about querying the Audit Log, read the Querying Audit Device Logs tutorial.
To define policies requires understanding the paths and capabilities of each authentication method and secrets engine. Learn additional approaches in the Write a Policy from API documentation tutorial.