Open Stack

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.