Gossip encryption and new nodes

[David Carr]

Hi,

We've got a cluster set up with TLS encryption and it's working well.  One issue we had initially was that the docs don't specify that you need to (or even that you can) set the 'https' address in the config.  If you don't do that it silently fails to set up the https server. Bit of a head-scratcher for a while.

We've now setup gossip encryption as well. Since you can now rotate the keys (which is great!) I was wondering how I might bring a new node into the cluster if I've rotated the keys.  It seems like the encrypt parameter in the config would be out of date for the new node, but I can't see a way of initialising the keyring without specifying the encrypt parameter. Is there a way to leave the encrypt param out of the config (since it would always be out of date) and initialise the keyring manually with the correct key for the cluster? The 'consul keyring' command doesn't seem to have an init of that sort.

Can anyone comment on the expected workflow when bringing a node into an encrypted consul cluster? 

David

[Ryan Uber]

Hey David,

Thanks for the feedback on the documentation. I’ve opened https://github.com/hashicorp/consul/issues/831 to clarify that a bit better.

RE: Gossip encryption, what I’ve done up to this point is to just specify the key in the -encrypt CLI flag. This flag will initialize the keyring only if it doesn’t already exist. It’s also possible to initialize the keyring file yourself, since it is only JSON text in Consul’s data dir. We originally had a “-init” argument to the keyring command (see https://github.com/hashicorp/consul/pull/336#discussion_r18292967), but decided that the UX wasn’t quite right, and could be confusing if an encrypt parameter was also specified at start time.

Hope this helps!

- Ryan

--
You received this message because you are subscribed to the Google Groups "Consul" group.
To unsubscribe from this group and stop receiving emails from it, send an email to consul-tool...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[David Carr]

Hi Ryan,

Thanks for the quick reply. Hopefully those docs should help some other people out. That's the great thing about being able to dive into the code - you're always able to solve it yourself with enough patience.

I will try that CLI parameter first thing tomorrow.  That should be exactly what I need if it means I don't have to put the parameter in the config file.  The deploy is completely Puppetized, so I needed a place to pass that parameter at start up time as I bring a new node in.  It does mean an extra step to log on to one of the existing nodes and doing a 'consul keyring -list', but I don't see any way around that since the key is only available on those nodes already part of the cluster.

David

[Paul Slater]

hey Ryan,

I'm still struggling to see how to bootstrap encryption into an existing unencrypted cluster without downtime.  My interpretation of that -init would be to let you arrive in a state where you have a keyring, with one or more keys installed, but NOT actually using any.  You could then issue consul keyring -use=x to move from unencrypted -> encrypted.

Otherwise it looks like you have to make the config changes everywhere and do a whole cluster restart.  This would mean that everything is down during the restart and you have to issue the server/agent restart commands all at once as there is no other means of gracefully rolling it out.

Am I missing something ?

Thanks for any advice!

Paul

On Tuesday, 31 March 2015 19:07:36 UTC+1, Ryan Uber wrote: