ofekisr opened a new issue #15362: URL: https://github.com/apache/superset/issues/15362
### Motivation In short * Instead of using one master key aka flask.secret_key use different key for each use * support key rotation In long Our organization security policies require to meet constraints in regard to using secret keys and credentials * Our products should use a different key for each use so in case a specific key is stolen, all other objects are kept safe. * Key can be changed or rotated at any time, so fresh keys can be maintained all the time. * When Superset is crashed or exited, the keys cannot be lost so encrypted data could be decrypted. ### Proposed Change general: * Each library/module which is used the master key by accessing app.secret_key will be accessed the key by calling a get key method * use cases consisting of encryption-decryption flows will define methods handling procedures of rotations, means decrypt with old keys and re-encryption with a new key * adding endpoints to declare rotations, they will trigger the declared procedures. * Easy way to define new dedicated keys in the future features Specific: * dedicated key for singing cookies * dedicated key for encryption-decryption insert and fetching "databases" rows (models) * dedicated key for Oauth login flow * dedicated key for Fab login and decorators Guidelines * Use feature flag * Incremantaly by phases, each phase can consist of a series of PRs, PR for each specific secret-key use * Default values will be the current master key * Can be customized for each use-case * Contribute to depended libraries Plan Phase one - adapting required infrastructure without phase two - migrate using the new infrastructure phase three - adding infrastructure to support key-changed declarations phase four - upgrade the dependent libraries that adapt the same mechanism Phase one * Adapting the https://pypi.org/project/keys-management/ package * defining feature flag phase two - for each dedicated key: - add temporary code to inject secret key method instead of value - based on inheritance the current clients classes - define specific configurations for the specific key while the default value will be the master key - if necessary defining roataion methods * review phase four why I said "temporary code" phase three will be incrementally too, first adding REST API endpoints, then refactor or add more safe and robust way such as CLI - first, support only an offline mode. Then build a small CLI socket-based service to support key rotations in runtime phase four We plan to contribute the same mechanism directly to the dependent libraries. for each adapted dependent library - remove the temporary code added in phase three - upgrade the library -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
