Fernet token management should be done outside of juju
Bug #1849519 reported by
Liam Young
This bug affects 6 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Keystone Charm |
Fix Released
|
High
|
Alex Kavanagh |
Bug Description
Fernet tokens are rotated and distributed to all keystone units by the keystone unit using the leader settings mechanism. If there is an issue with juju then the leader may perform the rotation but fail to distribute the keys. After time this will cause the non-leaders to reject the leaders tokens and vice versa.
I think it makes sense to move the key distribution to a mechanism that does not involve juju.
Changed in charm-keystone: | |
status: | New → Triaged |
importance: | Undecided → Wishlist |
Changed in charm-keystone: | |
assignee: | nobody → Alex Kavanagh (ajkavanagh) |
tags: | added: seg |
Changed in charm-keystone: | |
assignee: | Alex Kavanagh (ajkavanagh) → nobody |
Changed in charm-keystone: | |
status: | Triaged → Fix Committed |
assignee: | nobody → Alex Kavanagh (ajkavanagh) |
Changed in charm-keystone: | |
milestone: | none → 21.01 |
Changed in charm-keystone: | |
status: | Fix Committed → Fix Released |
To post a comment you must log in.
Just adding some thoughts that we generated during our call:
1. The fernet token rotation has to take place on only ONE unit; currently this is the Juju leader, but if juju is excused, then determining which unit should do the rotation might be more complicated. [1]
2. An approach that was discussed is to use rsync over ssh between the 'leader' and the other units.
3. juju is still (obviously) used to configure the jobs that does the fernet key rotation.
[1] - I think we can use juju to 'set' via the config which unit is the leader, and the script just dumbly follows this. If leader changes, then the config will be re-written, etc. i.e. no additional method of determining the leader is needed.