Encrypt and authenticate communication between nodes

[mattbostock]

While we can reasonably expect a user to configure a reverse HTTP proxy to add encryption and authentication between client and server, doing so for internal communication between nodes in a cluster could be a considered an unnecessary operational burden.

The aim of this issue is to determine how to best secure internal communication while avoiding:

• making it difficult for people wishing to try out the database
• making it difficult to develop and test the database
• adding a plethora of configuration options

The solution should be simple.

Some background reading:

• Why Varnish doesn't support SSL
• Why Prometheus doesn't support TLS
• How etcd implements secure communication
• How Serf implements secure communication
• How Riak implements secure communication

[mattbostock]

I considered using TLS with a pre-shared key for encryption, which would be relatively simple to configure.

The Go TLS library does not yet support TLS-PSK, however.

[mattbostock]

There are a lot of good reverse proxies that do TLS termination well and I don't want to complicate the codebase with configuration for TLS. For example:

• some folks may want to use client authentication
• some folks may want to use LetsEncrypt
• support for TLS needs additional configuration and associated tests

I think a better solution is for users to use a sidecar proxy such as Envoy or Nginx Unit which can handle TLS on behalf of Timbala.

Remaining tasks left before this can be closed:

• Document this decision
• Raise an issue to add example config for using Timbala with Envoy/Istio