scottk/vault
1
0
Fork 0
mirror of https://github.com/optim-enterprises-bv/vault.git synced 2025-10-29 17:52:32 +00:00
Code Issues Packages Projects Releases Wiki Activity

CLI content refresh - audit commands (#28642)

Browse Source 
First CLI command doc updates:
* Rewrite CLI usage page
* Rewrite token helper page
* Move and rewrite CLI emulator doc
* Rewrite `vault audit` command family docs
This commit is contained in:
Sarah Chavis
2024-10-11 16:29:15 -07:00
committed by GitHub
parent b753cc50d5
commit 927d1758e6
68 changed files with 1757 additions and 617 deletions
Download Patch File Download Diff File Expand all files Collapse all files

79
website/content/docs/commands/audit/disable.mdx
View File

@@ -1,37 +1,76 @@
--- ---
layout: docs layout: docs
page_title: audit disable - Command page_title: "audit disable - Vault CLI"
description: |- description: >-
The "audit disable" command disables an audit device at a given path, if one Disable an audit device capturing log data from Vault.
exists. This command is idempotent, meaning it succeeds even if no audit
device is enabled at the path.
--- ---
# audit disable # `audit disable`
The `audit disable` command disables an audit device at a given path, if one Disable an audit device if it exists.
exists. This command is idempotent, meaning it succeeds even if no audit device
is enabled at the path.
Once an audit device is disabled, no future audit logs are dispatched to it. The <CodeBlockConfig hideClipboard>
data associated with the audit device is unaffected. For example, if you
disabled an audit device that was logging to a file, the file would still exist
and have stored contents.
~> Note: Once an audit device is disabled, you will no longer be able to HMAC values ```shell-session
for comparison with entries in the audit logs. This is true even if you re-enable $ vault audit disable [flags] <device_path>
the audit device at the same path, as a new salt will be created for hashing.
$ vault audit disable [-help | -h]
```
</CodeBlockConfig>
## Description
`vault audit disable` deactivates an audit device without destroying data
already logged by the device. The operation is idempotent and succeeds if the
audit device is properly disabled **or** if the device path does not
correspond to an active audit device.
<Tip title="Related API endpoints">
DisableAuditDevice - [`DELETE:/sys/audit/{mount-path}`](/vault/api-docs/system/audit#disable-audit-device)
</Tip>
### Limitations and warnings
- You cannot HMAC values for comparison against audit logs for a disabled audit
device.
- Vault does not preserve HMAC encryption if you reenable an audit device at the
same path. Each time you enable a device, Vault uses a new salt for hashing.
## Command arguments
<br />
@include 'cli/audit/args/device_path.mdx'
## Command options
- None
## Command flags
- None
## Standard flags
<br />
@include 'cli/standard-settings/all-standard-flags-but-format.mdx'
## Examples ## Examples
Disable the audit device enabled at "file/": Disable a file-type audit device at the default path, `file/`:
```shell-session ```shell-session
$ vault audit disable file/ $ vault audit disable file/
Success! Disabled audit device (if it was enabled) at: file/ Success! Disabled audit device (if it was enabled) at: file/
``` ```
## Usage Disable a socket audit device at the path `audit/kv-socket`:
There are no flags beyond the [standard set of flags](/vault/docs/commands) ```shell-session
included on all commands. $ vault audit disable audit/kv-socket/
Success! Disabled audit device (if it was enabled) at: audit/kv-socket/
```

201
website/content/docs/commands/audit/enable.mdx
View File

@@ -1,47 +1,188 @@
--- ---
layout: docs layout: docs
page_title: audit enable - Command page_title: "audit enable - Vault CLI"
description: The "audit enable" command enables an audit device at a given path. description: >-
Create and enable a new audit device to capture log data from Vault.
--- ---
# audit enable # `audit enable`
The `audit enable` command enables an audit device at a given path. If an audit Enable a new audit device.
device already exists at the given path, an error is returned. Additional
options for configuring the audit device are provided as `KEY=VALUE`. Each audit
device declares its own set of configuration options.
Once an audit device is enabled, almost every request and response will be <CodeBlockConfig hideClipboard>
logged to the device.
```shell-session
$ vault audit enable [flags] <device_type> [options] [<config_argument=value>...]
$ vault audit enable [-help | -h]
```
</CodeBlockConfig>
## Description
`audit enable` creates and enables an audit device at the given path or returns
an error if an audit device already exists at the given path. The device
configuration parameters depend on the audit device type.
<Tip title="Related API endpoints">
EnableAuditDevice - [`POST:/sys/audit/{mount-path}`](/vault/api-docs/system/audit#enable-audit-device)
</Tip>
### Limitations and warnings
- None
## Command arguments
@include 'cli/audit/args/device_type.mdx'
Each audit device type also has a set of configuration arguments:
<Tabs>
<Tab heading="File">
<CodeBlockConfig hideClipboard>
```shell-session
$ vault audit enable [flags] file [options] \
file_path=<path/to/log/file> \
[mode=<file_permissions>]
```
</CodeBlockConfig>
<br />
@include 'cli/audit/args/file/file_path.mdx'
<br /><hr /><br />
@include 'cli/audit/args/file/mode.mdx'
</Tab>
<Tab heading="Socket">
<CodeBlockConfig hideClipboard>
```shell-session
$ vault audit enable [flags] socket [options] \
[address=<server_address>] \
[socket_type=<protocol>] \
[write_timeout=<wait_time>]
```
</CodeBlockConfig>
<br />
@include 'cli/audit/args/socket/address.mdx'
<br /><hr /><br />
@include 'cli/audit/args/socket/socket_type.mdx'
<br /><hr /><br />
@include 'cli/audit/args/socket/write_timeout.mdx'
</Tab>
<Tab heading="Syslog">
<CodeBlockConfig hideClipboard>
```shell-session
$ vault audit enable [flags] syslog [options] \
[facility=<process_entry_source>] \
[tag=<program_entry_source>]
```
</CodeBlockConfig>
<br />
@include 'cli/audit/args/syslog/facility.mdx'
<br /><hr /><br />
@include 'cli/audit/args/syslog/tag.mdx'
</Tab>
</Tabs>
## Command options
<br />
@include 'cli/audit/options/elide_list_responses.mdx'
<br /><hr /><br />
@include 'cli/audit/options/exclude.mdx'
<br /><hr /><br />
@include 'cli/audit/options/fallback.mdx'
<br /><hr /><br />
@include 'cli/audit/options/filter.mdx'
<br /><hr /><br />
@include 'cli/audit/options/format.mdx'
<br /><hr /><br />
@include 'cli/audit/options/hmac_accessor.mdx'
<br /><hr /><br />
@include 'cli/audit/options/log_raw.mdx'
<br /><hr /><br />
@include 'cli/audit/options/prefix.mdx'
## Command flags
<br />
@include 'cli/audit/flags/description.mdx'
<br /><hr /><br />
@include 'cli/audit/flags/local.mdx'
<br /><hr /><br />
@include 'cli/audit/flags/path.mdx'
## Standard flags
<br />
@include 'cli/standard-settings/all-standard-flags-but-format.mdx'
## Examples ## Examples
Enable the audit device "file" enabled at "file/": Enable a `file` type audit device at the default path, `file/`:
```shell-session ```shell-session
$ vault audit enable file file_path=/tmp/my-file.txt $ vault audit enable file file_path=/tmp/my-file.txt
Success! Enabled the file audit device at: file/ Success! Enabled the file audit device at: file/
``` ```
## Usage Enable a `file` type audit device at the path, `audit/file`:
The following flags are available in addition to the [standard set of ```shell-session
flags](/vault/docs/commands) included on all commands. $ vault audit enable -path=audit/file file file_path=/tmp/my-file.txt
Success! Enabled the file audit device at: audit/file/
```
- `-description` `(string: "")` - Human-friendly description for the purpose of
this audit device.
- `-local` `(bool: false)` - Mark the audit device as a local-only device.
Local devices are not replicated or removed by replication.
- `-path` `(string: "")` - Place where the audit device will be accessible. This
must be unique across all audit devices. This defaults to the "type" of the
audit device.
All audit devices support the following common options which can be supplied after
the flags documented above:
@include 'audit-options-common.mdx'
For device specific options, refer to the relevant audit device type under the [Audit Devices](/vault/docs/audit)
overview.

60
website/content/docs/commands/audit/index.mdx
View File

@@ -1,60 +0,0 @@
---
layout: docs
page_title: audit - Command
description: |-
The "audit" command groups subcommands for interacting with Vault's audit
devices. Users can list, enable, and disable audit devices.
---
# audit
The `audit` command groups subcommands for interacting with Vault's audit
devices. Users can list, enable, and disable audit devices.
For more information, please see the [audit device
documentation](/vault/docs/audit)
## Examples
Enable an audit device:
```shell-session
$ vault audit enable file file_path=/tmp/my-file.txt
Success! Enabled the file audit device at: file/
```
List all audit devices:
```shell-session
$ vault audit list
Path Type Description
---- ---- -----------
file/ file n/a
```
Disable an audit device:
```shell-session
$ vault audit disable file/
Success! Disabled audit device (if it was enabled) at: file/
```
~> Note: Once an audit device is disabled, you will no longer be able to HMAC values
for comparison with entries in the audit logs. This is true even if you re-enable
the audit device at the same path, as a new salt will be created for hashing.
## Usage
```text
Usage: vault audit <subcommand> [options] [args]
# ...
Subcommands:
disable Disables an audit device
enable Enables an audit device
list Lists enabled audit devices
```
For more information, examples, and usage about a subcommand, click on the name
of the subcommand in the sidebar.

78
website/content/docs/commands/audit/list.mdx
View File

@@ -1,19 +1,61 @@
--- ---
layout: docs layout: docs
page_title: audit list - Command page_title: "audit list - Vault CLI"
description: |- description: >-
The "audit list" command lists the audit devices enabled. The output lists the List active audit devices for Vault.
enabled audit devices and options for those devices.
--- ---
# audit list # `audit list`
The `audit list` command lists the audit devices enabled. The output lists the List information about active audit devices.
enabled audit devices and options for those devices.
<CodeBlockConfig hideClipboard>
```shell-session
$ vault audit list [flags]
$ vault audit list [-help | -h]
```
</CodeBlockConfig>
## Description
`vault audit list` displays information about active audit devices.
<Tip title="Related API endpoints">
ListAuditDevices - [`GET:/sys/audit`](/vault/api-docs/system/audit#list-enabled-audit-devices)
</Tip>
### Limitations and warnings
None.
## Command arguments
None.
## Command options
None.
## Command flags
<br />
@include 'cli/audit/flags/detailed.mdx'
## Standard flags
<br />
@include 'cli/standard-settings/all-standard-flags.mdx'
## Examples ## Examples
List all audit devices: List basic information for all active audit devices:
```shell-session ```shell-session
$ vault audit list $ vault audit list
@@ -22,27 +64,11 @@ Path Type Description
file/ file n/a file/ file n/a
``` ```
List detailed audit device information: List detailed information for all active audit devices:
```shell-session ```shell-session
$ vault audit list -detailed $ vault audit list -detailed
Path Type Description Replication Options Path Type Description Replication Options
---- ---- ----------- ----------- ------- ---- ---- ----------- ----------- -------
file/ file n/a replicated file_path=/var/log/audit.log file/ file n/a replicated file_path=/var/log/audit.log
``` ```
## Usage
The following flags are available in addition to the [standard set of
flags](/vault/docs/commands) included on all commands.
### Output options
- `-format` `(string: "table")` - Print the output in the given format. Valid
formats are "table", "json", or "yaml". This can also be specified via the
`VAULT_FORMAT` environment variable.
### Command options
- `-detailed` `(bool: false)` - Print detailed information such as options and
replication status about each auth device.

590
website/content/docs/commands/index.mdx
View File

@@ -1,144 +1,266 @@
--- ---
layout: docs layout: docs
page_title: Commands (CLI) page_title: Vault CLI usage
description: |- description: >-
In addition to a verbose HTTP API, Vault features a command-line interface Technical reference for the Vault CLI
that wraps common functionality and formats output. The Vault CLI is a single
static binary. It is a thin wrapper around the HTTP API. Every CLI command
maps directly to the HTTP API internally.
--- ---
# Vault commands (CLI) # Vault CLI
~> **Note:** The Vault command-line interface (CLI) changed substantially in The Vault CLI is a static binary that wraps the Vault API. While every CLI
0.9.2+ and may cause confusion while using older versions of Vault with this command maps directly to one or more APIs internally, not every endpoint is
documentation. Read our [upgrade exposed publicly and not every API endpoint has a corresponding CLI command.
guide](/vault/docs/upgrading/upgrade-to-0.9.2#backwards-compatible-cli-changes) for
more information.
In addition to a verbose [HTTP API](/vault/api-docs), Vault features a command-line
interface (CLI) that wraps common functionality and formats output. The Vault
CLI is a single static binary. It is a thin wrapper around the HTTP API. Every
CLI command maps directly to the HTTP API internally.
## CLI command structure
Each command is represented as a command or subcommand, and there are a number ## Usage
of command and subcommand options available: HTTP options, output options, and
command-specific options.
Construct your Vault CLI command such that the command options precede its path
and arguments if any:
<CodeBlockConfig hideClipboard> <CodeBlockConfig hideClipboard>
```text ```shell-session
vault <command> [options] [path] [args] $ vault <command> [subcommand(s)] [flag(s)] [command-argument(s)]
$ vault <command> [subcommand(s)] [-help | -h]
``` ```
</CodeBlockConfig> </CodeBlockConfig>
- `options` - [Flags](/vault/docs/commands#flags) to specify additional settings <Tip>
- `args` - API arguments specific to the operation
-> **NOTE:** Use the [command help](#command-help) to display available options Use the `-help` flag with any command to see a description of the command and a
and arguments. list of supported options and flags.
#### Examples: </Tip>
The following `write` command creates a new user (`bob`) in the userpass auth The Vault CLI returns different exit codes depending on whether and where an
method. It passes the `-address` flag to specify the Vault server address which error occurred:
precedes the path (`auth/userpass/users/bob`) and its
[argument](/vault/api-docs/auth/userpass#create-update-user) - **`0`** - Success
(`password="long-password"`) at last. - **`1`** - Local/terminal error (invalid flags, failed validation, wrong
numbers of arguments, etc.)
- **`2`** - Remote/server error (API failures, bad TLS, incorrect API
parameters, etc.)
### Authenticating to Vault
Unauthenticated users can use CLI commands with the `--help` flag, but must use
[`vault login`](/vault/docs/commands/login) or set the
[`VAULT_TOKEN`](/vault/docs/commands#standard-vault_token) environment variable
to use the CLI.
The CLI uses a token helper to cache access tokens after authenticating with
`vault login` The default file for cached tokens is `~/.vault-token` and
deleting the file forcibly logs the user out of Vault.
If you prefer to use a custom token helper,
[you can create your own](/vault/docs/commands/token-helper) and configure the
CLI to use it.
### Passing command arguments
Command arguments include any relevant configuration settings and
command-specific options. Command options pass input data as `key=value` pairs,
which you can provided inline, as a `stdin` stream, or from a local file.
<Tabs>
<Tab heading="Inline">
To pass input inline with the command, use the `<option-name>=<value>` syntax:
<CodeBlockConfig hideClipboard>
```shell-session ```shell-session
$ vault write -address="http://127.0.0.1:8200" auth/userpass/users/bob password="long-password" $ vault audit enable file file_path="/var/log/vault.log"
``` ```
If multiple options (`-address` and `-namespace`) and </CodeBlockConfig>
[arguments](/vault/api-docs/auth/userpass#create-update-user) (`password` and
`policies`) are specified, the command would look like: </Tab>
<Tab heading="stdin">
To pass input from `stdin`, use `-` as a stand-in for the entire `key=value`
pair or a specific option value.
To pipe the option and value, use a JSON object with the option name and value:
<CodeBlockConfig hideClipboard>
```shell-session ```shell-session
$ vault write -address="http://127.0.0.1:8200" -namespace="my-organization" \ $ echo -n '{"file_path":"/var/log/vault.log"}' | vault audit enable file -
auth/userpass/users/bob password="long-password" policies="admin"
``` ```
The options (flags) come after the command (or subcommand) preceding the path, </CodeBlockConfig>
and the args always follow the path to set API parameter values.
The four most common operations in Vault are [read](/vault/docs/commands/read), To pipe the option value by itself, provide the option name inline:
[write](/vault/docs/commands/write), [delete](/vault/docs/commands/delete), and
[list](/vault/docs/commands/list). These operations work on most paths in Vault. Some
paths will contain secrets while other paths may contain configuration. Whatever it
is, the primary interface for reading and writing data to Vault is similar.
### Print cURL command <CodeBlockConfig hideClipboard>
To see the equivalent API call to perform the same operation, use the
`-output-curl-string` flag after the subcommand.
```shell-session ```shell-session
$ vault write -output-curl-string auth/userpass/users/bob password="long-password" $ echo -n "/var/log/vault.log" | vault audit enable file file_path=-
curl -X PUT -H "X-Vault-Request: true" -H "X-Vault-Token: $(vault print token)" -d '{"password":"long-password"}' http://127.0.0.1:8200/v1/auth/userpass/users/bob
``` ```
#### Print policy requirements </CodeBlockConfig>
To view the policy requirements to perform an operation, use the `-output-policy` flag after the subcommand. </Tab>
``` <Tab heading="Local file">
$ vault kv put -output-policy kv/secret value=itsasecret
path "kv/data/secret" { To pass data as a file, use `@` as a stand-in for the entire
capabilities = ["create", "update"] `<option-name>=<value>` pair or a specific option value.
To pass the option and value, use a JSON file:
<CodeBlockConfig hideClipboard>
```shell-session
data.json:
{
"file_path":"/var/log/vault.log"
} }
$ vault audit enable file @data.json
``` ```
## Command help </CodeBlockConfig>
There are two primary ways to get help in Vault: [CLI help (`help`)](#cli-help) To pass the option value by itself, use the option name inline and pass the
and [API help (`path-help`)](#api-help). value as text:
### CLI help <CodeBlockConfig hideClipboard>
Use `help` (or `-h` for shorthand) to see the CLI help output which corresponds
to your Vault version.
To get CLI help:
```shell-session ```shell-session
$ vault help data.txt:
/var/log/vault.log
$ vault audit enable file file_path=@data.txt
``` ```
**Example:** To get help on the `kv` command. </CodeBlockConfig>
If you use `@` as part of an argument **name** in `<option-name>=<value>`
format, Vault treats the `@` as part of the key name, rather than a file
reference. As a result, Vault does not support filenames that include the `=`
character.
<Note title="Escape literal '@' values">
To keep Vault from parsing values that begin with a literal `@`, escape the
value with a backslash (`\`):
<CodeBlockConfig hideClipboard>
```shell-session ```shell-session
$ vault kv help $ vault login -method userpass \
username="mitchellh" \
password="\@badpasswordisbad"
``` ```
The help output displays available subcommands, parameters, and command flags. </CodeBlockConfig>
### API help </Note>
To invoke the Vault API paths, you can use the [read](/vault/docs/commands/read) (for </Tab>
HTTP GET), [write](/vault/docs/commands/write) (for HTTP PUT or POST),
[delete](/vault/docs/commands/delete) (for HTTP DELETE), and
[list](/vault/docs/commands/list) (for HTTP LIST) commands.
Use `path-help` to get Vault API help: </Tabs>
### Calling API endpoints
To invoke an API endpoint with the Vault CLI, you can use one of the following
CLI commands with the associated endpoint path:
CLI command | HTTP verbs
-------------- | -------------
`vault read` | `GET`
`vault write` | `PUT`, `POST`
`vault delete` | `DELETE`
`vault list` | `LIST`
For example, to call the UpsertLDAPGroup endpoint,
`/auth/ldap/groups/{group-name}` to create a new LDAP group called `admin`:
<CodeBlockConfig hideClipboard>
```shell-session ```shell-session
$ vault path-help -h $ vault write /auth/ldap/groups/admin policies="admin,default"
``` ```
The `path-help` retrieves API help on any API paths. Vault API paths provide </CodeBlockConfig>
built-in help in markdown format. This includes system paths, secret engines,
and auth methods.
**Example:** API help on the [`sys/mounts/`](/vault/api-docs/system/mounts) path. <Tip title="Core plugins have dedicated commands">
You can use `read`, `write`, `delete`, or `list` with the relevant paths for
any valid API endpoint, but some plugins are central to the functionality
of Vault and have dedicated CLI commands:
- [`vault kv`](/vault/docs/commands/kv)
- [`vault transit`](/vault/docs/commands/transit)
- [`vault transform`](/vault/docs/commands/transform)
- [`vault token`](/vault/docs/commands/token)
</Tip>
## Enable autocomplete
The CLI does not autocomplete commands by default. To enable autocomplete for
flags, subcommands, and arguments (where supported), use the
`-autocomplete-install` flag and **restart your shell session**:
```shell-session
$ vault -autocomplete-install
```
To use autocomplete, press `<tab>` while typing a command to show a list of
available completions. Or, use the `-<tab>` flag to show available flag
completions for the current command.
<Tip>
If you have configured the `VAULT_*` environment variables needed to connect to
your Vault instance, the autocomplete feature automatically queries the Vault
server and returns helpful argument suggestions.
</Tip>
## Configure environment variables
You can use environment variables to configure the CLI globally. Some
configuration settings have a corresponding CLI flag to configure a specific
command.
For example, `export VAULT_ADDR='http://localhost:8200'` sets the
address of your Vault server globally, while
`-address='http://someotherhost:8200'` overrides the value for a specific
command.
---
@include 'cli/standard-settings/all-env-variables.mdx'
## Troubleshoot CLI errors
If you run into errors when executing a particular CLI command, the following
flags and commands can help you track down the problem.
### Confirm you are using the right endpoint or command
If a command behaves differently than expected or you need details about a
specific endpoint, you can use the
[`vault path-help`](/vault/docs/commands/path-help) command to see the help text
for a given endpoint path.
For example, to see the help for `sys/mounts`:
```shell-session ```shell-session
$ vault path-help sys/mounts $ vault path-help sys/mounts
@@ -167,293 +289,35 @@ This path responds to the following HTTP methods.
Unmount the specified mount point. Unmount the specified mount point.
``` ```
The help output displays supported child-paths and available parameters if there ### Construct the associated cURL command
are any.
## Command input To determine if the problem exists with the structure of your CLI command or the
associated endpoint, you can use the `-output-curl-string` flag:
To write data to Vault, the input can be a part of the command in key-value For example, to test that a `vault write` command to create a new user is not
format. failing due to an issue with the `/auth/userpass/users/{username}` endpoint, use
the generated cURL command to call the endpoint directly:
```shell-session ```shell-session
$ vault kv put secret/password value=itsasecret $ vault write -output-curl-string auth/userpass/users/bob password="long-password"
curl -X PUT -H "X-Vault-Request: true" -H "X-Vault-Token: $(vault print token)" -d '{"password":"long-password"}' http://127.0.0.1:8200/v1/auth/userpass/users/bob
``` ```
However, some Vault API require more advanced structures such as maps. You can ### Construct the required Vault policy
use stdin or file input instead.
### stdin To determine if the problem relates to insufficient permissions, you can use the
`-output-policy` flag to construct a minimal Vault policy that grants the
permissions needed to execute the relevant command.
Some commands in Vault can read data from stdin using `-` as the value. If `-` For example, to confirm you have permission to write a secret to the `kv`
is the entire argument, Vault expects to read a JSON object from stdin: plugin, mounted at `kv/secret`, use `-output-policy` then confirm you have the
capabilities listed:
```shell-session
$ echo -n '{"value":"itsasecret"}' | vault kv put secret/password -
``` ```
$ vault kv put -output-policy kv/secret value=itsasecret
In addition to reading full JSON objects, Vault can read just a value from path "kv/data/secret" {
stdin: capabilities = ["create", "update"]
}
```shell-session
$ echo -n "itsasecret" | vault kv put secret/password value=-
```
### Files
Some commands can also read data from a file on disk. The usage is similar to
stdin as documented above. If an argument starts with `@`, Vault will read it as
a file:
```shell-session
$ vault kv put secret/password @data.json
```
Or specify the contents of a file as a value:
```shell-session
$ vault kv put secret/password value=@data.txt
```
To use values that begin with an `@` character, escape the character with a
backslash (`\`) to keep Vault from parsing the value as a file location:
```shell-session
$ vault login -method userpass username="mitchellh" password="\@foo"
```
Note that if an argument is supplied in a @key=value format, Vault will treat that as a
kv pair with the key being `@key`, not a file called `key=value`. This also means that Vault
does not support filenames with `=` in them.
## Mount flag syntax (KV)
All `kv` commands can alternatively refer to the path to the KV secrets engine using a flag-based syntax like `$ vault kv get -mount=secret password`
instead of `$ vault kv get secret/password`. The mount flag syntax was created to mitigate confusion caused by the fact that for KV v2 secrets,
their full path (used in policies and raw API calls) actually contains a nested `/data/` element (e.g. `secret/data/password`) which can be easily overlooked when using
the above KV v1-like syntax `secret/password`. To avoid this confusion, all KV-specific docs pages will use the `-mount` flag.
## Exit codes
The Vault CLI aims to be consistent and well-behaved unless documented
otherwise.
- Local errors such as incorrect flags, failed validations, or wrong numbers
of arguments return an exit code of 1.
- Any remote errors such as API failures, bad TLS, or incorrect API parameters
return an exit status of 2
Some commands override this default where it makes sense. These commands
document this anomaly.
## Autocompletion
The `vault` command features opt-in autocompletion for flags, subcommands, and
arguments (where supported).
Enable autocompletion by running:
```shell-session
$ vault -autocomplete-install
```
~> Be sure to **restart your shell** after installing autocompletion!
When you start typing a Vault command, press the `<tab>` character to show a
list of available completions. Type `-<tab>` to show available flag completions.
If the `VAULT_*` environment variables are set, the autocompletion will
automatically query the Vault server and return helpful argument suggestions.
## Token helper
By default, the Vault CLI uses a "token helper" to cache the token after
authentication. This is conceptually similar to how a website securely stores
your session information as a cookie in the browser. Token helpers are
customizable, and you can even build your own.
The default token helper stores the token in `~/.vault-token`. You can delete
this file at any time to "logout" of Vault.
## Environment variables
The CLI reads the following environment variables to set behavioral defaults.
This can alleviate the need to repetitively type a flag. Flags always take
precedence over the environment variables. Each of the following environment
variables must be set on the Vault process. In Vault 1.13+, all environment
variables available to the Vault process will be logged during startup.
### `VAULT_TOKEN`
Vault authentication token. Conceptually similar to a session token on a
website, the `VAULT_TOKEN` environment variable holds the contents of the token.
For more information, please see the [token
concepts](/vault/docs/concepts/tokens) page.
### `VAULT_ADDR`
Address of the Vault server expressed as a URL and port, for example:
`https://127.0.0.1:8200/`.
### `VAULT_CACERT`
Path to a PEM-encoded CA certificate _file_ on the local disk. This file is used
to verify the Vault server's SSL certificate. This environment variable takes
precedence over `VAULT_CAPATH`.
### `VAULT_CAPATH`
Path to a _directory_ of PEM-encoded CA certificate files on the local disk.
These certificates are used to verify the Vault server's SSL certificate.
### `VAULT_CLIENT_CERT`
Path to a PEM-encoded client certificate on the local disk. This file is used
for TLS communication with the Vault server.
### `VAULT_CLIENT_KEY`
Path to an unencrypted, PEM-encoded private key on disk which corresponds to the
matching client certificate.
### `VAULT_CLIENT_TIMEOUT`
Timeout variable. The default value is 60s.
### `VAULT_CLUSTER_ADDR`
Address that should be used for other cluster members to connect to this node
when in High Availability mode.
### `VAULT_FORMAT`
Provide Vault output (read/status/write) in the specified format. Valid formats are "table", "json", or "yaml".
### `VAULT_LICENSE`
[Enterprise, Server only] Specify a license to use for this node. This takes
precedence over [#VAULT_LICENSE_PATH](#vault_license_path) and
[license_path in config](/vault/docs/configuration#license_path).
### `VAULT_LICENSE_PATH`
[Enterprise, Server only] Specify a path to a license on disk to use for this node.
This takes precedence over [license_path in config](/vault/docs/configuration#license_path).
### `VAULT_LOG_LEVEL`
Set the Vault server's log level. The supported values are `trace`, `debug`,
`info`, `warn`, and `err`. The default log level is `info`.
### `VAULT_MAX_RETRIES`
Maximum number of retries when certain error codes are encountered. The default
is `2`, for three total attempts. Set this to `0` or less to disable retrying.
Error codes that are retried are 412 (client consistency requirement not
satisfied) and all 5xx except for 501 (not implemented).
### `VAULT_REDIRECT_ADDR`
Address that should be used when clients are redirected to this node when in
High Availability mode.
### `VAULT_SKIP_VERIFY`
Do not verify Vault's presented certificate before communicating with it.
Setting this variable is not recommended and voids Vault's [security
model](/vault/docs/internals/security).
### `VAULT_TLS_SERVER_NAME`
Name to use as the SNI host when connecting via TLS.
### `VAULT_CLI_NO_COLOR`
If provided, Vault output will not include ANSI color escape sequence characters.
### `VAULT_RATE_LIMIT`
This environment variable will limit the rate at which the `vault` command
sends requests to Vault.
This environment variable has the format `rate[:burst]` (where items in `[]` are
optional). If not specified, the burst value defaults to rate. Both rate and
burst are specified in "operations per second". If the environment variable is
not specified, then the rate and burst will be unlimited _i.e._ rate
limiting is off by default.
_Note:_ The rate is limited for each invocation of the `vault` CLI. Since
each invocation of the `vault` CLI typically only makes a few requests,
this environment variable is most useful when using the Go
[Vault client API](/vault/api-docs/libraries#go).
### `VAULT_NAMESPACE`
The namespace to use for the command. Setting this is not necessary
but allows using relative paths.
### `VAULT_SRV_LOOKUP`
Enables the client to lookup the host through DNS SRV look up as described in this
[draft](https://tools.ietf.org/html/draft-andrews-http-srv-02).
This is not designed for high-availability, just discovery.
The draft specifies that the SRV record lookup is ignored if a port is given.
### `VAULT_MFA`
**ENTERPRISE ONLY**
MFA credentials in the format `mfa_method_name[:key[=value]]` (items in `[]` are
optional). Note that when using the environment variable, only one credential
can be supplied. If a MFA method expects multiple credential values, or if there
are multiple MFA methods specified on a path, then the CLI flag `-mfa` should be
used.
### `VAULT_HTTP_PROXY`
HTTP or HTTPS proxy location which should be used by all requests to access Vault.
When present, this overrides the default proxy resolution behavior.
Format should be `http://server:port` or `https://server:port`.
(See `VAULT_PROXY_ADDR` below).
### `VAULT_PROXY_ADDR`
HTTP or HTTPS proxy location which should be used by all requests to access Vault.
When present, this overrides the default proxy resolution behavior.
Format should be `http://server:port` or `https://server:port`.
~> Note: When using `VAULT_HTTP_PROXY` or `VAULT_PROXY_ADDR` any of the standard
proxy variables found in the environment will be ignored.
Specifically `HTTP_PROXY`, `HTTPS_PROXY` and `NO_PROXY`.
All requests will resolve the specified proxy; there is no way to exclude
domains from consulting the proxy server.
~> Note: If both `VAULT_HTTP_PROXY` and `VAULT_PROXY_ADDR` environment
variables are supplied, `VAULT_PROXY_ADDR` will be prioritized and preferred.
### `VAULT_DISABLE_REDIRECTS`
Prevents the Vault client from following HTTP redirects. By default, the
Vault CLI client only follows the first redirect. Additional redirects can
result in an empty or unexpected response.
~> **Note:** Disabling redirect following behavior could cause issues with commands such as 'vault operator raft snapshot' as this command redirects the request to the cluster's primary node.
### `VAULT_HEADERS`
JSON-encoded headers to include in Vault HTTP requests performed by the CLI. For example: `{"FOO": "BAR"}`.
Like the `-header` CLI parameter, headers starting with `X-Vault-` are forbidden.
## Flags
There are different CLI flags that are available depending on subcommands. Some
flags, such as those used for setting HTTP and output options, are available
globally, while others are specific to a particular subcommand. For a complete
list of available flags, run:
```shell-session
$ vault <subcommand> -h
``` ```

22
website/content/docs/commands/kv/index.mdx
View File

@@ -26,6 +26,28 @@ for KV v2, because it is not actually the full API path to the secret
mount flag syntax was introduced. Upgrade to at least Vault 1.11, or refer to previous versions of the docs mount flag syntax was introduced. Upgrade to at least Vault 1.11, or refer to previous versions of the docs
which only use the old syntax to refer to the mount path. which only use the old syntax to refer to the mount path.
## Mount flag syntax (KV)
All `kv` commands can alternatively refer to the path to the KV secrets engine using a flag-based syntax like `$ vault kv get -mount=secret password`
instead of `$ vault kv get secret/password`. The mount flag syntax was created to mitigate confusion caused by the fact that for KV v2 secrets,
their full path (used in policies and raw API calls) actually contains a nested `/data/` element (e.g. `secret/data/password`) which can be easily overlooked when using
the above KV v1-like syntax `secret/password`. To avoid this confusion, all KV-specific docs pages will use the `-mount` flag.
## Exit codes
The Vault CLI aims to be consistent and well-behaved unless documented
otherwise.
- Local errors such as incorrect flags, failed validations, or wrong numbers
of arguments return an exit code of 1.
- Any remote errors such as API failures, bad TLS, or incorrect API parameters
return an exit status of 2
Some commands override this default where it makes sense. These commands
document this anomaly.
## Examples ## Examples
Create or update the key named "creds" in the KV version 2 enabled at "secret" Create or update the key named "creds" in the KV version 2 enabled at "secret"

299
website/content/docs/commands/token-helper.mdx
View File

@@ -1,53 +1,303 @@
--- ---
layout: docs layout: docs
page_title: Token Helpers page_title: Use a custom token helper
description: >- description: >-
The Vault CLI supports external token helpers that make retrieving, setting The Vault CLI supports external token helpers to help simplify retrieving,
and erasing tokens simpler to use. setting and erasing authentication tokens.
--- ---
# Token helpers # Use a custom token helper
A token helper is an external program that Vault calls to save, retrieve or erase A **token helper** is a program or script that saves, retrieves, or erases a
a saved token. The token helper could be a very simple script or a more complex saved authentication token.
program depending on your needs. The interface to the external token helper is
extremely simple.
By default the Vault CLI provides a built in tool for authenticating with any By default, the Vault CLI includes a token helper that caches tokens from any
of the enabled authentication backends. Once authenticated, the CLI will store enabled authentication backend in a `~/.vault-token` file. You can customize
the generated token on disk in the `~/.vault-token` file. By using a token helper, the caching behavior with a custom token helper.
this default functionality can be changed.
## Configuration ## Step 1: Script your helper
To configure a token helper, edit (or create) the file `~/.vault` and add a line similar to: Your token helper must accept a single command-line argument:
Argument | Action
-------- | ------
`get` | Fetch and print a cached authentication token to `stdout`
`store` | Read an authentication token from `stdin` and save it in a secure location
`erase` | Delete a cached authentication token
You can manage the authentication tokens in whatever way you prefer, but your
helper must adhere to following output requirements:
- Limit `stdout` writes to token strings.
- Write all error messages to `stderr`.
- Write all non-error and non-token output to `syslog` or a log file.
- Return the status code `0` on success.
- Return non-zero status codes for errors.
## Step 2: Configure Vault
To configure a custom token helper, edit (or create) a CLI configuration file
called `.vault` under your home directory and set the `token_helper` parameter
with the **fully qualified path** to your new helper:
<Tabs>
<Tab heading="Linux shell" group="nix">
``` ```
token_helper = "/path/to/token/helper.sh" echo 'token_helper = "/path/to/token/helper.sh"' >> ${HOME}/.vault
``` ```
You will need to use the fully qualified path to the token helper script. The script should be executable. </Tab>
## Developing a token helper <Tab heading="Powershell" group="ps">
The interface to a token helper is extremely simple: the script is passed with one argument that could be `get`, `store` or `erase`. If the argument is `get`, the script should do whatever work it needs to do to retrieve the stored token and then print the token to `STDOUT`. If the argument is `store`, Vault is asking you to store the token. Finally, if the argument is `erase`, your program should erase the stored token. Make sure to use UTF-8 encoding (`ascii`) or Vault may complain about invalid
characters when reading the configuration file:
If your program succeeds, it should exit with status code 0. If it encounters an issue that prevents it from working, it should exit with some other status code. You should write a user-friendly error message to `STDERR`. You should never write anything other than the token to `STDOUT`, as Vault assumes whatever it gets on `STDOUT` is the token. ```powershell
'token_helper = "\\path\\to\\token\\helper.ps1"' | `
Out-File -FilePath ${env:USERPROFILE}/.vault -Encoding ascii -Append
```
### Example token helper </Tab>
This is an example token helper written in Ruby that stores and retrieves tokens in a json file called `~/.vault_tokens`. The key is the environment variable \$VAULT_ADDR, this allows the Vault user to easily store and retrieve tokens from a number of different Vault servers. </Tabs>
<Tip>
Make sure the script is executable by the Vault binary.
</Tip>
## Example token helper
The following token helper manages tokens in a JSON file in the home directory
called `.vault_tokens`.
The helper relies on the `$VAULT_ADDR` environment variable to store and
retrieve tokens from different Vault servers.
<CodeTabs>
```shell-session
#!/bin/bash
function write_error(){ >&2 echo $@; }
# Customize the hash key for tokens. Currently, we remove the strings
# 'https://', '.', and ':' from the passed address (Vault address environment
# by default) because jq has trouble with special characeters in JSON field
# names
function createHashKey {
local key=""
if [[ -z "${1}" ]] ; then key="${VAULT_ADDR}"
else key="${1}"
fi
# We index the token according to the Vault server address by default so
# return an error if the address is empty
if [[ -z "${key}" ]] ; then
write_error "Error: VAULT_ADDR environment variable unset."
exit 100
fi
key=${key//"http://"/""}
key=${key//"."/"_"}
key=${key//":"/"_"}
echo "addr-${key}"
}
TOKEN_FILE="${HOME}/.vault_token"
KEY=$(createHashKey)
TOKEN="null"
# If the token file does not exist, create it
if [ ! -f ${TOKEN_FILE} ] ; then
echo "{}" > ${TOKEN_FILE}
fi
case "${1}" in
"get")
# Read the current JSON data and pull the token associated with ${KEY}
TOKEN=$(cat ${TOKEN_FILE} | jq --arg key "${KEY}" -r '.[$key]')
# If the token != to the string "null", print the token to stdout
# jq returns "null" if the key was not found in the JSON data
if [ ! "${TOKEN}" == "null" ] ; then
echo "${TOKEN}"
fi
exit 0
;;
"store")
# Get the token from stdin
read TOKEN
# Read the current JSON data and add a new entry
JSON=$(
jq \
--arg key "${KEY}" \
--arg token "${TOKEN}" \
'.[$key] = $token' ${TOKEN_FILE}
)
;;
"erase")
# Read the current JSON data and remove the entry if it exists
JSON=$(
jq \
--arg key "${KEY}" \
--arg token "${TOKEN}" \
'del(.[$key])' ${TOKEN_FILE}
)
;;
*)
# change to stderr for real code
write_error "Error: Provide a valid command: get, store, or erase."
exit 101
esac
# Update the JSON file and return success
echo $JSON | jq "." > ${TOKEN_FILE}
exit 0
```
```powershell
<#
.Synopsis
Vault token helper script
.INPUTS
Positional/command line argument: get, store, erase
.OUTPUTS
get: prints a cached authentication token to stdin (if it exists)
store: no output, updates the token cache
erase: no output, updates the token cache
#>
<#
.Synopsis
CreateHashKey
.DESCRIPTION
Customize the hash key for tokens. Currently, we remove the strings
'https://', '.', and ':' from the passed address (Vault address environment by
default) variable to simplify the hash key string
#>
function CreateHashKey {
Param($address = "${env:VAULT_ADDR}")
# We index the token according to the Vault server address by default so
# return an error if the address is empty
if ( -not $address) {
Write-Error "[Missing value] env:VAULT_ADDR currently unset."
exit 101
}
$key = ${address}.Replace("/","").Replace(".","_").Replace(":","_")
return ${key}.Replace("http_", "addr-")
}
<#
.Synopsis
GetTokenCache
.DESCRIPTION
Read in or create a new token cache and initialize the hash
#>
function GetTokenCache {
Param($filename)
# Read the JSON file (token cache) and initialize the hash data or create an
# empty hash if the file does not exist yet
if ( Get-Item -Path "./${filename}" -ErrorAction SilentlyContinue ) {
$fileData = (Get-Content "${filename}" -Raw | ConvertFrom-Json -AsHashtable)
} else {
$fileData = (Write-Output "{}" | ConvertFrom-Json -AsHashtable)
}
return $fileData
}
<#
.Synopsis
UpdateTokenCache
.DESCRIPTION
Write the token hash out to the cache
#>
function UpdateTokenCache {
Param($filename, $fileData)
$jsonData = ($fileData | ConvertTo-Json)
# Convert the hash to JSON and update the token cache
$jsonData | Out-File -Encoding ascii "${filename}"
return
}
$tokenFile = "${env:USERPROFILE}/.vault_token"
$hashData = (GetTokenCache "${tokenFile}")
$key = (CreateHashKey)
$token = $null
switch -Exact -CaseSensitive (${args}[0]) {
"get" {
# Print the token to stdin and return success
Write-Output ${hashData}.${key}
exit 0
}
"store" {
$token = Read-Host
# Add the new token to the hash
$hashData["${key}"] = "${token}"
}
"erase" {
# Erase the token entry if it exists
if ($hashData.ContainsKey("${key}") ) {
$hashData.Remove("${key}")
}
}
Default {
# The argument was invalid so return an error
Write-Error "[Invalid argument] Command must be: get, store, or erase."
exit 102
}
}
# Update the token cache and return success
UpdateTokenCache ${tokenFile} ${hashData}
exit 0
```
```ruby ```ruby
#!/usr/bin/env ruby #!/usr/bin/env ruby
require 'json' require 'json'
// We index the token according to the Vault server address
// so the VAULT_ADDR variable is required
unless ENV['VAULT_ADDR'] unless ENV['VAULT_ADDR']
STDERR.puts "No VAULT_ADDR environment variable set. Set it and run me again!" STDERR.puts "No VAULT_ADDR environment variable set. Set it and run me again!"
exit 100 exit 100
end end
// If the token file does not exist, create and initialize the hashmap
begin begin
tokens = JSON.parse(File.read("#{ENV['HOME']}/.vault_tokens")) tokens = JSON.parse(File.read("#{ENV['HOME']}/.vault_tokens"))
rescue Errno::ENOENT => e rescue Errno::ENOENT => e
@@ -55,15 +305,22 @@ rescue Errno::ENOENT => e
tokens = {} tokens = {}
end end
// Get the first command line argument
case ARGV.first case ARGV.first
when 'get' when 'get'
// Write the token to stdout if it exists
print tokens[ENV['VAULT_ADDR']] if tokens[ENV['VAULT_ADDR']] print tokens[ENV['VAULT_ADDR']] if tokens[ENV['VAULT_ADDR']]
exit 0 exit 0
when 'store' when 'store'
// Read the token from stdin
tokens[ENV['VAULT_ADDR']] = STDIN.read tokens[ENV['VAULT_ADDR']] = STDIN.read
when 'erase' when 'erase'
// Delete the token entry if it exists
tokens.delete!(ENV['VAULT_ADDR']) tokens.delete!(ENV['VAULT_ADDR'])
end end
// Update the token file
File.open("#{ENV['HOME']}/.vault_tokens", 'w') { |file| file.write(tokens.to_json) } File.open("#{ENV['HOME']}/.vault_tokens", 'w') { |file| file.write(tokens.to_json) }
``` ```
</CodeTabs>

84
website/content/docs/commands/web.mdx
View File

@@ -1,84 +0,0 @@
---
layout: docs
page_title: Web REPL - Command
description: |-
The Vault web user interface (UI) includes an advanced mode that mimics some basic commands from the Vault CLI. It can be useful for users more familiar with the CLI or API as it lets a user directly input the paths they wish to manipulate.
---
# Web REPL
The Vault web user interface (UI) includes an advanced mode that mimics some basic commands from the Vault CLI. It can be useful for users more familiar with the CLI or API as it lets a user directly input the paths they wish to manipulate.
~> **Note:** The Vault Web REPL is _not_ a full terminal emulator. Features like environment variables, HEREDOC, or piping of data or files will not work unless explicitly documented.
## Command history
The Web REPL will keep a history of all of the commands you've entered in your current session. If you refresh the browser or use the `clearall` command, this history will be reset.
To cycle through the command history, you can use the up and down arrows when the REPL input has focus. If you reach either beginning of the history by pressing up, it will cycle back to the most recent command. Pressing the down arrow will stop at an empty prompt after the most recent command.
## Commands
The Vault Web REPL implements the Create/Read/Update/Delete/List (CRUDL) commands from the Vault CLI. With these basic commands, a user can interact with most of the Vault API even if there aren't explicit screens for it in Vault's Web UI.
All commands can optionally be prefixed with `vault` as if you were using the CLI - the intent being that a large number of example commands from the documentation should work via simply copy and pasting them from the documentation site into the web REPL.
### delete
`delete` in the Web REPL is the same as using the [`delete`](/vault/docs/commands/delete) command in the CLI. It can be used to delete secrets and configuration from Vault at the given path via an HTTP DELETE.
### kv-get
The Web REPL is a convenience method exclusively for reading secrets from a KV version 2 secrets engine, much like [`kv read`](/vault/docs/commands/kv/read). The command `kv-get secret/foo` is functionally equivalent to running the REPL `read` command with the full API path: `read secret/data/foo`.
There is also a `-metadata` flag that is shorthand for `-field=metadata`.
### list
The Web REPL `list` command is functionally identical to the CLI [`list`](/vault/docs/commands/list) command. It is used to list keys at a given path such as roles in an auth method, or keys for a given secrets engine. The Web REPL version issues a GET with the `?list=true` query parameter as described in the [API overview](/vault/api-docs#api-operations) since web browsers do not support custom HTTP verbs.
### read
Like the CLI [`read`](/vault/docs/commands/read) command, the Web REPL `read` performs an HTTP GET on a given path.
Also like the CLI `read`, the REPL implements `-field` and `-format` flags. The output defaults to "table" format, but also supports "json" output.
### write
This is a Web REPL implementation of the CLI [`write`](/vault/docs/commands/write) command - it will perform an HTTP POST to the given path with the given data. Notably the special "**@**" syntax from the CLI is not implemented - data must be specified as arguments to the command. Because of this, any API fields that require data structures not expressible as arguments are not supported.
This is the major shortcoming of the Vault Web REPL.
## Command options
### field
If you are only interested in a single field in the response, you can use the `-field` flag which will specify that the REPL should only print that field in the response. Using this in conjunction with `-wrap-ttl` is nice because you can return just the wrapped token by doing something like this:
```
kv-get secret/one -wrap-ttl=10m -field=token
```
### force
Some delete paths require using `-force` as a confirmation that the delete is intentional. Using `delete` without this flag on a path that needs it will result in an error that tells you `-force` is required.
### format
`read` commands default to the "table" format, if you would like to see the JSON format of a response, you can pass `-format=json`. This is most often useful for responses that have deeply nested objects that don't fit well in the table format.
### metadata
As mentioned above in the `kv-get` section - this flag is shorthand for `-field=metadata` which is useful when reading secrets from the KVv2 secrets engine.
### wrap-ttl
Like the `vault` CLI, the Web REPL supports creating [response-wrapping tokens](/vault/docs/concepts/response-wrapping#response-wrapping-token-creation).The format is also the same: it can be an integer that sets the wrapping TTL for a number of seconds, or it can be a string that specifys the length of the duration in seconds (`15s`), miniutes (`20m`), or hours (`25h`).
## REPL-specific commands
### api
This will navigate you to an interactive OpenAPI explorer in the Vault UI. This explorer will only contain the paths your current `VAULT_TOKEN` has permissions to operate on.
### clear
This will clear all of the output currently in the Web REPL log.
### clearall
This clears the output _and_ the command history in the Web REPL. After running `clearall`, arrowing up won't show previously executed commands.
### fullscreen
`fullscreen` will toggle the Web REPL into a view that expands to cover the whole browser window.
### help
Submitting the form with no input or typing `help` in the Web REPL will print out a list of available commands with short descriptions.
### refresh
If you've run a command in the Web REPL that affects the data on a page you're currently on in the Vault UI, the UI does not automatically refresh. The `refresh` command is a convenient way to refresh the current route without having to navigate away or fully refresh the browser application.

62
website/content/docs/ui/web-cli.mdx Normal file
View File

@@ -0,0 +1,62 @@
---
layout: docs
page_title: CLI emulation in the Vault GUI
description: >-
Run basic Vault CLI commands in your Vault web UI with a REPL terminal.
---
# CLI emulation in the Vault GUI
The Vault GUI includes an advanced mode that uses a read–eval–print loop (REPL)
terminal to mimic basic create/read/update/delete/list (CRUDL) commands for
users who are more familiar with the Vault CLI than the GUI.
<Note title="Limited emulation">
The Vault Web REPL terminal **is not** a full terminal emulator. You cannot
use typical `bash` elements like environment variables, HEREDOC, or data/file
piping unless explicitly stated otherwise.
</Note>
## Command history
The Web REPL keeps a history of all commands your enter during the current
session. Refreshing the browser window and using the `clearall` command resets
your command history.
Use the up and down arrows while the REPL prompt has focus to cycle through the
command history. Fully cycling backward, past the start of the history, wraps
around to the most recent command. Cycling forward past the most recent command
stops at an empty prompt.
## Supported commands
<Tip>
The Web REPL terminal accepts commands with, or without, the `vault` prefix to
ensure example commands from the Vault documentation work when pasted into
the Web REPL terminal.
</Tip>
## Supported Vault CLI commands
REPL command | Associated CLI command | REPL differences
------------ | --------------------------------------- | ----------------------
`delete` | [`delete`](/vault/docs/commands/delete) | None
`list` | [`list`](/vault/docs/commands/list) | Issues GET requests with the `?list=true` query parameter rather than `LIST` requests
`read` | [`read`](/vault/docs/commands/read) | None
`write` | [`write`](/vault/docs/commands/write) | Does not support `@` syntax to set parameters and actions that require data structures as input are not supported
`kv-get` | [`kv get`](/vault/docs/commands/kv/get) | Only supports path syntax and KVv2 plugins, supports the `-metatdata` flag as shorthand for `-field=metadata`
## REPL-specific commands
Command | Description
------------ | -----------
`api` | Opens the interactive OpenAPI explorer in the Vault UI with information for all endpoints you can use with your current permissions
`clear` | Clears all output in the current Web REPL log
`clearall` | Clears the command history and all output in the current Web REPL log
`fullscreen` | Toggles the Web REPL terminal into, and out of, fullscreen view in the browser window
`help` | Prints the list of all available REPL commands with short descriptions
`refresh` | Refresh data on the current Vault GUI page to see the affects of a recent command

8
website/content/partials/cli/audit/args/device_path.mdx Normal file
View File

@@ -0,0 +1,8 @@
<a id="audit-arg-path" />
**`path (string : <required>)`**
The internal path where Vault accesses the audit device. Audit device paths are
unique across all audit devices.
**Example**: `"/audit/kv-file"`

11
website/content/partials/cli/audit/args/device_type.mdx Normal file
View File

@@ -0,0 +1,11 @@
<a id="audit-device-type" />
**`device_type (enum : <required>)`**
The audit device type to create.
Enum | Description
-------- | -----------
`file` | Write log entries to a file on the Vault server.
`socket` | Write log entries to an existing TCP, UDP, or UNIX socket.
`syslog` | Write log entries using the existing system logging protocol.

15
website/content/partials/cli/audit/args/file/file_path.mdx Normal file
View File

@@ -0,0 +1,15 @@
<a id="audit-file-file_path" />
**`file_path (string : <required>)`**
Location on the audit log on the Vault server. Must be one of the following:
Value | Description
------------------------- | -----------
Relative or absolute path | Write or append audit entries to the target file
`stdout` | Streams audit data to `stdout` on the Vault server
`discard` | Discards audit output instead of writing to a device
**Example**: `file_path='/logs/kv-audit.log'`

9
website/content/partials/cli/audit/args/file/mode.mdx Normal file
View File

@@ -0,0 +1,9 @@
<a id="audit-file-mode" />
**`mode (string : "0600")`**
The `chmod`-style octal permissions for the audit file. Set `mode` to "0000" to
prevent Vault from modifying the file mode.
**Example**: `mode="0755"`

9
website/content/partials/cli/audit/args/socket/address.mdx Normal file
View File

@@ -0,0 +1,9 @@
<a id="audit-socket-address" />
**`address (string : "")`**
Location of the socket as a server IP and port or a local path.
**Example**: `address="/tmp/audit.sock"`

12
website/content/partials/cli/audit/args/socket/socket_type.mdx Normal file
View File

@@ -0,0 +1,12 @@
<a id="audit-socket-socket_type" />
**`socket_type (string : "tcp")`**
Communication protocol expected by the socket. Vault can write to any
[net.Dialer](https://pkg.go.dev/net#Dialer)-compatible socket. If a TCP socket
stops responding, Vault may become unresponsive due to a
[blocked audit device error](/vault/docs/audit#blocked-audit-devices).
**Example**: `socket_type="udp"`

10
website/content/partials/cli/audit/args/socket/write_timeout.mdx Normal file
View File

@@ -0,0 +1,10 @@
<a id="audit-socket-write_timeout" />
**`write_timeout (string : "2s")`**
Duration in seconds that Vault will wait for a write to complete over the
socket. Setting `write_timeout` to `0` disables time outs and forces Vault to
always wait until the write completes.
**Example**: `write_timeout=0`

9
website/content/partials/cli/audit/args/syslog/facility.mdx Normal file
View File

@@ -0,0 +1,9 @@
<a id="audit-syslog-facility" />
**`facility (string : "AUTH")`**
The process that generated the syslog entry (the syslog facility).
**Example**: `facility="AUTO-AUTH"`

8
website/content/partials/cli/audit/args/syslog/tag.mdx Normal file
View File

@@ -0,0 +1,8 @@
<a id="audit-syslog-tag" />
**`tag (string : "vault")`**
The program that generated the syslog entry.
**Example**: `tag="vault-agent"`

7
website/content/partials/cli/audit/flags/description.mdx Normal file
View File

@@ -0,0 +1,7 @@
<a id="audit-flag-description" />
**`-description (string : "")`**
A human-friendly string that explains the purpose of the audit device.
**Example**: `-description "KV request auditing"`

8
website/content/partials/cli/audit/flags/detailed.mdx Normal file
View File

@@ -0,0 +1,8 @@
<a id="audit-flag-detailed" />
**`-detailed (bool : false)`**
Print detailed information such as options and replication status about each
audit device.
**Example**: `-detailed`

8
website/content/partials/cli/audit/flags/local.mdx Normal file
View File

@@ -0,0 +1,8 @@
<a id="audit-flag-local" />
**`-local (bool : false)`**
Indicates that the audit device is local to the Vault server and ignored by
replication.
**Example**: `-local`

8
website/content/partials/cli/audit/flags/path.mdx Normal file
View File

@@ -0,0 +1,8 @@
<a id="audit-flag-path" />
**`-path (string : "/<device_type>")`**
The internal path where Vault will access the audit device. Audit device paths
must be unique across all audit devices.
**Example**: `-path "/audit/kv-file"`

11
website/content/partials/cli/audit/options/elide_list_responses.mdx Normal file
View File

@@ -0,0 +1,11 @@
<a id="audit-elide_list_responses" />
**`elide_list_responses (bool : false)`**
Replace the details for `response.data.keys` and `response.data.key_info` with
the number of entries to reduce the size of audit records. See
[Eliding list response bodies](/vault/docs/audit#eliding-list-response-bodies)
for more details.
**Example**: `elide_list_responses=true`

21
website/content/partials/cli/audit/options/exclude.mdx Normal file
View File

@@ -0,0 +1,21 @@
<a id="audit-exclude" />
**`exclude (string : "")`** <EnterpriseAlert inline="true" />
Remove any fields matching the provided
[exclusion filtering rules](/vault/docs/enterprise/audit/exclusion) from the
audit entry before writing to the audit device.
**Example**: `exclude='[{ "condition": "/request/mount_type" == transit", "fields": [ "request/data" ] }]'`
<Tip>
Write your exclude rules to a JSON file and use `@` notation to pass the rule
definitions to `exclude`:
```
$ vault audit enable exclude=@rules.json file file_path="/var/logs/vault/audit.log"'
```
</Tip>

9
website/content/partials/cli/audit/options/fallback.mdx Normal file
View File

@@ -0,0 +1,9 @@
<a id="audit-fallback" />
**`fallback (bool : false)`** <EnterpriseAlert inline="true" />
The audit device is the fallback for filtering purposes.
**Vault only supports one fallback audit device at a time**.
**Example**: `fallback=true`

10
website/content/partials/cli/audit/options/filter.mdx Normal file
View File

@@ -0,0 +1,10 @@
<a id="audit-filter" />
**`filter (string : "")`** <EnterpriseAlert inline="true" />
Only write audit log entries matching the provided
[filtering expression](/vault/docs/enterprise/audit/filtering) to the audit
device.
**Example**: `filter='mount_type == "kv-v2"'`

13
website/content/partials/cli/audit/options/format.mdx Normal file
View File

@@ -0,0 +1,13 @@
<a id="audit-format" />
**`format (enum : json)`**
Write audit log entries in the provided format.
Enum | Description
------- | -----------
`json` | Structure audit entries as JSON data
`jsonx` | Structure audit entries as XML data
**Example**: `format=jsonx`

8
website/content/partials/cli/audit/options/hmac_accessor.mdx Normal file
View File

@@ -0,0 +1,8 @@
<a id="audit-hmac_accessor" />
**`hmac_accessor (bool : true)`**
Hash all token accessor data before writing to the audit device.
**Example**: `hmac_accessor=false`

8
website/content/partials/cli/audit/options/log_raw.mdx Normal file
View File

@@ -0,0 +1,8 @@
<a id="audit-log_raw" />
**`log_raw (bool : false)`**
Hash all sensitive security information before writing to the audit device.
**Example**: `log_raw=true`

8
website/content/partials/cli/audit/options/prefix.mdx Normal file
View File

@@ -0,0 +1,8 @@
<a id="audit-prefix" />
**`prefix (string : "")`**
Prepend the provided string to each log entry when writing to the audit device.
**Example**: `prefix="KV Request :: "`

105
website/content/partials/cli/standard-settings/all-env-variables.mdx Normal file
View File

@@ -0,0 +1,105 @@
@include 'cli/standard-settings/both/address.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/both/agent-address.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/both/ca-cert.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/both/ca-path.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/env/cli_no_color.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/both/client-cert.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/both/client-key.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/env/client_timeout.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/env/cluster_addr.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/both/disable-redirects.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/both/format.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/env/http_proxy.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/env/license_path.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/env/license.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/env/log_level.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/env/max_retries.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/both/mfa.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/both/namespace.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/env/proxy_addr.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/env/rate_limit.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/env/redirect_addr.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/env/skip_verify.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/env/srv_lookup.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/both/tls-server-name.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/both/tls-skip-verify.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/env/token.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/both/wrap-ttl.mdx'

69
website/content/partials/cli/standard-settings/all-standard-flags-but-format.mdx Normal file
View File

@@ -0,0 +1,69 @@
@include 'cli/standard-settings/both/address.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/both/agent-address.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/both/ca-cert.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/both/ca-path.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/both/client-cert.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/both/client-key.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/both/disable-redirects.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/flags/header.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/both/mfa.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/both/namespace.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/flags/non-interactive.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/flags/output-curl-string.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/flags/output-policy.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/flags/policy-override.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/both/tls-server-name.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/both/tls-skip-verify.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/flags/unlock-key.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/both/wrap-ttl.mdx'

73
website/content/partials/cli/standard-settings/all-standard-flags.mdx Normal file
View File

@@ -0,0 +1,73 @@
@include 'cli/standard-settings/both/address.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/both/agent-address.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/both/ca-cert.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/both/ca-path.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/both/client-cert.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/both/client-key.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/both/disable-redirects.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/both/format.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/flags/header.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/both/mfa.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/both/namespace.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/flags/non-interactive.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/flags/output-curl-string.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/flags/output-policy.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/flags/policy-override.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/both/tls-server-name.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/both/tls-skip-verify.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/flags/unlock-key.mdx'
<br /><hr /><br />
@include 'cli/standard-settings/both/wrap-ttl.mdx'

11
website/content/partials/cli/standard-settings/both/address.mdx Normal file
View File

@@ -0,0 +1,11 @@
<a id="standard-address" />
**`[-address | VAULT_ADDR] (string : 'https://127.0.0.1:8200')`**
Address of the Vault server.
**Examples**:
- CLI flag: `-address "https://mydomain/vault:8200"`
- Environment variable: `export VAULT_ADDR="https://mydomain/vault:8200"`

11
website/content/partials/cli/standard-settings/both/agent-address.mdx Normal file
View File

@@ -0,0 +1,11 @@
<a id="standard-agent-address" />
**`[-agent-address | VAULT_AGENT_ADDR] (string : "")`**
Address of the Vault Agent, if used.
**Examples**:
- CLI flag: `-agent-address "https://mydomain/vault-agent:8200"`
- Environment variable: `export VAULT_AGENT_ADDR="https://mydomain/vault-agent:8200"`

12
website/content/partials/cli/standard-settings/both/ca-cert.mdx Normal file
View File

@@ -0,0 +1,12 @@
<a id="standard-ca-cert" />
**`[-ca-cert | VAULT_CA_CERT] (string : "")`**
Path to a PEM-encoded CA certificate file on the local disk. Used to verify SSL
certificates for the server. **Takes precedence over `-ca_path`**.
**Examples**:
- CLI flag: `-ca-cert "/path/to/certs/mycert.pem"`
- Environment variable: `export VAULT_CA_CERT="/path/to/certs/mycert.pem"`

12
website/content/partials/cli/standard-settings/both/ca-path.mdx Normal file
View File

@@ -0,0 +1,12 @@
<a id="standard-ca-path" />
**`[-ca-path | VAULT_CAPATH] (string : "")`**
Path to a directory with PEM-encoded CA certificate files on the local disk.
Used to verify SSL certificates for the server.
**Examples**:
- CLI flag: `-ca-path "/path/to/certs/dir"`
- Environment variable: `export VAULT_CAPATH="/path/to/certs/dir"`

13
website/content/partials/cli/standard-settings/both/client-cert.mdx Normal file
View File

@@ -0,0 +1,13 @@
<a id="standard-client-cert" />
**`[-client-cert | VAULT_CLIENT_CERT] (string : "")`**
Path to a PEM-encoded CA certificate file on the local disk. Used for TLS
communication with the server. **The specified certificate must match to the
private key specified with `-client-cert`**.
**Examples**:
- CLI flag: `-client-cert "/path/to/certs/mycert.pem"`
- Environment variable: `export VAULT_CLIENT_CERT="/path/to/certs/mycert.pem"`

12
website/content/partials/cli/standard-settings/both/client-key.mdx Normal file
View File

@@ -0,0 +1,12 @@
<a id="standard-client-key" />
**`[-client-key | VAULT_CLIENT_KEY] (string : "")`**
Path to a PEM-encoded private key that matches the client certificate set with
`-client-cert`.
**Examples**:
- CLI flag: `-client-key "/path/to/keys/myprivatekey.pem"`
- Environment variable: `export VAULT_CLIENT_KEY="/path/to/keys/myprivatekey.pem"`

21
website/content/partials/cli/standard-settings/both/disable-redirects.mdx Normal file
View File

@@ -0,0 +1,21 @@
<a id="standard-disable-redirects" />
**`[-disable-redirects | VAULT_DISABLE_REDIRECTS] (bool : false)`**
Disable the default CLI redirect behavior so the CLI honors the first redirect
response from the underlying API instead of following the full HTTP redirect
chain.
**Examples**:
- CLI flag: `-disable-redirects`
- Environment variable: `export VAULT_DISABLE_REDIRECTS=1`
<Warning>
Disabling the default redirect behavior may cause commands that redirect
requests to primary cluster notes (like `vault operator raft snapshot`) to
misbehave.
</Warning>

18
website/content/partials/cli/standard-settings/both/format.mdx Normal file
View File

@@ -0,0 +1,18 @@
<a id="standard-format" />
**`[-format | VAULT_FORMAT] (enum: json)`**
Set the CLI output format.
Value | Description
------- | -----------
`table` | Structure the response as a table
`json` | Structure the response as JSON data
`yaml` | Structure the response as YAML data
`jsonx` | Structure information as XML data
**Examples**:
- CLI flag: `-format table`
- Environment variable: `export VAULT_FORMAT=table`

23
website/content/partials/cli/standard-settings/both/mfa.mdx Normal file
View File

@@ -0,0 +1,23 @@
<a id="standard-mfa" />
**`[-mfa | VAULT_MFA] (string : "")`** <EnterpriseAlert inline="true" />
A multi-factor authentication (MFA) credential, in the format
`mfa_method_name[:key[=value]]`, that the CLI should use to authenticate to
Vault. The CLI adds MFA credentials to the `X-Vault-MFA` header when calling the
underlying API endpoint.
**Examples**:
- CLI flag: `-mfa "totp:password=12345"`
- Environment variable: `export VAULT_MFA="totp:password=12345"`
<Note>
The `VAULT_MFA` environment variable only accepts one MFA method specification
and one credential for the specified method. To supply multiple credentials or
MFA methods, use the `-mfa` CLI flag and repeat the flag as needed.
</Note>

12
website/content/partials/cli/standard-settings/both/namespace.mdx Normal file
View File

@@ -0,0 +1,12 @@
<a id="standard-namespace" />
**`[-namespace | -ns | VAULT_NAMESPACE] (string : <unset>)`**
Root namespace for the CLI command. Setting a default namespace allow relative
mount paths.
**Examples**:
- CLI flag: `-namespace "admin"`
- Environment variable: `export VAULT_NAMESPACE="admin"`

11
website/content/partials/cli/standard-settings/both/tls-server-name.mdx Normal file
View File

@@ -0,0 +1,11 @@
<a id="standard-tls-server-name" />
**`[-tls-server-name | VAULT_TLS_SERVER_NAME] (string : "")`**
Name of the SNI host for TLS handshake resolution for TLS connections to Vault.
**Examples**:
- CLI flag: `-tls-server-name "hostname.domain"`
- Environment variable: `export VAULT_TLS_SERVER_NAME="hostname.domain"`

13
website/content/partials/cli/standard-settings/both/tls-skip-verify.mdx Normal file
View File

@@ -0,0 +1,13 @@
<a id="standard-tls-skip-verify" />
**`[-tls-skip-verify | VAULT_SKIP_VERIFY] (bool : false)`**
Disable verification for all TLS certificates. **Use with caution**. Disabling
TLS certificate verification decreases the security of data transmissions to and
from the Vault server.
**Examples**:
- CLI flag: `-tls-skip-verify`
- Environment variable: `export VAULT_SKIP_VERIFY=1`

13
website/content/partials/cli/standard-settings/both/wrap-ttl.mdx Normal file
View File

@@ -0,0 +1,13 @@
<a id="standard-wrap-ttl" />
**`[-wrap-ttl | VAULT_WRAP_TTL] (string : "")`**
Default time-to-live in `<number>[s|m|h|d]` format for the Cubbyhole token used
to wrap CLI responses. You must use `vault unwrap` to view response data before
the duration expires. Leave `wrap_ttl` unset to leave CLI responses unwrapped.
**Examples**:
- CLI flag: `-wrap-ttl "5m"`
- Environment variable: `export VAULT_WRAP_TTL="5m"`

9
website/content/partials/cli/standard-settings/env/cli_no_color.mdx vendored Normal file
View File

@@ -0,0 +1,9 @@
<a id="standard-cli_no_color" />
**`VAULT_CLI_NO_COLOR (bool : true)`**
Exclude ANSI color escape sequence characters from the CLI output.
**Example**: `export VAULT_CLI_NO_COLOR=0`

9
website/content/partials/cli/standard-settings/env/client_timeout.mdx vendored Normal file
View File

@@ -0,0 +1,9 @@
<a id="standard-vault_client_timeout" />
**`VAULT_CLIENT_TIMEOUT (string : "60s")`**
Default time in `<number>[s|m|h|d]` format for the CLI to wait on a response
from Vault.
**Example**: `export VAULT_CLIENT_TIMEOUT="2m"`

9
website/content/partials/cli/standard-settings/env/cluster_addr.mdx vendored Normal file
View File

@@ -0,0 +1,9 @@
<a id="standard-vault_cluster_addr" />
**`VAULT_CLUSTER_ADDR (string : "")`**
Address of the local Vault node. Vault uses cluster addresses for
cluster-to-cluster communication when running in high-availability mode.
**Example**: `export VAULT_CLUSTER_ADDR="https://127.0.0.1:8201"`

7
website/content/partials/cli/standard-settings/env/http_proxy.mdx vendored Normal file
View File

@@ -0,0 +1,7 @@
<a id="standard-vault_http_proxy" />
**`VAULT_HTTP_PROXY (string : "")`**
Legacy alias for `VAULT_PROXY_ADDR`.

14
website/content/partials/cli/standard-settings/env/license.mdx vendored Normal file
View File

@@ -0,0 +1,14 @@
<a id="standard-vault_license" />
**`VAULT_LICENSE (string : "")`** <EnterpriseAlert inline="true" />
Vault Enterprise license string for the local server or node. `VAULT_LICENSE`
takes precedence over `VAULT_LICENSE_PATH` **and** the `license_path` parameter
in the Vault configuration file.
**Example**: `export VAULT_LICENSE="02MV4UU43BK5..."`

11
website/content/partials/cli/standard-settings/env/license_path.mdx vendored Normal file
View File

@@ -0,0 +1,11 @@
<a id="standard-vault_license_path" />
**`VAULT_LICENSE_PATH (string : "")`** <EnterpriseAlert inline="true" />
Local path to a file containing a valid Vault Enterprise license for the server
or node. `VAULT_LICENSE_PATH` takes precedence over the `license_path` parameter
in the Vault configuration file.
**Example**: `export VAULT_LICENSE_PATH=/local/path/to/vault.hclic`

16
website/content/partials/cli/standard-settings/env/log_level.mdx vendored Normal file
View File

@@ -0,0 +1,16 @@
<a id="standard-vault_log_level" />
**`VAULT_LOG_LEVEL (enum : info)`**
Default logging level for the Vault server.
Enum | Logging behavior
------- | ----------------
`trace` | Log everything including details about process flow within the server
`debug` | `info` level logging and detailed server state
`info` | `warn` level logging, server events, and general server state
`warn` | `err` level logging, deprecations, and potentially harmful events/states in the server
`err` | Log information about non-fatal errors and handled exceptions
**Example**: `export VAULT_LOG_LEVEL=debug`

14
website/content/partials/cli/standard-settings/env/max_retries.mdx vendored Normal file
View File

@@ -0,0 +1,14 @@
<a id="standard-vault_max_retries" />
**`VAULT_MAX_RETRIES (integer : 2)`**
The number of times the CLI should retry a request to the Vault server when the
CLI receives one of the following recoverable error codes:
- **`412`** - "Client consistency requirement not satisfied"
- **`5xx`** - Any server error except `501`, which Vault does not use.
To disable retrying, set `VAULT_MAX_RETRIES` to `0`.
**Example**: `export VAULT_MAX_RETRIES=5`

17
website/content/partials/cli/standard-settings/env/proxy_addr.mdx vendored Normal file
View File

@@ -0,0 +1,17 @@
<a id="standard-vault_proxy_addr" />
**`VAULT_PROXY_ADDR (string : "")`**
The HTTPS or HTTP address, including server and port, where clients can access
Vault. Setting `VAULT_HTTP_PROXY` overrides the default proxy resolution
behavior and tells Vault to ignore the following proxy-related environment
variables: `HTTP_PROXY`, `HTTPS_PROXY`, and `NO_PROXY`.
**Preferred over `VAULT_HTTP_ADDR`**.
All CLI requests resolve the specified proxy and you cannot exclude domains from
consulting the proxy server.
**Example**: `export VAULT_PROXY_ADDR="https://gohereforvault:8200"`

20
website/content/partials/cli/standard-settings/env/rate_limit.mdx vendored Normal file
View File

@@ -0,0 +1,20 @@
<a id="standard-vault_rate_limit" />
**`VAULT_RATE_LIMIT (string : unset)`**
The number of operations per second, in `rate[:burst]` format, used to throttle
requests between the CLI and the server. The `burst` value is optional and
defaults to `rate` when not specified.
Leaving `VAULT_RATE_LIMIT` unset disables request limiting.
**Example**: `export VAULT_RATE_LIMIT="10:30"`
<Tip>
The rate limit is not global and applies individually to each invocation of
the CLI. As a result, the `VAULT_RATE_LIMIT` variable is most useful when
using the Go SDK for Vault.
</Tip>

9
website/content/partials/cli/standard-settings/env/redirect_addr.mdx vendored Normal file
View File

@@ -0,0 +1,9 @@
<a id="standard-vault_redirect_addr" />
**`VAULT_REDIRECT_ADDR (string : "")`**
Local node address that listens for redirected client communication when Vault
runs in high-availability mode.
**Example**: `export VAULT_CLUSTER_ADDR="https://127.0.0.1:8201"`

17
website/content/partials/cli/standard-settings/env/skip_verify.mdx vendored Normal file
View File

@@ -0,0 +1,17 @@
<a id="standard-vault_skip_verify" />
**`VAULT_SKIP_VERIFY (bool : false)`**
Allow communication between the CLI and Vault server before verifying the
authentication certificate presented by Vault.
**Example**: `export VAULT_SKIP_VERIFY=1`
<Warning title="Not appropriate for production">
Do not use `VAULT_SKIP_VERIFY` in production. Skipping certificate
verification violates the Vault security model and voids any associated
security guarantees.
</Warning>

17
website/content/partials/cli/standard-settings/env/srv_lookup.mdx vendored Normal file
View File

@@ -0,0 +1,17 @@
<a id="standard-vault_srv_lookup" />
**`VAULT_SRV_LOOKUP (bool : false)`**
Use SRV records instead of standard DNS to look up hostnames as described in
the Network Working Group draft
["Use of SRV records in conjunction with HTTP and URIs"](https://datatracker.ietf.org/doc/html/draft-andrews-http-srv-02).
**Example**: `export VAULT_SRV_LOOKUP=1`
<Warning title="Not appropriate for production">
SRV lookup is still in discovery and not designed for high-availability
deployments.
</Warning>

10
website/content/partials/cli/standard-settings/env/token.mdx vendored Normal file
View File

@@ -0,0 +1,10 @@
<a id="standard-vault_token" />
**`VAULT_TOKEN (string : "")`**
A Vault-issued service token that authenticates the CLI user to Vault.
See the [tokens concepts page](/vault/docs/concepts/tokens) for more information
on token types.
**Example**: `export VAULT_TOKEN="hvs.CvmS4c0DPTvHv5eJgXWMJg9r"`

10
website/content/partials/cli/standard-settings/flags/header.mdx Normal file
View File

@@ -0,0 +1,10 @@
<a id="standard-header" />
**`-header (string : "")`**
Optional HTTP header in the form `"<key>=<value>"` for the CLI request. Repeat
the `-header` flag as needed with one string per flag. User-defined headers
cannot start with `X-Vault-`
**Example**: `-header "Cache-Control=max-age=0"`

8
website/content/partials/cli/standard-settings/flags/non-interactive.mdx Normal file
View File

@@ -0,0 +1,8 @@
<a id="standard-non-interactive" />
**`-non-interactive (bool : false)`**
Prevent the CLI from asking users for input through the terminal.
**Example**: `-non-interactive`

9
website/content/partials/cli/standard-settings/flags/output-curl-string.mdx Normal file
View File

@@ -0,0 +1,9 @@
<a id="standard-output-curl-string" />
**`-output-curl-string (bool : false)`**
Print the API call(s) required to execute the CLI command as `cURL` strings
then exit without running the command.
**Example**: `-output-curl-string`

9
website/content/partials/cli/standard-settings/flags/output-policy.mdx Normal file
View File

@@ -0,0 +1,9 @@
<a id="standard-output-policy" />
**`-output-policy (bool : false)`**
Print the Vault policy required to execute the CLI command as HCL then exit
without running the command.
**Example**: `-output-policy`

8
website/content/partials/cli/standard-settings/flags/policy-override.mdx Normal file
View File

@@ -0,0 +1,8 @@
<a id="standard-policy-override" />
**`-policy-override (bool : false)`**
Overrides any Sentinel policy where `enforcement_level` is "soft-mandatory".
**Example**: `-policy-override`

8
website/content/partials/cli/standard-settings/flags/unlock-key.mdx Normal file
View File

@@ -0,0 +1,8 @@
<a id="standard-unlock-key" />
**`-unlock-key (string : <unset>)`**
Plaintext key that unlocks the underlying API endpoint for a given namespace.
**Example**: `-unlock-key "7oXtdlmvRQ"`

24
website/data/docs-nav-data.json
View File

@@ -618,16 +618,18 @@
] ]
}, },
{ {
"title": "Commands (CLI)", "title": "Vault CLI",
"routes": [ "routes": [
{ {
"title": "Overview", "title": "Usage",
"path": "commands" "path": "commands"
}, },
{ {
"title": "Web REPL", "title": "Use a custom token helper",
"path": "commands/web" "path": "commands/token-helper"
}, },
{ "divider": true },
{ "heading": "CLI commands" },
{ {
"title": "<code>agent</code>", "title": "<code>agent</code>",
"path": "commands/agent" "path": "commands/agent"
@@ -635,10 +637,6 @@
{ {
"title": "<code>audit</code>", "title": "<code>audit</code>",
"routes": [ "routes": [
{
"title": "Overview",
"path": "commands/audit"
},
{ {
"title": "<code>disable</code>", "title": "<code>disable</code>",
"path": "commands/audit/disable" "path": "commands/audit/disable"
@@ -1130,15 +1128,11 @@
{ {
"title": "<code>write</code>", "title": "<code>write</code>",
"path": "commands/write" "path": "commands/write"
},
{
"title": "Token Helpers",
"path": "commands/token-helper"
} }
] ]
}, },
{ {
"title": "Vault UI", "title": "Vault GUI",
"routes": [ "routes": [
{ {
"title": "Overview", "title": "Overview",
@@ -1152,6 +1146,10 @@
"type": "outlined", "type": "outlined",
"color": "neutral" "color": "neutral"
} }
},
{
"title": "CLI emulation",
"path": "ui/web-cli"
} }
] ]
}, },

5
website/redirects.js
View File

@@ -129,5 +129,10 @@ module.exports = [
source: '/vault/docs/concepts/lease-count-quota-exceeded', source: '/vault/docs/concepts/lease-count-quota-exceeded',
destination: '/vault/docs/troubleshoot/lease-count-quota-exceeded', destination: '/vault/docs/troubleshoot/lease-count-quota-exceeded',
permanent: true, permanent: true,
},
{
source: '/vault/docs/command/web',
destination: '/vault/docs/ui/web-cli',
permanent: true,
} }
] ]