You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@superset.apache.org by GitBox <gi...@apache.org> on 2021/06/24 11:01:00 UTC
[GitHub] [superset] ofekisr opened a new issue #15362: [SIP] Proposal for secret keys rotations and remove using one master key
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:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
[GitHub] [superset] ofekisr commented on issue #15362: [SIP-70] Secret keys rotations and stop using single SECRET_KEY
Posted by GitBox <gi...@apache.org>.
ofekisr commented on issue #15362:
URL: https://github.com/apache/superset/issues/15362#issuecomment-875494122
As I had already said, the keys-management package does not claim to be responsible for storing keys, but it fetches the key by key-store - a function that return keys, so each client can define its key-store to fetch keys from a specific provider
--
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.
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
[GitHub] [superset] ofekisr commented on issue #15362: [SIP-70] Secret keys rotations and stop using single SECRET_KEY
Posted by GitBox <gi...@apache.org>.
ofekisr commented on issue #15362:
URL: https://github.com/apache/superset/issues/15362#issuecomment-871501191
Hi @michael-s-molina
none of the solutions you suggest is a python based except for Confidant.
My solution support secret-keys-rotations assistance.
[keys-management](https://pypi.org/project/keys-management/) package does not claim to be responsible for storing keys, there are so many solution for it
--
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.
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
[GitHub] [superset] michael-s-molina commented on issue #15362: [SIP-70] Secret keys rotations and stop using single SECRET_KEY
Posted by GitBox <gi...@apache.org>.
michael-s-molina commented on issue #15362:
URL: https://github.com/apache/superset/issues/15362#issuecomment-870061247
Thanks for the SIP @ofekisr.
Currently, we have some very mature solutions regarding the management of secret keys like [Keywhiz](https://github.com/square/keywhiz), [Vault](https://github.com/hashicorp/vault), [Confidant](https://github.com/lyft/confidant), [Knox](https://github.com/pinterest/knox), etc. Can you provide more context on which solutions were considered, why they don't fit our case, and why did you choose to implement your own package? It would be awesome to add this information to the **Rejected Alternatives** section of the SIP.
--
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.
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
[GitHub] [superset] craig-rueda commented on issue #15362: [SIP-70] Secret keys rotations and stop using single SECRET_KEY
Posted by GitBox <gi...@apache.org>.
craig-rueda commented on issue #15362:
URL: https://github.com/apache/superset/issues/15362#issuecomment-874454750
I'm all for this one, as long as the final impl is pluggable. I think I share @michael-s-molina 's concern in that the implementation shouldn't prevent us from being able to adapt the secret backend to whatever provider a user needs. I suggest adding the ability to configure different "providers" that can be overridden in configuration, with the default implementation just delegating to `SECRET_KEY` for backwards compatibility.
--
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.
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
[GitHub] [superset] craig-rueda commented on issue #15362: [SIP-70] Secret keys rotations and stop using single SECRET_KEY
Posted by GitBox <gi...@apache.org>.
craig-rueda commented on issue #15362:
URL: https://github.com/apache/superset/issues/15362#issuecomment-874454750
I'm all for this one, as long as the final impl is pluggable. I think I share @michael-s-molina 's concern in that the implementation shouldn't prevent us from being able to adapt the secret backend to whatever provider a user needs. I suggest adding the ability to configure different "providers" that can be overridden in configuration, with the default implementation just delegating to `SECRET_KEY` for backwards compatibility.
--
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.
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
[GitHub] [superset] ofekisr edited a comment on issue #15362: [SIP-70] Secret keys rotations and stop using single SECRET_KEY
Posted by GitBox <gi...@apache.org>.
ofekisr edited a comment on issue #15362:
URL: https://github.com/apache/superset/issues/15362#issuecomment-871501191
Hi @michael-s-molina
none of the solutions you suggest is a python based except for Confidant.
My solution support secret-keys-rotations assistance.
[keys-management](https://pypi.org/project/keys-management/) package does not claim to be responsible for storing keys, there are so many solutions for it
--
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.
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
[GitHub] [superset] michael-s-molina commented on issue #15362: [SIP-70] Secret keys rotations and stop using single SECRET_KEY
Posted by GitBox <gi...@apache.org>.
michael-s-molina commented on issue #15362:
URL: https://github.com/apache/superset/issues/15362#issuecomment-870061247
Thanks for the SIP @ofekisr.
Currently, we have some very mature solutions regarding the management of secret keys like [Keywhiz](https://github.com/square/keywhiz), [Vault](https://github.com/hashicorp/vault), [Confidant](https://github.com/lyft/confidant), [Knox](https://github.com/pinterest/knox), etc. Can you provide more context on which solutions were considered, why they don't fit our case, and why did you choose to implement your own package? It would be awesome to add this information to the **Rejected Alternatives** section of the SIP.
--
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.
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org