JWS key rotation¶

Initial setup¶

Before a deployment of keystone servers can issue JWT tokens, each server must set keystone.conf [token] provider = jws. Additionally, each API server must have its own asymmetric key pair either generated manually or using keystone-manage create_jws_keypair. If you’re generating the key pairs manually, they must be usable with the ES256 JSON Web Algorithm (JWA). It is worth noting that the keystone-manage create_jws_keypair command line utility will create an appropriate key pair, but it will not automatically deploy it to the key repository locations defined in keystone.conf [jwt_tokens]. It is up to operators to move these files accordingly and resolve possible file name conflicts.

After generating a key pair, the public key from each API server must be shared with every other API server in the deployment. Ensure the private key used to sign JWS tokens is readable by the process running keystone and available in the keystone.conf [jwt_tokens] jws_private_key_repository location. Keystone will automatically use a key named private.pem to sign tokens and ignore all other keys in the repository. To validate tokens, keystone will iterate all available public keys in keystone.conf [jwt_tokens] jws_public_key_repository. At a minimum, this repository needs to have the corresponding public key to the private.pem key found in keystone.conf [jwt_tokens] jws_private_key_repository.

Continued operations¶

Depending on the security requirements for your deployment, you might need to rotate out an existing key pair. To do so without prematurely invalidating tokens, follow these steps:

1. Generate a new asymmetric key pair for a given keystone API server (see keystone-manage create_jws_keypair for more details)
2. Copy or sync the newly generated public key to the public key repositories of all other keystone API servers, the public key should be placed in keystone.conf [jwt_tokens] jws_public_key_repository
3. Copy the new private key to the private key repository on the API server you’re performing the rotation on and make sure it’s named private.pem, at this point the server will start signing tokens with the new private key and all other keystone API servers will be able to validate those tokens since they already have a copy of the public key from step #2
4. At this point, you must wait until the last tokens signed with the old private key have expired before you can remove the old corresponding public keys from each keystone API server, note this should be a minimum of keystone.conf [token] expiration
5. Once you’re confident all tokens signed with the old private key are expired, it is safe to remove the old corresponding public key from each API server in the deployment, which is important in case the original private key was compromised and prevents attackers from using it craft their own tokens