-
Notifications
You must be signed in to change notification settings - Fork 14.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support AES256 encryption of sensitive params #45195
base: main
Are you sure you want to change the base?
Support AES256 encryption of sensitive params #45195
Conversation
Starting with a draft with a POC. Please, let me know if this is a good direction. |
692732e
to
56d5d47
Compare
Implements support for `_ENCRYPTED` versions of env variables and `_encrypted` versions of config params. Those would be encrypted using a parameter `params_encryption_aes256_key` (which can be retrieved from a secret for example). The params encryption key itself doesn't support encrypted suffix, or it'd create an infinite recursion. closes: apache#45194 Signed-off-by: Andrii Korotkov <andrii.korotkov@verkada.com>
56d5d47
to
c2ca77e
Compare
Before we go any deeper. I would like to dicuss the reasoning of doing it I simply think it does not achieve any "more" security than we currently have. Both parameters and decryption key are necesarlly in the same environment and you neeed to have access to both - if you don't, then you cannot decrypt them. We already have encryption using fernet key (symmetric) but there we use it to encrypt the database values, becuase then for example if you have only access to database backups/dumps or database itself, you are not able to decrypt it without access to the configuraiton of Airlfow - where the fernet key is stored. So here values and keys are kept in two separate "spaces" / "security scopes/perimeters". We also already support In this case and your proposal, seemlngly both encrypted values and the key are supposed to be stored in the same "space" - so if you have access to one, you have access to other, and you can use the key to decrypt the values, so at best it's security-by-obscurity. Do you see any scenario where someone could get hold of the values but not the key - where it could be helpful? What kind of attacks and which actor behaviours it would prevent ? It might be you have some concrete use cases in mind that I don't know. |
Sure. I think of this as more of a convenience feature rather than a feature that heightens a security.
I'd have to think separately on how to work with secret things mounted as files, e.g. Please, let me know if these arguments make sense. Happy to discuss further. |
Implements support for
_ENCRYPTED
versions of env variables and_encrypted
versions of config params. Those would be encrypted using a parameterparams_encryption_aes256_key
(which can be retrieved from a secret for example). The params encryption key itself doesn't support encrypted suffix, or it'd create an infinite recursion.closes: #45194
^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named
{pr_number}.significant.rst
or{issue_number}.significant.rst
, in newsfragments.