Bug 1889443 - [RFE] Support for rotating and migrating Fernet keys used to encrypt and decrypt keystone credentials
Summary: [RFE] Support for rotating and migrating Fernet keys used to encrypt and decr...
Status: NEW
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: tripleo-ansible
Version: 17.0 (Wallaby)
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: ---
Assignee: OSP Team
QA Contact: Jeremy Agee
Depends On:
TreeView+ depends on / blocked
Reported: 2020-10-19 16:55 UTC by Lance Bragstad
Modified: 2021-07-09 16:29 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed:
Target Upstream Version:

Attachments (Terms of Use)

Description Lance Bragstad 2020-10-19 16:55:04 UTC
Description of problem:

Currently, it's possible for deployers to unintentionally lock all users out of their credential data.

Keystone supports a credentials backend, which is primarily used for storing MFA secrets and ec2 credentials (not passwords). In the Newton release, these credentials were encrypted so they weren't stored in plaintext. The upstream community re-used the existing token enryption
mechanism to encrypt credential data. As a result, credential encryption uses an entirely separate key repository from token encryption, but both repositories are managed using similar rotation flows.

The credential backend stores a hash of the key used to encrypt it. The `keystone-manage credential_rotate` command relies on this information to ensure it doesn't overrotate the keys. If keys are overrotated, the encrypted data is unrecoverable. Deployers must use the following flow to rotate credential fernet keys safely:

1.) setup the credential repository (`keystone-manage credential_setup`)
2.) rotate the credential keys (`keystone-manage credential_rotate`)
3.) re-enrypt credentials using the newest fernet key (`keystone-manage credential_migrate`)

Steps #2 and #3 can be done as many times as needed, so long as they're done in lock-step.

Currently, we don't have anything in TripleO that enforces this workflow. It's possible for deployers to set KeystoneCredential0 and KeystoneCredential1 to keys of their own choosing, manually rotating the keys. This can result in the deployer unintentionally locking all credential data since the symmetric keys used to encrypt them are no longer available.

Comment 2 Lance Bragstad 2020-10-19 16:59:18 UTC
More information on credential encryption, including the rotation process, is documented upstream [0].

[0] https://docs.openstack.org/keystone/latest/admin/credential-encryption.html

Note You need to log in before you can comment on or make changes to this bug.