2014-09-11 18:19:48 +00:00
|
|
|
---
|
|
|
|
|
layout: "docs"
|
2014-09-13 03:08:54 +00:00
|
|
|
page_title: "Commands: Keyring"
|
|
|
|
|
sidebar_current: "docs-commands-keyring"
|
2014-09-11 18:19:48 +00:00
|
|
|
---
|
|
|
|
|
|
2014-09-13 03:08:54 +00:00
|
|
|
# Consul Keyring
|
2014-09-11 18:19:48 +00:00
|
|
|
|
2014-09-13 03:08:54 +00:00
|
|
|
Command: `consul keyring`
|
2014-09-11 18:19:48 +00:00
|
|
|
|
2014-09-13 03:08:54 +00:00
|
|
|
The `keyring` command is used to examine and modify the encryption keys used in
|
2014-09-11 18:19:48 +00:00
|
|
|
Consul's [Gossip Pools](/docs/internals/gossip.html). It is capable of
|
2014-09-19 01:57:18 +00:00
|
|
|
distributing new encryption keys to the cluster, retiring old encryption keys,
|
|
|
|
|
and changing the keys used by the cluster to encrypt messages.
|
2014-09-11 18:19:48 +00:00
|
|
|
|
|
|
|
|
Consul allows multiple encryption keys to be in use simultaneously. This is
|
|
|
|
|
intended to provide a transition state while the cluster converges. It is the
|
|
|
|
|
responsibility of the operator to ensure that only the required encryption keys
|
2014-10-01 00:31:16 +00:00
|
|
|
are installed on the cluster. You can review the installed keys using the
|
|
|
|
|
`-list` argument, and remove unneeded keys with `-remove`.
|
2014-09-11 18:19:48 +00:00
|
|
|
|
2014-10-03 05:05:00 +00:00
|
|
|
All operations performed by this command can only be run against server nodes,
|
|
|
|
|
and affect both the LAN and WAN keyrings in lock-step.
|
2014-09-30 22:31:07 +00:00
|
|
|
|
2014-10-03 05:05:00 +00:00
|
|
|
All variations of the `keyring` command return 0 if all nodes reply and there
|
|
|
|
|
are no errors. If any node fails to reply or reports failure, the exit code
|
|
|
|
|
will be 1.
|
2014-09-11 18:19:48 +00:00
|
|
|
|
|
|
|
|
## Usage
|
|
|
|
|
|
2014-09-13 03:08:54 +00:00
|
|
|
Usage: `consul keyring [options]`
|
2014-09-11 18:19:48 +00:00
|
|
|
|
2014-10-03 05:05:00 +00:00
|
|
|
Only one actionable argument may be specified per run, including `-list`,
|
|
|
|
|
`-install`, `-remove`, and `-use`.
|
2014-09-11 18:19:48 +00:00
|
|
|
|
|
|
|
|
The list of available flags are:
|
|
|
|
|
|
2014-10-03 05:05:00 +00:00
|
|
|
* `-list` - List all keys currently in use within the cluster.
|
2014-09-19 01:57:18 +00:00
|
|
|
|
2014-09-11 18:19:48 +00:00
|
|
|
* `-install` - Install a new encryption key. This will broadcast the new key to
|
|
|
|
|
all members in the cluster.
|
|
|
|
|
|
|
|
|
|
* `-use` - Change the primary encryption key, which is used to encrypt messages.
|
|
|
|
|
The key must already be installed before this operation can succeed.
|
|
|
|
|
|
|
|
|
|
* `-remove` - Remove the given key from the cluster. This operation may only be
|
|
|
|
|
performed on keys which are not currently the primary key.
|
|
|
|
|
|
2016-09-23 23:00:05 +00:00
|
|
|
* `-token=""` - ACL token to use during requests. Defaults to that of the agent.
|
|
|
|
|
|
2017-02-02 02:42:41 +00:00
|
|
|
* `-relay-factor` - Added in Consul 0.7.4, setting this to a non-zero value will
|
|
|
|
|
cause nodes to relay their response to the operation through this many
|
|
|
|
|
randomly-chosen other nodes in the cluster. The maximum allowed value is 5.
|
|
|
|
|
|
2014-12-15 18:16:43 +00:00
|
|
|
* `-rpc-addr` - Address to the RPC server of the agent you want to contact
|
|
|
|
|
to send this command. If this isn't specified, the command will contact
|
|
|
|
|
"127.0.0.1:8400" which is the default RPC address of a Consul agent.
|
2014-10-01 00:31:16 +00:00
|
|
|
|
|
|
|
|
## Output
|
|
|
|
|
|
|
|
|
|
The output of the `consul keyring -list` command consolidates information from
|
|
|
|
|
all nodes and all datacenters to provide a simple and easy to understand view of
|
|
|
|
|
the cluster. The following is some example output from a cluster with two
|
|
|
|
|
datacenters, each which consist of one server and one client:
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
==> Gathering installed encryption keys...
|
|
|
|
|
==> Done!
|
|
|
|
|
|
|
|
|
|
WAN:
|
|
|
|
|
a1i101sMY8rxB+0eAKD/gw== [2/2]
|
|
|
|
|
|
|
|
|
|
dc2 (LAN):
|
|
|
|
|
a1i101sMY8rxB+0eAKD/gw== [2/2]
|
|
|
|
|
|
|
|
|
|
dc1 (LAN):
|
|
|
|
|
a1i101sMY8rxB+0eAKD/gw== [2/2]
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
As you can see, the output above is divided first by gossip pool, and then by
|
|
|
|
|
encryption key. The indicator to the right of each key displays the number of
|
|
|
|
|
nodes the key is installed on over the total number of nodes in the pool.
|
|
|
|
|
|
|
|
|
|
## Errors
|
|
|
|
|
|
|
|
|
|
If any errors are encountered while performing a keyring operation, no key
|
|
|
|
|
information is displayed, but instead only error information. The error
|
|
|
|
|
information is arranged in a similar fashion, organized first by datacenter,
|
|
|
|
|
followed by a simple list of nodes which had errors, and the actual text of the
|
|
|
|
|
error. Below is sample output from the same cluster as above, if we try to do
|
|
|
|
|
something that causes an error; in this case, trying to remove the primary key:
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
==> Removing gossip encryption key...
|
|
|
|
|
|
|
|
|
|
dc1 (LAN) error: 2/2 nodes reported failure
|
|
|
|
|
server1: Removing the primary key is not allowed
|
|
|
|
|
client1: Removing the primary key is not allowed
|
|
|
|
|
|
|
|
|
|
WAN error: 2/2 nodes reported failure
|
|
|
|
|
server1.dc1: Removing the primary key is not allowed
|
|
|
|
|
server2.dc2: Removing the primary key is not allowed
|
|
|
|
|
|
|
|
|
|
dc2 (LAN) error: 2/2 nodes reported failure
|
|
|
|
|
server2: Removing the primary key is not allowed
|
|
|
|
|
client2: Removing the primary key is not allowed
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
As you can see, each node with a failure reported what went wrong.
|
