<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 27, 2015 at 2:03 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 Dolph Mathews's message of 2015-07-27 11:48:12 -0700:<br>
<div><div class="h5">> On Mon, Jul 27, 2015 at 1:31 PM, Clint Byrum <<a href="mailto:clint@fewbar.com">clint@fewbar.com</a>> wrote:<br>
><br>
> > Excerpts from Alexander Makarov's message of 2015-07-27 10:01:34 -0700:<br>
> > > Greetings!<br>
> > ><br>
> > > I'd like to discuss pro's and contra's of having Fernet encryption keys<br>
> > > stored in a database backend.<br>
> > > The idea itself emerged during discussion about synchronizing rotated<br>
> > keys<br>
> > > in HA environment.<br>
> > > Now Fernet keys are stored in the filesystem that has some availability<br>
> > > issues in unstable cluster.<br>
> > > OTOH, making SQL highly available is considered easier than that for a<br>
> > > filesystem.<br>
> > ><br>
> ><br>
> > I don't think HA is the root of the problem here. The problem is<br>
> > synchronization. If I have 3 keystone servers (n+1), and I rotate keys on<br>
> > them, I must very carefully restart them all at the exact right time to<br>
> > make sure one of them doesn't issue a token which will not be validated<br>
> > on another. This is quite a real possibility because the validation<br>
> > will not come from the user, but from the service, so it's not like we<br>
> > can use simple persistence rules. One would need a layer 7 capable load<br>
> > balancer that can find the token ID and make sure it goes back to the<br>
> > server that issued it.<br>
> ><br>
><br>
> This is not true (or if it is, I'd love see a bug report). keystone-manage<br>
> fernet_rotate uses a three phase rotation strategy (staged -> primary -><br>
> secondary) that allows you to distribute a staged key (used only for token<br>
> validation) throughout your cluster before it becomes a primary key (used<br>
> for token creation and validation) anywhere. Secondary keys are only used<br>
> for token validation.<br>
><br>
> All you have to do is atomically replace the fernet key directory with a<br>
> new key set.<br>
><br>
> You also don't have to restart keystone for it to pickup new keys dropped<br>
> onto the filesystem beneath it.<br>
><br>
<br>
</div></div>That's great news! Is this documented anywhere? I dug through the<br>
operators guides, security guide, install guide, etc. Nothing described<br>
this dance, which is impressive and should be written down!<br></blockquote><div><br></div><div>(BTW, your original assumption would normally have been an accurate one!)</div><div><br></div><div>I don't believe it's documented in any of those places, yet. The best explanation of the three phases in tree I'm aware of is probably this (which isn't particularly accessible..):</div><div><br></div><div>  <a href="https://github.com/openstack/keystone/blob/6a6fcc2/keystone/cmd/cli.py#L208-L223">https://github.com/openstack/keystone/blob/6a6fcc2/keystone/cmd/cli.py#L208-L223</a></div><div><br></div><div>Lance Bragstad and I also gave a small presentation at the Vancouver summit on the behavior and he mentions the same on one of his blog posts:<br></div><div><br></div><div>  <a href="https://www.youtube.com/watch?v=duRBlm9RtCw&feature=youtu.be">https://www.youtube.com/watch?v=duRBlm9RtCw&feature=youtu.be</a></div><div>  <a href="http://lbragstad.com/?p=133">http://lbragstad.com/?p=133</a></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I even tried to discern how it worked from the code but it actually<br>
looks like it does not work the way you describe on casual investigation.<br></blockquote><div><br></div><div>I don't blame you! I'll work to improve the user-facing docs on the topic.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
</span>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>
</blockquote></div><br></div></div>