<div dir="ltr">Yeah, that's a good point. If we end up with something like etcd does all config have to be in there, or can we limit it to certain parts of config?<div><br></div><div>For some reason I was expecting more correlation between these two topics. I apologize for getting my wires crossed.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 16, 2017 at 1:02 PM, Davanum Srinivas <span dir="ltr"><<a href="mailto:davanum@gmail.com" target="_blank">davanum@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Lance,<br>
<br>
in the other thread, we have not been talking about having any kind of<br>
security for the fernet keys. Isn't that a requirement since if we<br>
throw that in etcd it may be vulnerable?<br>
<br>
Thanks,<br>
Dims<br>
<div class="HOEnZb"><div class="h5"><br>
On Thu, Mar 16, 2017 at 12:45 PM, Lance Bragstad <<a href="mailto:lbragstad@gmail.com">lbragstad@gmail.com</a>> wrote:<br>
> I think the success of this, or a revived fernet-backend spec, is going to<br>
> have a hard requirement on the outcome of the configuration opts discussion<br>
> [0]. When we attempted to introduce an abstraction for fernet keys<br>
> previously, it led down a rabbit hole of duplicated work across<br>
> implementations, which was part of the reason for dropping the spec.<br>
><br>
><br>
> [0]<br>
> <a href="http://lists.openstack.org/pipermail/openstack-dev/2017-March/113941.html" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/2017-<wbr>March/113941.html</a><br>
><br>
> On Thu, Mar 16, 2017 at 10:12 AM, Emilien Macchi <<a href="mailto:emilien@redhat.com">emilien@redhat.com</a>> wrote:<br>
>><br>
>> On Tue, Mar 14, 2017 at 1:27 PM, Emilien Macchi <<a href="mailto:emilien@redhat.com">emilien@redhat.com</a>><br>
>> wrote:<br>
>> > Folks,<br>
>> ><br>
>> > I found useful to share a spec that I started to write this morning:<br>
>> > <a href="https://review.openstack.org/445592" rel="noreferrer" target="_blank">https://review.openstack.org/<wbr>445592</a><br>
>> ><br>
>> > The goal is to do Keystone Fernet keys rotations in a way that scales<br>
>> > and is secure, by using the standard tools and not re-inventing the<br>
>> > wheel.<br>
>> > In other words: if you're working on Keystone or TripleO or any other<br>
>> > deployment tool: please read the spec and give any feedback.<br>
>> ><br>
>> > We would like to find a solution that would work for all OpenStack<br>
>> > deployment tools (Kolla, OSA, Fuel, TripleO, Helm, etc) but I sent the<br>
>> > specs to tripleo project<br>
>> > to get some feedback.<br>
>> ><br>
>> > If you already has THE solution that you think is the best one, then<br>
>> > we would be very happy to learn from it in a comment directly in the<br>
>> > spec.<br>
>> ><br>
>><br>
>> After 2 days of review from Keystone, TripleO, OSA (and probably some<br>
>> groups I missed), it's pretty clear the problem is already being fixed<br>
>> in different places in different ways and that's bad.<br>
>> IMHO we should engage some work to fix it in Keystone and investigate<br>
>> again a storage backend for Keystone tokens.<br>
>><br>
>> The Keystone specs that started this investigation was removed for Pike:<br>
>> <a href="https://review.openstack.org/#/c/439194/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/439194/</a><br>
>><br>
>> I see 2 options here:<br>
>><br>
>> - we keep duplicating efforts and let deployers implement their own<br>
>> solutions.<br>
>><br>
>> - we work with Keystone team to re-enable the spec and move forward to<br>
>> solve the problem in Keystone itself, therefore for all deployments<br>
>> tools in OpenStack (my favorite option).<br>
>><br>
>><br>
>> I would like to hear from Keystone folks what are the main blockers<br>
>> for option #2 and if this is only a human resource issue or if there<br>
>> is some technical points we need to solve (in that case, it could be<br>
>> done in the specs).<br>
>><br>
>><br>
>> Thanks,<br>
>> --<br>
>> Emilien Macchi<br>
>><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>
><br>
><br>
><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>
><br>
<br>
<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Davanum Srinivas :: <a href="https://twitter.com/dims" rel="noreferrer" target="_blank">https://twitter.com/dims</a><br>
</font></span><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>