Folks,
I found useful to share a spec that I started to write this morning:
https://review.openstack.org/445592
The goal is to do Keystone Fernet keys rotations in a way that scales
and is secure, by using the standard tools and not re-inventing the
wheel.
In other words: if you're working on Key
On Tue, Mar 14, 2017 at 1:27 PM, Emilien Macchi wrote:
> Folks,
>
> I found useful to share a spec that I started to write this morning:
> https://review.openstack.org/445592
>
> The goal is to do Keystone Fernet keys rotations in a way that scales
> and is secure, by using the standard tools and
I think the success of this, or a revived fernet-backend spec, is going to
have a hard requirement on the outcome of the configuration opts discussion
[0]. When we attempted to introduce an abstraction for fernet keys
previously, it led down a rabbit hole of duplicated work across
implementations,
Lance,
in the other thread, we have not been talking about having any kind of
security for the fernet keys. Isn't that a requirement since if we
throw that in etcd it may be vulnerable?
Thanks,
Dims
On Thu, Mar 16, 2017 at 12:45 PM, Lance Bragstad wrote:
> I think the success of this, or a revi
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?
For some reason I was expecting more correlation between these two topics.
I apologize for getting my wires crossed.
On Thu, Mar 16, 2017 at 1:02 PM
On Thu, Mar 16, 2017 at 2:53 PM, Lance Bragstad wrote:
> 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?
This is a good question but I'm not sure it belongs to this threads,
since it's not relat
