Open Stack

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 [zbitter at redhat.com]
Sent: Tuesday, August 09, 2016 3:00 PM
To: openstack-dev at 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-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev