Yep. Also to add - a little bit on `whys`. The root cause was that we had some inconsistency in behaviour of code duplication that Jens tried to sort out and it broke our tests. And for me the consistent approach described by Buğra is something we can nicely explain to users. Currently the behaviour of a few border conditions is not specified in the docs: https://airflow.apache.org/docs/apache-airflow/stable/security/secrets/fernet.html
Essentially, the proposal is that you can only disable fernet encryption by specifying an empty key - explicitly (but also warn). We believe it's a rather common producti case that airflow.cfg is either explicitly provided or the configuration folder is read-only. And there we could fall-back to no-encryption even if default behaviour is "generate unique key by default" - so we propose to opt for explicit failure, to avoid surprises and people not being aware that their sensitive data is **not** encrypted. The reason we raise it here is that this is a bit of a behaviour change. It's a "security hardening" and not intentional behaviour so we are **good** with SemVer and could do it in 3.2, however maybe there are some considerations that we have not thought about so wanted to get wider feedback. J. On Wed, Nov 12, 2025 at 1:37 AM Buğra Öztürk <[email protected]> wrote: > > Hello, > > Recent work on cleaning and standardising Fernet Key parsing introduced > some breaking changes. For example, empty Fernet keys ('') were raising > exceptions, especially in integration/end-to-end tests. Previously, even > though comments were specific to certain use cases, empty Fernet keys were > allowed and handled by NullFernet. This approach makes the system > unencrypted, similar to having just an empty password while logging in to a > system. We have reverted the breaking changes to enable room for discussion. > > We should have a generic, agreed-upon approach for Fernet key handling. > Where appropriate, big warnings and documentation should be added or > updated. For example, our Helm chart generates a Fernet key for deployment > if not provided (empty), whereas Docker Compose does not. > > There is also a PR related to providing a Fernet key for integration tests, > where tests should always have a key to run reliably. This may not cover > all cases, but it’s the first step toward making Fernet handling resilient > and consistent. > > Below is the approach discussed with a small group of people (Jarek Potiuk, > Jens Scheffler and me): > > Proposed Fernet Key parsing approach: > > > - > > Specified but empty ('')* →* use NullFernet (log a big warning that it’s > unencrypted). > - > > Not specified* →* attempt to generate and persist; fail if unable (e.g., > due to permissions). > - > > Specified and non-empty* →* attempt to use it; fail if format is invalid. > > > It would be great to collect any feedback or ideas. You can find some > useful links below. > Which part of the code mentioned: > https://github.com/apache/airflow/blob/main/airflow-core/src/airflow/models/crypto.py > Adding Fernet Key as default (followed by Amogh Desai with a good idea of > generating the fernet dynamically in the code for integration tests, which > will be updated): https://github.com/apache/airflow/pull/58112 > > > Kind regards, > > -- > Bugra Ozturk --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
