Its been said before and I'll reiterate, the fernet keys are not meant to be managed by keystone itself directly. This is viewed as a DevOps concern as keystone itself doesnt dictate the HA method to be used (many deployers use different methodologies). Most CMS systems handle synchronization of files on disk very very well. Much the same as ssl certs, pki infrastructure, Etc. fernet keys are more in the realm of your CMS tool than something that belongs in keystone's DB.
If you look through the other messages in both this thread and the others, you'll find this has been the stance from the beginning. --Morgan Sent via mobile > On Aug 6, 2015, at 15:25, joehuang <joehu...@huawei.com> wrote: > > Hi, > > Even if Barbican can store the key, but it will add overhead for restful API > interaction between KeyStone and Barbican. May we store the key in the > KeyStone DB backend (or another separate DB backend), for example MySQL? > > Best Regards > Chaoyi Huang ( Joe Huang ) > > From: Lance Bragstad [mailto:lbrags...@gmail.com] > Sent: Wednesday, August 05, 2015 9:06 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [Keystone][Fernet] HA SQL backend for Fernet keys > > > > On Wed, Aug 5, 2015 at 2:38 AM, Adam Heczko <ahec...@mirantis.com> wrote: > Hi, I believe that Barbican keystore for signing keys was discussed earlier. > I'm not sure if that's best idea since Barbican relies on Keystone > authN/authZ. > > Correct. Once we find a solution for that problem it would be interesting to > work towards a solution for storing keys in Barbican. I've talked to several > people about this already and it seems to be the natural progression. Once we > can do that, I think we can revisit the tooling for rotation. > > That's why this mechanism should be considered rather as "out of band" to > Keystone/OS API and is rather devops task. > > regards, > > Adam > > > > > On Wed, Aug 5, 2015 at 8:11 AM, joehuang <joehu...@huawei.com> wrote: > Hi, Lance, > > May we store the keys in Barbican, can the key rotation be done upon > Barbican? And if we use Barican as the repository, then it’s easier for Key > distribution and rotation in multiple KeyStone deployment scenario, the > database replication (sync. or async.) capability could be leveraged. > > Best Regards > Chaoyi Huang ( Joe Huang ) > > From: Lance Bragstad [mailto:lbrags...@gmail.com] > Sent: Tuesday, August 04, 2015 10:56 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [Keystone][Fernet] HA SQL backend for Fernet keys > > > On Tue, Aug 4, 2015 at 9:28 AM, Boris Bobrov <bbob...@mirantis.com> wrote: > On Tuesday 04 August 2015 08:06:21 Lance Bragstad wrote: > > On Tue, Aug 4, 2015 at 1:37 AM, Boris Bobrov <bbob...@mirantis.com> wrote: > > > On Monday 03 August 2015 21:05:00 David Stanek wrote: > > > > On Sat, Aug 1, 2015 at 8:03 PM, Boris Bobrov <bbob...@mirantis.com> > > > > > > wrote: > > > > > Also, come on, does http://paste.openstack.org/show/406674/ look > > > > > overly > > > > > complex? (it should be launched from Fuel master node). > > > > > > > > I'm reading this on a small phone, so I may have it wrong, but the > > > > script > > > > > > > > appears to be broken. > > > > > > > > > > > > > > > > It will ssh to node-1 and rotate. In the simplest case this takes key > > > > 0 > > > > > > and > > > > > > > moves it to the next highest key number. Then a new key 0 is > > > > generated. > > > > > > > > > > > > > > > > Later there is a loop that will again ssh into node-1 and run the > > > > > > rotation > > > > > > > script. If there is a limit set on the number of keys and you are at > > > > that > > > > > > > > limit a key will be deleted. This extra rotation on node-1 means that > > > > > > it's > > > > > > > possible that it has a different set of keys than are on node-2 and > > > > > > node-3. > > > > > > > > > > > > You are absolutely right. Node-1 should be excluded from the loop. > > > > > > > > > > > > pinc also lacks "-c 1". > > > > > > > > > > > > I am sure that other issues can be found. > > > > > > > > > > > > In my excuse I want to say that I never ran the script and wrote it just > > > to show how simple it should be. Thank for review though! > > > > > > > > > > > > I also hope that no one is going to use a script from a mailing list. > > > > > > > What's the issue with just a simple rsync of the directory? > > > > > > None I think. I just want to reuse the interface provided by > > > keystone-manage. > > > > You wanted to use the interface from keystone-manage to handle the actual > > promotion of the staged key, right? This is why there were two > > fernet_rotate commands issued? > > Right. Here is the fixed version (please don't use it anyway): > http://paste.openstack.org/show/406862/ > > Note, this doesn't take into account the initial key repository creation, > does it? > > Here is a similar version that relies on rsync for the distribution after the > initial key rotation [0]. > > [0] http://cdn.pasteraw.com/d6odnvtt1u9zsw5mg4xetzgufy1mjua > > > > -- > Best regards, > Boris Bobrov > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > -- > Adam Heczko > Security Engineer @ Mirantis Inc. > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
