Open Stack

> On 3 Aug 2015, at 8:02 pm, Sergii Golovatiuk <sgolovatiuk at mirantis.com> wrote:
> 
> Hi,
> 
> I agree with Bogdan that key rotation procedure should be part of HA solution.

These things don’t usually have to be an either/or situation.
Why not create one script that does the work and can be called manually if desired but also create an agent that pacemaker can use to call it at the appropriate time.

> If you make a simple script then this script will be a single point of failure. It requires operator's attention so it may lead to human errors also. Adding monitoring around it or expiration time is not a solution either.
> 
> There are couple of approaches how to make 'key rotation' HA ready.
> 
> 1. Make it as part of pacemaker OCF script. In this case pacemaker will select the node which will be Master. It will be responsible for key generations. In this case OCF script should have logic how to distribute keys. It may be puppet or some rsync wrappers like lsyncd or special function in OCF script itself. In this case when master is dead, pacemaker will elect a new master while old one is down.
> 
> 2. Make keystone HA ready by itself. In this case, all logic of distributed system should be covered in keystone. keystone should be able to detect peers, it should have some consensus algorithms (PAXOS, RAFT, ZAB). Using this algorithm master should be elected. Master should generate keys and distribute them somehow to all other peers. Key distribution may be done via rsync or using memcache/db as centralized storage for keys. Master may send a event to all peers or peers may check memcache/db periodically.
> 
> 
> 
> 
> 
> --
> Best regards,
> Sergii Golovatiuk,
> Skype #golserge
> IRC #holser
> 
> On Mon, Aug 3, 2015 at 2:37 AM, David Medberry <openstack at medberry.net> wrote:
> Glad to see you weighed in on this. -d
> 
> On Sat, Aug 1, 2015 at 3:50 PM, Matt Fischer <matt at mattfischer.com> wrote:
> Agree that you guys are way over thinking this. You don't need to rotate keys at exactly the same time, we do it in within a one or two hours typically based on how our regions are setup. We do it with puppet, puppet runs on one keystone node at a time and drops the keys into place. The actual rotation and generation we handle with a script that then proposes the new key structure as a review which is then approved and deployed via the normal process. For this process I always drop keys 0, 1, 2 into place, I'm not bumping the numbers like the normal rotations do.
> 
> We had also considered ansible which would be perfect for this, but that makes our ability to setup throw away environments with a single click a bit more complicated. If you don't have that requirement, a simple ansible script is what you should do. 
> 
> 
> On Sat, Aug 1, 2015 at 3:41 PM, Clint Byrum <clint at fewbar.com> wrote:
> Excerpts from Boris Bobrov's message of 2015-08-01 14:18:21 -0700:
> > On Saturday 01 August 2015 16:27:17 bdobrelia at mirantis.com wrote:
> > > I suggest to use pacemaker multistate clone resource to rotate and
> > rsync
> > > fernet tokens from local directories across cluster nodes. The resource
> > > prototype is described here
> > > https://etherpad.openstack.org/p/fernet_tokens_pacemaker> Pros:
> > Pacemaker
> > > will care about CAP/split-brain stuff for us, we just design rotate and
> > > rsync logic. Also no shared FS/DB involved but only Corosync CIB - to
> > store
> > > few internal resource state related params, not tokens. Cons: Keystone
> > > nodes hosting fernet tokens directories must be members of pacemaker
> > > cluster. Also custom OCF script should be created to implement this. __
> > > Regards,
> > > Bogdan Dobrelya.
> > > IRC: bogdando
> >
> > Looks complex.
> >
> > I suggest this kind of bash or python script, running on Fuel master node:
> >
> > 0. Check that all controllers are online;
> > 1. Go to one of the controllers, rotate keys there;
> > 2. Fetch key 0 from there;
> > 3. For each other controller rotate keys there and put the 0-key instead of
> > their new 0-key.
> > 4. If any of the nodes fail to get new keys (because they went offline or for
> > some other reason) revert the rotate (move the key with the biggest index
> > back to 0).
> >
> > The script can be launched by cron or by button in Fuel.
> >
> > I don't see anything critically bad if one rotation/sync event fails.
> >
> 
> This too is overly complex and will cause failures. If you replace key 0,
> you will stop validating tokens that were encrypted with the old key 0.
> 
> You simply need to run rotate on one, and then rsync that key repository
> to all of the others. You _must not_ run rotate again until you rsync to
> all of the others, since the key 0 from one rotation becomes the primary
> token encrypting key going forward, so you need it to get pushed out to
> all nodes as 0 first.
> 
> Don't over think it. Just read http://lbragstad.com/?p=133 and it will
> remain simple.
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev