luxolus
/
open-consul
2
0
Fork 0
Code Issues 1 Pull Requests Packages Releases Wiki Activity

website: More info on TLS encryption

This commit is contained in:
Armon Dadgar 2014-04-07 15:06:26 -07:00
parent c452b19267
commit 002b9018a1
2 changed files with 33 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
.gitignore vendored
View File

@ -23,7 +23,6 @@ _testmain.go
*.test
bin/
.vagrant/
website/npm-debug.log
*.old
*.attr

34
website/source/docs/agent/encryption.html.markdown
View File

@ -8,11 +8,12 @@ sidebar_current: "docs-agent-encryption"
The Consul agent supports encrypting all of its network traffic. The exact
method of this encryption is described on the
[encryption internals page](/docs/internals/security.html).
[encryption internals page](/docs/internals/security.html). There are two
seperate systems, one for gossip traffic and one for RPC.
## Enabling Encryption
## Gossip Encryption
Enabling encryption only requires that you set an encryption key when
Enabling gossip encryption only requires that you set an encryption key when
starting the Consul agent. The key can be set using the `-encrypt` flag
on `consul agent` or by setting the `encrypt_key` in a configuration file.
It is advisable to put the key in a configuration file to avoid other users
@ -47,3 +48,30 @@ $ consul agent -data=/tmp/consul -encrypt=cg8StVXbQJ0gPvMd9o7yrg==
All nodes within a Consul cluster must share the same encryption key in
order to send and receive cluster information.
# RPC Encryption with TLS
Consul supports using TLS to verify the authenticity of servers and clients. For this
to work, Consul requires that all clients and servers have key pairs that are generated
by a single Certificate Authority. This can be a private CA, used only internally. The
CA then signs keys for each of the agents. [Here](https://langui.sh/2009/01/18/openssl-self-signed-ca/)
is a tutorial on generating both a CA and signing keys using OpenSSL.
There are a number of things to consider when setting up TLS for Consul. Either we can
use TLS just to verify the authenticity of the servers, or we can also verify the authenticity
of clients. The former can be used to prevent unauthorized access. This behavior is controlled
using either the `verify_incoming` and `verify_outgoing` [options](/docs/agent/options.html).
If `verify_outgoing` is set, then agents verify the authenticity of Consuls for outgoing
connections. This means server nodes must present a certificate signed by the `ca_file` that
the agent has. This option must be set on all agents, and there must be a `ca_file` provided
to check the certificate against. If this is set, then all server nodes must have an appropriate
key pair set using `cert_file` and `key_file`.
If `verify_incoming` is set, then the servers verify the authenticity of all incoming
connections. Servers will also disallow any non-TLS connections. If this is set, then all
clients must have a valid key pair set using `cert_file` and `key_file`. To force clients to
use TLs, `verify_outgoing` must also be set.
TLS is used to secure the RPC calls between agents, but gossip between nodes is done over UDP
and is secured using a symmetric key. See above for enabling gossip encryption.