Events
Beta feature
Beta functionality is stable but possibly incomplete and subject to change. We strongly discourage using beta features in production deployments of Vault
Events are arbitrary, non-secret data that can be exchanged between producers (Vault and plugins) and subscribers (Vault components and external users via the API).
Event types
Internal components of Vault as well as external plugins can generate events.
These are published to "event types", sometimes called "topics" in some event systems.
All events of a specific event type will have the same format for their
additional metadata
field.
The following events are currently generated by Vault and its builtin plugins automatically:
Plugin | Event Type | Metadata | Vault version |
---|---|---|---|
kv | kv-v1/delete | modified , operation , path | 1.13 |
kv | kv-v1/write | data_path , modified , operation , path | 1.13 |
kv | kv-v2/config-write | data_path , modified , operation , path | 1.13 |
kv | kv-v2/data-delete | modified , operation , path | 1.13 |
kv | kv-v2/data-patch | data_path , modified , operation , path | 1.13 |
kv | kv-v2/data-write | data_path , modified , operation , path | 1.13 |
kv | kv-v2/delete | modified , operation , path | 1.13 |
kv | kv-v2/destroy | modified , operation , path | 1.13 |
kv | kv-v2/metadata-delete | modified , operation , path | 1.13 |
kv | kv-v2/metadata-patch | data_path , modified , operation , path | 1.13 |
kv | kv-v2/metadata-write | data_path , modified , operation , path | 1.13 |
kv | kv-v2/undelete | data_path , modified , operation , path | 1.13 |
Event format
Events may be formatted in protobuf binary format or as JSON.
See EventReceived
in sdk/logical/event.proto
in the relevant Vault version for the protobuf schema.
When formatted as JSON, the event conforms to the CloudEvents specification.
id
(string)
- CloudEvents unique identifier for the event. Theid
is unique for each event, and events with the sameid
represent the same event.source
(string)
- CloudEvents source, which is currentlyhttps://vaultproject.io
.specversion
(string)
- The CloudEvents specification version this conforms to.type
(string)
- CloudEvents type this event corresponds to, which is currently always*
.datacontenttype
(string)
- CloudEvents content type of the event, which is currently alwaysapplication/json
.time
(string)
- ISO 8601-formatted timestamp for when the event was generated.data
(object)
- Vault-specific data.event
(Event)
- contains the event that happened.event_type
(string)
- the event type that was published.plugin_info
(PluginInfo)
- information about the plugin that generated the event, if applicable.mount_class
(string)
- the class of plugin, e.g.,secret
,auth
.mount_accessor
(string)
- the unique ID of the mounted plugin.mount_path
(string)
- the path that the plugin is mounted at.plugin
(string)
- the name of the plugin, e.g.,kv
.
Here is an example event in JSON format:
Subscribing to events
Vault has an API endpoint, /v1/sys/events/subscribe/{eventType}
, that allows users to subscribe to events via a
WebSocket stream.
This endpoint supports the standard authentication and authorization workflows used by other Vault endpoints.
The {eventType}
parameter is a non-empty string of what event type to subscribe to, which may contain wildcards (*
)
to subscribe to multiple events, e.g., kv-v2/data-*
.
By default, the events are delivered in protobuf binary format.
The endpoint can also format the data as JSON if the json
query parameter is set to true
:
The Vault CLI support this endpoint via the events subscribe
command, which will output a stream of
JSON for the requested events (one line per event):
Policies
To subscribe to an event, you must have the following policy grants:
read
capability on/v1/sys/events/subscribe/{eventType}
, where{eventType}
is the event type that will be subscribed to. The path may contain wildcards.An example blanket policy is:
list
andsubscribe
capabilities on the path of the secret for events related to secrets. The policy must also provide asubscribe_event_types
entry with the specific events subscribers are allowed to use. For example, to receive events related to the KV secrets engine path,secret/my-data
, a valid policy would be:
Event payload for secrets is subject to change
If the policy for the path of the secret also contains theread
capability, future versions of the events functionality may include the contents of the secret in the event payload.Vault continuously evaluates policies for WebSocket subscriptions and caches the results for a short period of time to improve performance. As a result, events may still be sent for a few minutes after a token is revoked or a policy is deleted.
Supported versions
Version | Support |
---|---|
<= 1.12 | Not supported |
1.13 | Supported; disabled by default |
1.14 | Supported; disabled by default |
1.15+ | Supported; enabled by default |
For versions where events are disabled by default, you can enable the
functionality with the events.alpha1
experiment option in your Vault
configuration or from the command line with the -experiments
flag. For example: