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
