From f02ae3104119a02394a4634f5eeb4c7ee452f343 Mon Sep 17 00:00:00 2001 From: Armon Dadgar Date: Mon, 7 Apr 2014 15:06:26 -0700 Subject: [PATCH] website: More info on TLS encryption --- .gitignore | 5 ++- .../docs/agent/encryption.html.markdown | 34 +++++++++++++++++-- 2 files changed, 33 insertions(+), 6 deletions(-) diff --git a/.gitignore b/.gitignore index 547ad2481a..405017d587 100644 --- a/.gitignore +++ b/.gitignore @@ -23,7 +23,6 @@ _testmain.go *.test bin/ .vagrant/ - - website/npm-debug.log - +*.old +*.attr diff --git a/website/source/docs/agent/encryption.html.markdown b/website/source/docs/agent/encryption.html.markdown index b4c396e52f..94710b6dd7 100644 --- a/website/source/docs/agent/encryption.html.markdown +++ b/website/source/docs/agent/encryption.html.markdown @@ -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. +