Add HTTPS/RPC/gossip encryption and setup script

[tjcelaya]

Attempts to resolve #49 by emulating and expanding upon the pattern used in autopilotpattern/vault.

Needs to be rebased once #48 is merged.

Summary

CONSUL_TLS_PATH specifies a directory that will be created which is used to sideload certs and key material. We can't reuse CONSUL_CACERT, CONSUL_CLIENT_CERT, CONSUL_CLIENT_KEY because ContainerPilot would expect the files to exist as soon as it started up and terminates immediately if they're missing. We can elect to surface these to ContainerPilot and trigger a reload, but it doesn't need the certificates and key since it'll be connecting to the unencrypted http port that's bound to a private address.

Instead, the preStart job blocks until the files are injected and sets Consul CONSUL_CACERT, CONSUL_CLIENT_CERT, CONSUL_CLIENT_KEY values in the configuration file. It is possible to use containerpilot -putenv if configuring ContainerPilot to use the encrypted connection is desired, but this doesn't seem necessary given the private listening address used for plain http. Keeping the automated Consul configuration we apply in the config makes it easy to inspect and debug.

preStop has been updated to skip consul leave if consul info fails. This was part of eliminating a warning that occurred previously while I was calling containerpilot -reload but is slightly irrelevant now. On the other hand, it does make some sense to only try to leave if you were registered in the first place, so I'm tempted to leave this in.

The README updates should provide all the necessary context, but things have shifted around enough that they might be slightly inaccurate, please let me know if anything seems off!

To make it easier for users to generate certificates the process described in this blogpost referenced from Consul's encryption docs has been compressed into ca/Dockerfile.

setup-encryption.sh provides three commands:

• build: uses the Dockerfile in the ca directory to build a CA container
• generate: invokes the CA container to generate a self-signed certificate, a gossip key, or both
• upload: installs certificates using docker cp

Additional notes

examples/triton/setup.sh and examples/triton/setup-multi-dc.sh now accept -t/--tls-path and -g/--gossip-path parameters for setting the expected cert directory and injecting the gossip secret key respectively. setup.sh has also been modified to accept ./setup.sh -h since ./setup.sh help seems unintuitive

The ca folder contains a really crude translation of the above-mentioned blogpost as a Docker container. Volume-mounting the /ssl folder in that container seems like a good idea to prevent losing CA state. I've been told having an intermediate CA cert would make things easier to manage, but my experience with certs is limited so I'll be delaying this improvement until testing is complete with the current super-minimalist certificate chain.

The upload command can be used to inject arbitrary files into running containers. This decoupling allows users to bring in their own certs as desired by ignoring the first two commands, but it also presents a security risk if not used carefully. Advice for how to make this more intuitive and secure is welcome.

[tjcelaya]

Testing reveals that we're missing a verify_* setting. I can bring up a cluster and see gossip and TLS encryption are all true but the cluster still responds to queries even for unconfigured agents.

See updated description above.

[jwreagor]

Just checking in, sounds like this is still being worked on?

[tjcelaya]

Yup, I'm going to rebase today and figure out what's left for testing. I'll reach out for an actual review once this is back on track.