luxolus
/
open-vault
2
0
Fork 0
Code Issues 1 Pull Requests Releases Activity

uppercase Vault in plugin doc (#4442)

This commit is contained in:
Becca Petrin 2018-04-24 10:41:37 -07:00 committed by GitHub
parent c35fe4e6f0
commit 639dc005ee
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 12 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
website/source/docs/internals/plugins.html.md
View File

@ -8,13 +8,13 @@ description: |-
# Plugin System
Certain Vault backends utilize plugins to extend their functionality outside of
what is available in the core vault code. Often times these backends will
what is available in the core Vault code. Often times these backends will
provide both builtin plugins and a mechanism for executing external plugins.
Builtin plugins are shipped with vault, often for commonly used implementations,
Builtin plugins are shipped with Vault, often for commonly used implementations,
and require no additional operator intervention to run. Builtin plugins are
just like any other backend code inside vault. External plugins, on the other
hand, are not shipped with the vault binary and must be registered to vault by
a privileged vault user. This section of the documentation will describe the
just like any other backend code inside Vault. External plugins, on the other
hand, are not shipped with the Vault binary and must be registered to Vault by
a privileged Vault user. This section of the documentation will describe the
architecture and security of external plugins.
# Plugin Architecture
@ -30,7 +30,7 @@ plugin's RPC server. While invoking the plugin process, Vault passes a [wrapping
token](https://www.vaultproject.io/docs/concepts/response-wrapping.html) to the
plugin process' environment. This token is single use and has a short TTL. Once
unwrapped, it provides the plugin with a uniquely generated TLS certificate and
private key for it to use to talk to the original vault process.
private key for it to use to talk to the original Vault process.
The [`api_addr`][api_addr] must be set in order for the plugin process establish
communication with the Vault server during mount time. If the storage backend
@ -42,7 +42,7 @@ in plugins.
## Plugin Registration
An important consideration of Vault's plugin system is to ensure the plugin
invoked by vault is authentic and maintains integrity. There are two components
invoked by Vault is authentic and maintains integrity. There are two components
that a Vault operator needs to configure before external plugins can be run, the
plugin directory and the plugin catalog entry.
@ -50,17 +50,17 @@ plugin directory and the plugin catalog entry.
The plugin directory is a configuration option of Vault, and can be specified in
the [configuration file](https://www.vaultproject.io/docs/configuration/index.html).
This setting specifies a directory that all plugin binaries must live. A plugin
can not be added to vault unless it exists in the plugin directory. There is no
can not be added to Vault unless it exists in the plugin directory. There is no
default for this configuration option, and if it is not set plugins can not be
added to vault.
added to Vault.
~> Warning: A vault operator should take care to lock down the permissions on
~> Warning: A Vault operator should take care to lock down the permissions on
this directory to ensure a plugin can not be modified by an unauthorized user
between the time of the SHA check and the time of plugin execution.
### Plugin Catalog
The plugin catalog is Vault's list of approved plugins. The catalog is stored in
Vault's barrier and can only be updated by a vault user with sudo permissions.
Vault's barrier and can only be updated by a Vault user with sudo permissions.
Upon adding a new plugin, the plugin name, SHA256 sum of the executable, and the
command that should be used to run the plugin must be provided. The catalog will
make sure the executable referenced in the command exists in the plugin
@ -81,7 +81,7 @@ Success! Data written to: sys/plugins/catalog/myplugin-database-plugin
### Plugin Execution
When a backend wants to run a plugin, it first looks up the plugin, by name, in
the catalog. It then checks the executable's SHA256 sum against the one
configured in the plugin catalog. Finally vault runs the command configured in
configured in the plugin catalog. Finally Vault runs the command configured in
the catalog, sending along the JWT formatted response wrapping token and mlock
settings (like Vault, plugins support [the use of mlock when available](https://www.vaultproject.io/docs/configuration/index.html#disable_mlock)).