It needs to work in a distributed way... What happens if the one node you have cron running on doesn't work for a while. Keystone breaks?
If the undercloud deploys a timed workfow where the workflow can fail over from machine to machine, that would work. Thanks, Kevin ________________________________________ From: Zane Bitter [zbit...@redhat.com] Sent: Tuesday, August 09, 2016 3:00 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [tripleo] Fernet Key rotation On 09/08/16 17:11, Adam Young wrote: > The Fernet token format uses a symmetric key to sign tokens. In order > to check the signature, these keys need to be synchronized across all of > the Keystone servers. > > > I don't want to pass around nake symmetric keys. The right way to do > this is to put them into a PKCS 11 Envelope. Roughly, this: > > > 1. Each server generates a keypair and sends the public key to the > undercloud > > 2. undercloud generates a Fernet key > > 3. Undercloud puts the Fernet token into a PKCS11 document signed with > the overcloud nodes public key > > 4. Undercloud posts the PKCS11 data to metadata > > 5. os-*config Node downloads and stores the proper PKCS11 data > > 6. Something unpackst the pkcs11 data and puts the key into the Fernet > key store > > That last step needs to make use of the keystone-manage fernet_rotate > command. > > > How do we go about making this happen? The key rotations should be > scheduled infrequently; let me throw out monthly as a starting point for > the discussion, although that is probably way too frequent. How do we > schedule this? Is this a new stack that depends on the Keystone role? This sounds like a classic example of a workflow. Two possibilities come to mind. The fun way: Implement this as a Mistral workflow. Deploy the workflow along with a timed trigger somewhere in the overcloud Heat templates - you can grab data from other resources to figure out e.g. which machines you need to push keys to. The Mistral service on the undercloud will take care of running the workflow for you (thanks to the timed trigger), and its presence in the templates will ensure it gets set up automatically. The boring way: Implement this as a shell script. Add a cron job on the undercloud to run the script. The cron service on the undercloud will take care of running the workflow for you, and adding it to the undercloud puppet manifests will ensure it gets set up automatically. In either case a good mechanism might be to use a Heat Software Deployment via the Heat API directly (i.e. not as part of a stack) to push changes to the servers. (I say 'push' but it's more a case of making the data available for os-collect-config to grab it.) The biggest drawback of the cron job is that it will need to have some way of obtaining credentials in order to push data onto the servers and also to query the overcloud stack to find out which servers to push to. Whereas the Mistral workflow runs as the undercloud (keystone) user who created the 'overcloud' stack and the server list can be supplied through the template. cheers, Zane. __________________________________________________________________________ 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