Implement Fernet tokens as default authentication method, including initial generation and propagation of keys to all controllers.
The default Keystone configuration for Fernet tokens does not support keystone service running on multiple nodes. As a result, the current state requires Operators that are interested in using Fernet tokens to manually generate and sync the Fernet token key across controllers. Keystone itself does not have any knowledge of multiple key locations and does not provide any syncing capabilities natively. However, it is critical to have the keys synced between all Keystone nodes in order to provide token validation.
The goal of this spec is to provide a mechanism by which Fernet token keys can be easily generated, propagated during initial cluster environment setup to all keystone nodes and enabled by default.
Keystone with Fernet tokens does not natively support multiple controllers, we propose to implement this functionality using astute and puppet manifests in fuel-library. This will enable the user to generate and install Fernet keys to all Keystone nodes seamlessly during the deployment process.
To generate keys, a new ‘GenerateFernetKeys’ class will be added to ‘pre-deployment actions’ of astute. It will use the openssl tool for key generation. The generated keys will be stored in the following directory on the Fuel-Master node:
To copy the generated Fernet keys to all controllers, a new ‘UploadFernetKeys’ class will be added to ‘pre-deployment actions’ of astute. It will copy Fernet keys to the following destination:
After copying Fernet keys to all controller nodes, they will be installed to the appropriate directory using puppets facilities:
In order to use Fernet tokens as the default authentication mechanism, the ‘token_provider’ Keystone parameter will be set to ‘keystone.token.providers.fernet.Provider’ in the associated puppet manifest.
The following option should be passed to ::keystone class in order to enable Fernet tokens: * token_provider = keystone.token.providers.fernet.Provider
generate fernet keys using default keystone tool on Fuel Master node (keystone-manage fernet_setup) and copy them to all keystone nodes:
This proposition was rejected as this case could lead to upgrade of Keystone on Fuel Master node. And it would require a large overhead cost to perform this update.
generate fernet keys using default keystone tool on Primary node (keystone-manage fernet_setup) where keystone service is running keystone service is running and copy them to another keystone nodes:
This case was not implemented as there were some complexities to derive keys from deployed Primary node and copy the keys to another keystone node using Astute. This case needed an additional researching.
There should be no impact for Fuel Master upgrades. For existing cloud environment upgrades, there may be some service interruption until all controllers have been upgraded to support Fernet tokens and all tokens have been updated and all clients have new Fernet based tokens.
It is expected to have the same security level as for ssh keys of mysql, nova and etc.
Rally run showed the following results:
|Scenario||Load durations(s)||Full duration(s)||Itera tions|
Switching to Fernet tokens and manual Fernet keys rotation procedure should be documented in Fuel Deployment Guide .
Environment with enabled Fernet tokens should pass all tests currently run on Scale Lab with no significant performance degradation.
After successfull deployment all keystone nodes contain identical fernet keys, Keystone functions properly.