Two initial ideas:

We could create a specific ansible task to rotate the keys, and document that operator should set up a cron job on the deployment node to run this periodically.

We could also look at making use of VRRP (keepalived). Potentially the cron job could run on every controller, but only take action if it identifies it's the one with the VIP.

The second seems preferable to me as it requires no additional effort on the part of the operator. Maybe there's problems with this though that I'm not thinking of.

-Paul

On 06/03/17 05:52, Jeffrey Zhang wrote:
fix subject typo

On Mon, Mar 6, 2017 at 12:28 PM, Jeffrey Zhang <zhang.lei....@gmail.com
<mailto:zhang.lei....@gmail.com>> wrote:

    Kolla have support keystone fernet keys. But there are still some
    topics worth to talk.

    The key issue is key distribution. Kolla's solution is like

    * there is a task run frequently by cronjob to check whether
      the key should be rotate. This is controlled by
      `fernet_token_expiry` variable
    * When key rotate is required, the task in cron job will generate a
      new key by using `keystone-manage fernet-rotate` and distribute all
      keys in /etc/keystone/fernet-keys folder to other by using
      `rsync --delete`

    one issue is: there is no global lock in rotate and distribute steps.
    above command is ran on all controllers. it may cause issues if
    all controllers run this at the same time.

    Since we are using Ansible as deployment tools. there is not daemon
    agent at all to keep rotate and distribution atomic. Is there any
    easier way to implement a global lock?

    possible solution:
    1. configure cron job with different time on each controller
    2. implement a global lock? ( no idea how )

    [0] https://docs.openstack.org/admin-guide/identity-fernet-token-faq.html
    <https://docs.openstack.org/admin-guide/identity-fernet-token-faq.html>

    --
    Regards,
    Jeffrey Zhang
    Blog: http://xcodest.me <http://xcodest.me/>




--
Regards,
Jeffrey Zhang
Blog: http://xcodest.me <http://xcodest.me/>


__________________________________________________________________________
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

Reply via email to