What does the Airflow Fernet key protect, and how do you rotate it?

The Airflow Fernet key encrypts passwords stored in connections and variables in the metadata database. Anyone with the key and a database copy can read them, and changing it without the rotation steps breaks decryption. Store it as a secret, and rotate it with the documented three step process.

What it does

The Airflow docs say Fernet protects passwords in connection and variable configuration, and guarantees that a password encrypted with it cannot be manipulated or read without the key. Fernet is symmetric, authenticated cryptography.

On first start, Airflow generates a configuration file with a unique key in the core section. You can override it with the AIRFLOW__CORE__FERNET_KEY environment variable.

What it does not do

It does not protect values that never go through connections or variables, such as secrets in environment variables or XCom. It also does not stop a Dag author from reading a connection at run time, because that is how tasks use credentials. See the Airflow security model post.

Where the key should live

Treat it like a database encryption key. Keep it out of images and repositories, and inject it from your secrets system at deploy. If you use an external secrets backend for connections, the metadata database holds fewer secrets, which reduces what the key guards. Our note on Airflow secrets backend lookup order shows how lookups work.

Rotation steps

The documentation gives this sequence:

1. Set the key to the new key followed by the old key, separated by a comma.
2. Run the rotate command, airflow rotate-fernet-key, which re-encrypts stored credentials under the new key.
3. Remove the old key so only the new key remains.

The docs warn that changing the key without this migration causes decryption of existing credentials to fail.

Lost or leaked key

The docs do not give guidance on loss or leak, so this part is our reasoning. If the key is lost and no old copy exists, stored passwords cannot be decrypted, and you re-enter them. If it leaks along with a database copy, treat every stored credential as exposed: rotate the key, then rotate the underlying passwords at their sources.

A short runbook

1. Confirm which deployments share a key, and which databases have been copied.
2. Generate a new key in your secrets system.
3. Run the three step rotation in a maintenance window.
4. If a leak is suspected, rotate the downstream credentials too.
5. Record the date for audit evidence.

Quick check

Safeguard compliance and evidence automation can collect rotation records as audit evidence. A free dependency scan is at gold.safeguard.sh/scan.

Sources

• Apache Airflow: Fernet

Last reviewed: 19 October 2026.