update docs and help text to include 'operator' (#4712)
This commit is contained in:
parent
058b4e0a5f
commit
284600fbef
@ -367,7 +367,7 @@ func (c *OperatorGenerateRootCommand) provide(client *api.Client, key string, dr
|
||||
if !status.Started {
|
||||
c.UI.Error(wrapAtLength(
|
||||
"No root generation is in progress. Start a root generation by " +
|
||||
"running \"vault generate-root -init\"."))
|
||||
"running \"vault operator generate-root -init\"."))
|
||||
return 1
|
||||
}
|
||||
|
||||
|
@ -408,7 +408,7 @@ func (c *OperatorInitCommand) consulAuto(client *api.Client, req *api.InitReques
|
||||
c.UI.Output(wrapAtLength(fmt.Sprintf(
|
||||
"Discovered %d uninitialized Vault servers with Consul service name "+
|
||||
"%q. To initialize these Vaults, set any one of the following "+
|
||||
"environment variables and run \"vault init\":",
|
||||
"environment variables and run \"vault operator init\":",
|
||||
len(uninitedVaults), c.flagConsulService)))
|
||||
c.UI.Output("")
|
||||
|
||||
@ -481,8 +481,8 @@ func (c *OperatorInitCommand) init(client *api.Client, req *api.InitRequest) int
|
||||
c.UI.Output("")
|
||||
c.UI.Output(wrapAtLength(
|
||||
"It is possible to generate new unseal keys, provided you have a quorum " +
|
||||
"of existing unseal keys shares. See \"vault rekey\" for more " +
|
||||
"information."))
|
||||
"of existing unseal keys shares. See \"vault operator rekey\" for " +
|
||||
"more information."))
|
||||
} else {
|
||||
c.UI.Output("")
|
||||
c.UI.Output("Success! Vault is initialized")
|
||||
|
@ -52,7 +52,7 @@ func (c *OperatorRekeyCommand) Synopsis() string {
|
||||
|
||||
func (c *OperatorRekeyCommand) Help() string {
|
||||
helpText := `
|
||||
Usage: vault rekey [options] [KEY]
|
||||
Usage: vault operator rekey [options] [KEY]
|
||||
|
||||
Generates a new set of unseal keys. This can optionally change the total
|
||||
number of key shares or the required threshold of those key shares to
|
||||
@ -491,7 +491,7 @@ func (c *OperatorRekeyCommand) provide(client *api.Client, key string) int {
|
||||
if !started {
|
||||
c.UI.Error(wrapAtLength(
|
||||
"No rekey is in progress. Start a rekey process by running " +
|
||||
"\"vault rekey -init\"."))
|
||||
"\"vault operator rekey -init\"."))
|
||||
return 1
|
||||
}
|
||||
|
||||
@ -758,8 +758,8 @@ func (c *OperatorRekeyCommand) printUnsealKeys(client *api.Client, status *api.R
|
||||
c.UI.Output(wrapAtLength(fmt.Sprintf(
|
||||
"The encrypted unseal keys are backed up to \"core/unseal-keys-backup\"" +
|
||||
"in the storage backend. Remove these keys at any time using " +
|
||||
"\"vault rekey -delete-backup\". Vault does not automatically remove " +
|
||||
"these keys.",
|
||||
"\"vault operator rekey -delete-backup\". Vault does not automatically " +
|
||||
"remove these keys.",
|
||||
)))
|
||||
}
|
||||
|
||||
|
@ -21,7 +21,7 @@ func (c *OperatorSealCommand) Synopsis() string {
|
||||
|
||||
func (c *OperatorSealCommand) Help() string {
|
||||
helpText := `
|
||||
Usage: vault seal [options]
|
||||
Usage: vault operator seal [options]
|
||||
|
||||
Seals the Vault server. Sealing tells the Vault server to stop responding
|
||||
to any operations until it is unsealed. When sealed, the Vault server
|
||||
|
@ -21,7 +21,7 @@ func (c *OperatorRotateCommand) Synopsis() string {
|
||||
|
||||
func (c *OperatorRotateCommand) Help() string {
|
||||
helpText := `
|
||||
Usage: vault rotate [options]
|
||||
Usage: vault operator rotate [options]
|
||||
|
||||
Rotates the underlying encryption key which is used to secure data written
|
||||
to the storage backend. This installs a new key in the key ring. This new
|
||||
@ -34,7 +34,7 @@ Usage: vault rotate [options]
|
||||
|
||||
Rotate Vault's encryption key:
|
||||
|
||||
$ vault rotate
|
||||
$ vault operator rotate
|
||||
|
||||
For a full list of examples, please see the documentation.
|
||||
|
||||
|
@ -108,9 +108,9 @@ Usage: vault server [options]
|
||||
|
||||
This command starts a Vault server that responds to API requests. By default,
|
||||
Vault will start in a "sealed" state. The Vault cluster must be initialized
|
||||
before use, usually by the "vault init" command. Each Vault server must also
|
||||
be unsealed using the "vault unseal" command or the API before the server can
|
||||
respond to requests.
|
||||
before use, usually by the "vault operator init" command. Each Vault server must
|
||||
also be unsealed using the "vault operator unseal" command or the API before the
|
||||
server can respond to requests.
|
||||
|
||||
Start a server with a configuration file:
|
||||
|
||||
|
@ -24,8 +24,8 @@ in-memory). It is only made for development or experimentation.
|
||||
The properties of the dev server:
|
||||
|
||||
* **Initialized and unsealed** - The server will be automatically initialized
|
||||
and unsealed. You don't need to use `vault unseal`. It is ready for use
|
||||
immediately.
|
||||
and unsealed. You don't need to use `vault operator unseal`. It is ready
|
||||
for use immediately.
|
||||
|
||||
* **In-memory storage** - All data is stored (encrypted) in-memory. Vault
|
||||
server doesn't require any file permissions.
|
||||
|
@ -51,7 +51,7 @@ To generate unseal keys for Keybase users, Vault accepts the `keybase:` prefix
|
||||
to the `-pgp-keys` argument:
|
||||
|
||||
```
|
||||
$ vault init -key-shares=3 -key-threshold=2 \
|
||||
$ vault operator init -key-shares=3 -key-threshold=2 \
|
||||
-pgp-keys="keybase:jefferai,keybase:vishalnayak,keybase:sethvargo"
|
||||
```
|
||||
|
||||
@ -100,7 +100,7 @@ This is your unseal key in plain-text and should be guarded the same way you
|
||||
guard a password. Now you can enter your key to the `unseal` command:
|
||||
|
||||
```
|
||||
$ vault unseal
|
||||
$ vault operator unseal
|
||||
Key (will be hidden): ...
|
||||
```
|
||||
|
||||
@ -135,7 +135,7 @@ without ASCII armoring) or binary. Once saved to disk, the path to these files
|
||||
can be specified as an argument to the `-pgp-keys` flag.
|
||||
|
||||
```
|
||||
$ vault init -key-shares=3 -key-threshold=2 \
|
||||
$ vault operator init -key-shares=3 -key-threshold=2 \
|
||||
-pgp-keys="jeff.asc,vishal.asc,seth.asc"
|
||||
```
|
||||
|
||||
@ -180,6 +180,6 @@ This is your unseal key in plain-text and should be guarded the same way you
|
||||
guard a password. Now you can enter your key to the `unseal` command:
|
||||
|
||||
```
|
||||
$ vault unseal
|
||||
$ vault operator unseal
|
||||
Key (will be hidden): ...
|
||||
```
|
||||
|
@ -43,7 +43,7 @@ decrypt the data.
|
||||
|
||||
## Unsealing
|
||||
|
||||
The unseal process is done by running `vault unseal` or via the API.
|
||||
The unseal process is done by running `vault operator unseal` or via the API.
|
||||
This process is stateful: each key can be entered via multiple mechanisms
|
||||
on multiple computers and it will work. This allows each shard of the master
|
||||
key to be on a distinct machine for better security.
|
||||
|
@ -13,7 +13,7 @@ can be used directly or [auth methods](/docs/concepts/auth.html)
|
||||
can be used to dynamically generate tokens based on external identities.
|
||||
|
||||
If you've gone through the getting started guide, you probably noticed that
|
||||
`vault server -dev` (or `vault init` for a non-dev server) outputs an
|
||||
`vault server -dev` (or `vault operator init` for a non-dev server) outputs an
|
||||
initial "root token." This is the first method of authentication for Vault.
|
||||
It is also the only auth method that cannot be disabled.
|
||||
|
||||
@ -50,7 +50,7 @@ type of token within Vault that can be set to never expire without any renewal
|
||||
needed. As a result, it is purposefully hard to create root tokens; in fact, as
|
||||
of version 0.6.1, there are only three ways to create root tokens:
|
||||
|
||||
1. The initial root token generated at `vault init` time -- this token has no
|
||||
1. The initial root token generated at `vault operator init` time -- this token has no
|
||||
expiration
|
||||
2. By using another root token; a root token with an expiration cannot create a
|
||||
root token that never expires
|
||||
|
@ -191,17 +191,17 @@ nature of the algorithm, Vault doesn't know if it has the _correct_ key until
|
||||
the threshold is reached.
|
||||
|
||||
Also notice that the unseal process is stateful. You can go to another computer,
|
||||
use `vault unseal`, and as long as it's pointing to the same server, that other
|
||||
computer can continue the unseal process. This is incredibly important to the
|
||||
design of the unseal process: multiple people with multiple keys are required to
|
||||
unseal the Vault. The Vault can be unsealed from multiple computers and the keys
|
||||
should never be together. A single malicious operator does not have enough keys
|
||||
to be malicious.
|
||||
use `vault operator unseal`, and as long as it's pointing to the same server,
|
||||
that other computer can continue the unseal process. This is incredibly
|
||||
important to the design of the unseal process: multiple people with multiple
|
||||
keys are required to unseal the Vault. The Vault can be unsealed from multiple
|
||||
computers and the keys should never be together. A single malicious operator
|
||||
does not have enough keys to be malicious.
|
||||
|
||||
Continue with `vault unseal` to complete unsealing the Vault. To unseal the
|
||||
vault you must use three _different_ keys, the same key repeated will not work.
|
||||
As you use keys, as long as they are correct, you should soon see output like
|
||||
this:
|
||||
Continue with `vault operator unseal` to complete unsealing the Vault. To unseal
|
||||
the vault you must use three _different_ keys, the same key repeated will not
|
||||
work. As you use keys, as long as they are correct, you should soon see output
|
||||
like this:
|
||||
|
||||
```text
|
||||
$ vault operator unseal
|
||||
@ -249,9 +249,9 @@ token_renewable false
|
||||
token_policies [root]
|
||||
```
|
||||
|
||||
As a root user, you can reseal the Vault with `vault seal`. A single operator is
|
||||
allowed to do this. This lets a single operator lock down the Vault in an
|
||||
emergency without consulting other operators.
|
||||
As a root user, you can reseal the Vault with `vault operator seal`. A single
|
||||
operator is allowed to do this. This lets a single operator lock down the
|
||||
Vault in an emergency without consulting other operators.
|
||||
|
||||
When the Vault is sealed again, it clears all of its state (including the
|
||||
encryption key) from memory. The Vault is secure and locked down from access.
|
||||
|
Loading…
Reference in New Issue
Block a user