Fernet key rotation removing keys early

Bug #1465444 reported by Chris Stone
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
Fix Released
High
Lance Bragstad
Kilo
Fix Released
High
Dolph Mathews

Bug Description

When setting up Fernet key rotation with a maximum number of active of keys set to 25, it turned out that 'keystone-manage fernet_rotate' started deleting two keys once there reached 13 existing keys. It would waver between 12 and 13 keys every time it was rotated. It looks like this might be related to the range of keys to remove being negative :

excess_keys = ( keys[:len(key_files) - CONF.fernet_tokens.max_active_keys + 1])
.. ends up being excess_keys = ( keys[:-11] )
.. which seems to be dipping back into the range of keys that should still be good and removing those.

Adding something like: "if len(key_files) - CONF.fernet_tokens.max_active_keys + 1 >= 0" for the purge excess keys section seemed to allow us to generate all 25 keys, then rotate as normal. Once we hit the full 25 keys, this additional line was no longer needed.

Attaching some log information showing the available keys going from 12, 13, 12, 13.

Revision history for this message
Chris Stone (cstone-0) wrote :
Brant Knudson (blk-u)
tags: added: fernet
tags: added: kilo-backport-potential
Changed in keystone:
status: New → Triaged
importance: Undecided → High
Dolph Mathews (dolph)
Changed in keystone:
assignee: nobody → Dolph Mathews (dolph)
milestone: none → liberty-1
Revision history for this message
Lance Bragstad (lbragstad) wrote :

Hi Chris,

Thanks for the report. I am able to confirm. For me, the first key (/etc/keystone/fernet-keys/1) is being pruned when I perform a rotate after there are 12 keys in the repository. So, once the 13th key is added, the first key is prematurely removed. Sounds like what you were experiencing.

I'll take a look into the code, thanks!

Revision history for this message
Lance Bragstad (lbragstad) wrote :

Oh, looks like I'm seeing keys 1 and 2 being purged when the 13th key is added.

Revision history for this message
Lance Bragstad (lbragstad) wrote :

I think I found the issue. I'm not 100% sure but I think it's possible that the logic that determines how many excess keys are in the repository doesn't account for negative slices in the list [0].

Here is a paste of what I was playing with [1]. I'm going to tinker with that logic.

[0] https://github.com/openstack/keystone/blob/1ce6a87738be1d6694c3feaf048547f7c58a1604/keystone/token/providers/fernet/utils.py#L212
[1] http://cdn.pasteraw.com/bsaknota9ex7cz7pua1c3koaezagjh2

Revision history for this message
Lance Bragstad (lbragstad) wrote :

The issue is that we are processing negatives as slices in the list, which gives a behavior similar to:

http://cdn.pasteraw.com/i2bc865nfdmva65vckdkt3sqioc2i9s

In our case, I don't think we'd want to bother continuing if the slice is negative, since that would mean that the repository contains less keys than what CONF.fernet_tokens.max_active_keys has set.

We could propose something like:

http://cdn.pasteraw.com/b46zmja0n61un7qamaofbrpbk4shr1j

Changed in keystone:
assignee: Dolph Mathews (dolph) → Lance Bragstad (lbragstad)
status: Triaged → In Progress
Changed in keystone:
status: In Progress → Fix Committed
Changed in keystone:
status: Fix Committed → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to keystone (stable/kilo)

Fix proposed to branch: stable/kilo
Review: https://review.openstack.org/207506

Dolph Mathews (dolph)
tags: removed: kilo-backport-potential
Revision history for this message
OpenStack Infra (hudson-openstack) wrote :

Fix proposed to branch: stable/kilo
Review: https://review.openstack.org/212945

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to keystone (stable/kilo)

Reviewed: https://review.openstack.org/212945
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=7498154ad8c1ee24a10e8577c69045fd19627530
Submitter: Jenkins
Branch: stable/kilo

commit 7498154ad8c1ee24a10e8577c69045fd19627530
Author: Lance Bragstad <email address hidden>
Date: Wed Jun 17 17:05:37 2015 +0000

    Fix Fernet key rotation

    Previously, depending on the size of CONF.fernet_tokens.max_active_keys, keys
    would be pruned depending on if excess_keys was a negative slice. This caused
    the key repository to never actually reach CONF.fernet_tokens.max_active_keys
    in the repository in some cases.

    Change-Id: Icf47d6612ef0e98e876334f56c993666df081b50
    Closes-Bug: 1465444
    (cherry picked from commit 46f56119a0d19f0c4075aaf0dd29f2d8cf76fa54)

tags: added: in-stable-kilo
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix merged to keystone (stable/kilo)

Reviewed: https://review.openstack.org/207506
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=17b7dbc81eb9b173c776b25b9b2aff6b2f9320ed
Submitter: Jenkins
Branch: stable/kilo

commit 17b7dbc81eb9b173c776b25b9b2aff6b2f9320ed
Author: Dolph Mathews <email address hidden>
Date: Wed Jun 17 17:15:42 2015 +0000

    Add unit test to exercise key rotation

    This reproduces the issue reported in bug 1465444 when applied directly
    to master (and actually fails with max_active_keys=4), but passes when
    applied to Lance's patch:

      https://review.openstack.org/#/c/192782/

    Change-Id: I045bc97b047dc18983757db052ad6e5bdad11329
    Related-Bug: 1465444
    (cherry picked from commit a422444fc4bb56e65cc4cc3fda8cf0f13cc079a5)

Thierry Carrez (ttx)
Changed in keystone:
milestone: liberty-1 → 8.0.0
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.