feature: change encryption keys#199
feature: change encryption keys#199armon merged 65 commits intohashicorp:masterfrom ryanuber:keyring
Conversation
|
@ryanuber Wow! This is a huge PR! Awesome work! I will try to comb through this over the weekend. With the |
|
@armon the My thinking was that if the commands are idempotent, you would just do a |
|
@ryanuber Got it. Would it be possible to add a very simple indicator to list, just something thats like [58/60] or something that indicates how many nodes have that key? This way an operator can quickly see if they need to run |
|
@armon definitely! I'll take a stab at that over the weekend. |
serf/internal_query.go
Outdated
|
@ryanuber I've made a few notes, but overall this looks super solid! Very excited to have this in for the next release. Thanks for the hard work! |
|
@armon Thanks for the review! I made some adjustments based on your recommendations and added a few response comments. Let me know what you think and we can adjust further from here. |
There was a problem hiding this comment.
We should probably add a section below that documents the format of this file. Just so people know how to setup the keys, that the first key is the primary, etc.
|
@ryanuber This is looking really good. I think it's very close. I think we are also missing some tests for the RPC layer, but I can always add those after a merge if you want. |
…e mechanics are different from a tags file
… polluting the Serf API
|
@armon I took a swing at the RPC tests and added some command tests. If there is anything you think we are missing just let me know! |
|
@ryanuber Looks awesome! Thanks so much for all the hard work! |
For a week or so I've been chipping away at this feature little by little. It uses the new memberlist keyring feature to allow Serf to handle encryption key changes in a running cluster. I feel like it's feature-complete, and ready to start gathering some suggestions on the code itself.
There is more conversation around the feature in general in #194.
The bottom line on what it does can be seen with a few command examples. All of the operations are idempotent, so you can just keep running them without negative consequences if they fail.
Install a new key
Change the key used to encrypt messages:
List keys in use on the cluster:
Remove a key:
Error conditions during key operations:
I know this pull request is pretty massive, so if splitting it into smaller chunks is preferred, I can try doing that. Just let me know!