Etcd: Why can't peer-to-peer traffic use a simple symmetric key?

Created on 23 Mar 2018 · 10Comments · Source: etcd-io/etcd

Looking through the etc security model documentation, I sort of wonder why TLS was chosen to create secure peer-to-peer connectivity. We now need to create a CA, per-node keys and certificates.

As the subject of this issue says: why can't we simply use a single cluster-wide symmetric key to encrypt all peer-to-peer traffic?

arefeature aresecurity aretls

Source

EdSchouten

👍1

Most helpful comment

@hexfusion @EdSchouten If I understand this use case correctly, have you tried --peer-cert-allowed-cn?

When --peer-cert-allowed-cn flag is specified, node can only join with matching common name even with shared CAs. So you can create a cluster-wide certs and limit access with your own common name field.

gyuho on 23 Mar 2018

👍2

All 10 comments

a single cluster-wide symmetric key

How would this support dynamic cluster reconfiguration?

gyuho on 23 Mar 2018

We now need to create a CA, per-node keys and certificates.

Depending on use case it is worth noting that --peer-auto-tls does not require any file generation.

hexfusion on 23 Mar 2018

Exactly. There is --peer-auto-tls, but according to the documentation, this does not provide any authentication. It's only there to add encryption.

With regards to dynamic cluster reconfiguration, there shouldn't be any difference there, right? You just need to make sure that all nodes that are added to the cluster later on use the same symmetric key. Due to symmetric keys being relatively small in size (hundreds of bits), there could be a command line flag --peer-shared-secret S0m3Str1ngTh4tN0b0dyC4nGuess.

EdSchouten on 23 Mar 2018

👍1

Perhaps we _could_ reopen https://github.com/coreos/etcd/issues/8248. ? It seems like we have the foundation to support this same general idea if you are interested in helping @EdSchouten maybe we can move this along? I think because we have TLS already adding this currently is a nice to have feature, thus not a priority.

hexfusion on 23 Mar 2018

@hexfusion @EdSchouten If I understand this use case correctly, have you tried --peer-cert-allowed-cn?

gyuho on 23 Mar 2018

👍2

@EdSchouten Ping?

gyuho on 2 Apr 2018

Hi @gyuho,

Sorry for leaving you waiting. I just came back from a business trip to extinguish some fires that was planned on short notice; pure madness.

I just looked at the --peer-cert-allowed-cn flag and it looks like something that could be perfect for us. Let me give it a try tomorrow and report back to you whether that works for us. Thanks!

EdSchouten on 3 Apr 2018

@EdSchouten No problem! And please let us know. Thanks.

gyuho on 3 Apr 2018

I just gave --peer-cert-allowed-cn a try and it looks like that flag is only useful for specifying the hostname of the client certificate to validate. It still requires us to have a certificate with a bunch of SANs for every node to keep the TLS client happy when making outgoing connections to peers.

We've decided to give in for now and generate one certificate per system and have a common CA. It still feels like it's more complicated than strictly needed. A single shared key would have been sufficient.

Edit: I did some more Googling and stumbled upon TLS-PSK (TLS with a pre-shared key). This would have been ideal for our use case, but unfortunately it's not supported by Golang yet.

EdSchouten on 4 Apr 2018

@EdSchouten it seems like you guys have this under control now? Closing this for now, please let us know if this is still a required feature, thanks!