<div dir="ltr">Glad to see you weighed in on this. -d</div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Aug 1, 2015 at 3:50 PM, Matt Fischer <span dir="ltr"><<a href="mailto:matt@mattfischer.com" target="_blank">matt@mattfischer.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Agree that you guys are way over thinking this. You don't need to rotate keys at exactly the same time, we do it in within a one or two hours typically based on how our regions are setup. We do it with puppet, puppet runs on one keystone node at a time and drops the keys into place. The actual rotation and generation we handle with a script that then proposes the new key structure as a review which is then approved and deployed via the normal process. For this process I always drop keys 0, 1, 2 into place, I'm not bumping the numbers like the normal rotations do.<div><br><div>We had also considered ansible which would be perfect for this, but that makes our ability to setup throw away environments with a single click a bit more complicated. If you don't have that requirement, a simple ansible script is what you should do. </div></div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Aug 1, 2015 at 3:41 PM, Clint Byrum <span dir="ltr"><<a href="mailto:clint@fewbar.com" target="_blank">clint@fewbar.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Excerpts from Boris Bobrov's message of 2015-08-01 14:18:21 -0700:<br>
<div><div>> On Saturday 01 August 2015 16:27:17 <a href="mailto:bdobrelia@mirantis.com" target="_blank">bdobrelia@mirantis.com</a> wrote:<br>
> > I suggest to use pacemaker multistate clone resource to rotate and<br>
> rsync<br>
> > fernet tokens from local directories across cluster nodes. The resource<br>
> > prototype is described here<br>
> > <a href="https://etherpad.openstack.org/p/fernet_tokens_pacemaker" rel="noreferrer" target="_blank">https://etherpad.openstack.org/p/fernet_tokens_pacemaker</a>> Pros:<br>
> Pacemaker<br>
> > will care about CAP/split-brain stuff for us, we just design rotate and<br>
> > rsync logic. Also no shared FS/DB involved but only Corosync CIB - to<br>
> store<br>
> > few internal resource state related params, not tokens. Cons: Keystone<br>
> > nodes hosting fernet tokens directories must be members of pacemaker<br>
> > cluster. Also custom OCF script should be created to implement this. __<br>
> > Regards,<br>
> > Bogdan Dobrelya.<br>
> > IRC: bogdando<br>
><br>
> Looks complex.<br>
><br>
> I suggest this kind of bash or python script, running on Fuel master node:<br>
><br>
> 0. Check that all controllers are online;<br>
> 1. Go to one of the controllers, rotate keys there;<br>
> 2. Fetch key 0 from there;<br>
> 3. For each other controller rotate keys there and put the 0-key instead of<br>
> their new 0-key.<br>
> 4. If any of the nodes fail to get new keys (because they went offline or for<br>
> some other reason) revert the rotate (move the key with the biggest index<br>
> back to 0).<br>
><br>
> The script can be launched by cron or by button in Fuel.<br>
><br>
> I don't see anything critically bad if one rotation/sync event fails.<br>
><br>
<br>
</div></div>This too is overly complex and will cause failures. If you replace key 0,<br>
you will stop validating tokens that were encrypted with the old key 0.<br>
<br>
You simply need to run rotate on one, and then rsync that key repository<br>
to all of the others. You _must not_ run rotate again until you rsync to<br>
all of the others, since the key 0 from one rotation becomes the primary<br>
token encrypting key going forward, so you need it to get pushed out to<br>
all nodes as 0 first.<br>
<br>
Don't over think it. Just read <a href="http://lbragstad.com/?p=133" rel="noreferrer" target="_blank">http://lbragstad.com/?p=133</a> and it will<br>
remain simple.<br>
<div><div><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>