TLS Terminated Etcd (If you use etcd this affects you)
Charles Butler
charles.butler at canonical.com
Tue Jun 14 14:50:20 UTC 2016
Greetings,
TL;DR - If you have the time, are not listed in the grouping of
applications below, and are using etcd in your deployment - this effects
you and I *need* to hear from you!
I've been cycling the last few weeks on revamping the Etcd charm
<https://github.com/juju-solutions/layer-etcd> (a golang single binary
key/value store). One of the newest *enforced* features is TLS (provided by
layer-tls <https://github.com/juju-solutions/layer-tls>) Terminated
endpoints for end to end encryption of a production ready Kubernetes
deployment.
Normally this would be just a bullet point in a release bulletin email,
however this time around I want to ping the community before we push the
latest revision to a stable channel due to the following concerns:
- TLS is enabled/enforced by default (with strict client key/server key
validation)
- There is currently no way to disable TLS wrapped endpoints on Etcd (we
want to keep our coordination data secure don't we?)
- End users now have to use TLS certificates to communicate with Etcd
(available from a convenient action / scp command)
- This will break compatibility with existing deployments unless supporting
charms are built with the latest 'etcd' interface, and this is not 100%
crystal clear which charms have been updated - without releasing a new
bundle... and this only helps new deployments. Existing deployments will
require a bit more finesse in ensuring the related charms around Etcd have
been upgraded *prior* to the new etcd upgrade.
We did make the interface <https://github.com/juju-solutions/interface-etcd>
backward compatible, so anyone building the Etcd charm can use either
communication path. However the layer itself is not engineered in such a
way that the TLS certificates can be toggled. If If the community at large
has a need for a non-tls wrapped Etcd, I'd like to hear now, so we are
spending the engineering effort wisely. I'd like to support it, but not
without empirical evidence that it is required.* Secure by default* sounds
like a great place for us to be, but not at the expense of our community
members.
As best I can tell, this only effects the following projects:
- Calico (critical path)
- Kubernetes (critical path)
- Swarm (optional path)
Thank you for your time, and all the best,
--
Juju Charmer
Canonical Group Ltd.
Ubuntu - Linux for human beings | www.ubuntu.com
Juju - The fastest way to model your service | www.jujucharms.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20160614/f46d192b/attachment.html>
More information about the Juju
mailing list