<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 9, 2017 at 11:17 AM, 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 Lance Bragstad's message of 2017-06-08 16:10:00 -0500:<br>
<span class="">> On Thu, Jun 8, 2017 at 3:21 PM, Emilien Macchi <<a href="mailto:emilien@redhat.com">emilien@redhat.com</a>> wrote:<br>
><br>
> > On Thu, Jun 8, 2017 at 7:34 PM, Lance Bragstad <<a href="mailto:lbragstad@gmail.com">lbragstad@gmail.com</a>><br>
> > wrote:<br>
> > > After digging into etcd a bit, one place this might be help deployer<br>
> > > experience would be the handling of fernet keys for token encryption in<br>
> > > keystone. Currently, all keys used to encrypt and decrypt tokens are<br>
> > kept on<br>
> > > disk for each keystone node in the deployment. While simple, it requires<br>
> > > operators to perform rotation on a single node and then push, or sync,<br>
> > the<br>
> > > new key set to the rest of the nodes. This must be done in lock step in<br>
> > > order to prevent early token invalidation and inconsistent token<br>
> > responses.<br>
> ><br>
> > This is what we discussed a few months ago :-)<br>
> ><br>
> > <a href="http://lists.openstack.org/pipermail/openstack-dev/2017-March/113943.html" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/2017-<wbr>March/113943.html</a><br>
> ><br>
> > I'm glad it's coming back ;-)<br>
> ><br>
><br>
> Yep! I've proposed a pretty basic spec to backlog [0] in an effort to<br>
> capture the discussion. I've also noted the point Kevin brought up about<br>
> authorization in etcd (thanks, Kevin!)<br>
><br>
> If someone feels compelled to take that and run with it, they are more than<br>
> welcome to.<br>
><br>
> [0] <a href="https://review.openstack.org/#/c/472385/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/472385/</a><br>
><br>
<br>
</span>I commented on the spec. I think this is a misguided idea. etcd3 is a<br>
_coordination_ service. Not a key manager. It lacks the audit logging<br>
and access control one expects to protect and manage key material. I'd<br>
much rather see something like Hashicorp's Vault [1] implemented for<br>
Fernet keys than etcd3. We even have a library for such things called<br>
Castellan[2].<br></blockquote><div><br></div><div>Great point, and thanks for leaving it in the spec. I'm glad we're getting this documented since this specific discussion has cropped up a couple times.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
[1] <a href="https://www.vaultproject.io/" rel="noreferrer" target="_blank">https://www.vaultproject.io/</a><br>
[2] <a href="https://docs.openstack.org/developer/castellan/" rel="noreferrer" target="_blank">https://docs.openstack.org/<wbr>developer/castellan/</a><br>
<div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>______________________________<wbr>______________<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.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>