You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@airflow.apache.org by "Aaryan123456679 (via GitHub)" <gi...@apache.org> on 2026/07/22 14:45:12 UTC
[PR] Document how to rotate the Fernet key with the Helm chart [airflow]
Aaryan123456679 opened a new pull request, #70242:
URL: https://github.com/apache/airflow/pull/70242
The Helm chart docs describe pointing at a custom Fernet key Secret via `fernetKeySecretName`, but never explain how to actually rotate the key once Airflow is deployed via the chart. This adds a "Fernet Key" section to the production guide covering the standard prepend/rotate/trim procedure, and notes that the chart-generated Secret is only created on `helm install` (via a pre-install hook) so a self-managed Secret is required to rotate at all.
closes: #18509
## Test plan
- [x] `breeze build-docs --package-filter helm-chart` succeeded with no warnings/errors
- [x] `prek run --from-ref upstream/main --stage pre-commit` passed (including the RST double-backtick check)
- [x] `prek run --from-ref upstream/main --stage manual` passed
- [x] `git diff upstream/main...HEAD --stat` confirms only the doc file and newsfragment changed
---
##### Was generative AI tooling used to co-author this PR?
- [X] Yes — Claude Code (Sonnet 5)
Generated-by: Claude Code (Sonnet 5) following [the guidelines](https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions)
--
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: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Document how to rotate the Fernet key with the Helm chart [airflow]
Posted by "Aaryan123456679 (via GitHub)" <gi...@apache.org>.
Aaryan123456679 commented on code in PR #70242:
URL: https://github.com/apache/airflow/pull/70242#discussion_r3632577380
##########
chart/docs/production-guide.rst:
##########
@@ -260,6 +260,59 @@ generated using the secret key has a short expiry time though. Make sure that ti
that you run Airflow components on is synchronized (for example using ntpd). You might get
"forbidden" errors when the logs are accessed otherwise.
+Fernet Key
+----------
+
+Airflow uses a Fernet key to encrypt sensitive data, such as connection passwords, stored in the metadata database.
+See :doc:`Fernet <apache-airflow:security/secrets/fernet>` for background on how this works. If you do not provide a
+key, the chart generates one and stores it in the ``<RELEASE_NAME>-fernet-key`` Kubernetes Secret the first time you
+run ``helm install``.
+
+.. warning::
+
+ The chart only creates that Secret on ``helm install`` -- it is not re-created or otherwise updated by
+ ``helm upgrade``. This applies both to the auto-generated key and to a key you pass through ``fernetKey`` in the
+ values file, so neither can be changed by re-running ``helm upgrade``. To rotate the Fernet key you need to manage
+ the Secret yourself, as described below.
+
+To provide your own key, either set ``fernetKey`` in the values file:
+
+.. code-block:: yaml
+ :caption: values.yaml
+
+ fernetKey: <fernet_key>
+
+.. warning::
+
+ Due to security concerns, it is advised to use a Kubernetes Secret instead of setting the Fernet key directly in the values file.
+
+or create your own Kubernetes Secret containing a ``fernet-key`` key with a base64-encoded value, and point the chart at it with ``fernetKeySecretName``:
+
+.. code-block:: bash
+
+ kubectl create secret generic my-fernet-key --from-literal="fernet-key=<fernet_key>"
Review Comment:
Good point, done -- added a note recommending managing the self-created Secret through the normal Infrastructure-as-Code process (GitOps repo, Sealed Secret, External Secrets Operator, etc.) so it isn't lost on a cluster migration or full redeploy.
---
Drafted-by: Claude Code (Sonnet 5) (no human review before posting)
##########
chart/docs/production-guide.rst:
##########
@@ -260,6 +260,59 @@ generated using the secret key has a short expiry time though. Make sure that ti
that you run Airflow components on is synchronized (for example using ntpd). You might get
"forbidden" errors when the logs are accessed otherwise.
+Fernet Key
+----------
+
+Airflow uses a Fernet key to encrypt sensitive data, such as connection passwords, stored in the metadata database.
+See :doc:`Fernet <apache-airflow:security/secrets/fernet>` for background on how this works. If you do not provide a
+key, the chart generates one and stores it in the ``<RELEASE_NAME>-fernet-key`` Kubernetes Secret the first time you
+run ``helm install``.
+
+.. warning::
+
+ The chart only creates that Secret on ``helm install`` -- it is not re-created or otherwise updated by
+ ``helm upgrade``. This applies both to the auto-generated key and to a key you pass through ``fernetKey`` in the
+ values file, so neither can be changed by re-running ``helm upgrade``. To rotate the Fernet key you need to manage
+ the Secret yourself, as described below.
+
+To provide your own key, either set ``fernetKey`` in the values file:
+
+.. code-block:: yaml
+ :caption: values.yaml
+
+ fernetKey: <fernet_key>
+
Review Comment:
Added an explicit warning: "Never commit a `values.yaml` containing a plaintext Fernet key to version control."
---
Drafted-by: Claude Code (Sonnet 5) (no human review before posting)
##########
chart/docs/production-guide.rst:
##########
@@ -260,6 +260,59 @@ generated using the secret key has a short expiry time though. Make sure that ti
that you run Airflow components on is synchronized (for example using ntpd). You might get
"forbidden" errors when the logs are accessed otherwise.
+Fernet Key
+----------
+
+Airflow uses a Fernet key to encrypt sensitive data, such as connection passwords, stored in the metadata database.
+See :doc:`Fernet <apache-airflow:security/secrets/fernet>` for background on how this works. If you do not provide a
+key, the chart generates one and stores it in the ``<RELEASE_NAME>-fernet-key`` Kubernetes Secret the first time you
+run ``helm install``.
+
+.. warning::
+
+ The chart only creates that Secret on ``helm install`` -- it is not re-created or otherwise updated by
+ ``helm upgrade``. This applies both to the auto-generated key and to a key you pass through ``fernetKey`` in the
+ values file, so neither can be changed by re-running ``helm upgrade``. To rotate the Fernet key you need to manage
+ the Secret yourself, as described below.
+
+To provide your own key, either set ``fernetKey`` in the values file:
+
+.. code-block:: yaml
+ :caption: values.yaml
+
+ fernetKey: <fernet_key>
+
+.. warning::
+
+ Due to security concerns, it is advised to use a Kubernetes Secret instead of setting the Fernet key directly in the values file.
+
+or create your own Kubernetes Secret containing a ``fernet-key`` key with a base64-encoded value, and point the chart at it with ``fernetKeySecretName``:
+
+.. code-block:: bash
+
+ kubectl create secret generic my-fernet-key --from-literal="fernet-key=<fernet_key>"
+
+.. code-block:: yaml
+ :caption: values.yaml
+
+ fernetKeySecretName: my-fernet-key
+
+Rotating the Fernet key
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+Once connections, variables and triggers have been encrypted with a Fernet key, changing the key outright makes the
+existing encrypted values unreadable. To rotate the key without losing access to them, follow the same procedure as
+:doc:`Rotating encryption keys <apache-airflow:security/secrets/fernet>`, applied to the Kubernetes Secret that backs
+``AIRFLOW__CORE__FERNET_KEY``:
+
+#. Make sure you are using a self-managed Secret through ``fernetKeySecretName`` -- as noted above, the
Review Comment:
Added explicit `kubectl create secret ... --dry-run=client -o yaml | kubectl apply -f -` commands to both rotation steps (setting `new_key,old_key`, then trimming back to `new_key`), reusing the same command shown in the creation snippet above so it updates the existing Secret in place.
---
Drafted-by: Claude Code (Sonnet 5) (no human review before posting)
--
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: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Document how to rotate the Fernet key with the Helm chart [airflow]
Posted by "github-actions[bot] (via GitHub)" <gi...@apache.org>.
github-actions[bot] commented on PR #70242:
URL: https://github.com/apache/airflow/pull/70242#issuecomment-5109660197
### Backport successfully created: chart/v1-2x-test
Note: As of [Merging PRs targeted for Airflow 3.X](https://github.com/apache/airflow/blob/main/dev/README_AIRFLOW3_DEV.md#merging-prs-targeted-for-airflow-3x)
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.
In matter of doubt please ask in [#release-management](https://apache-airflow.slack.com/archives/C03G9H97MM2) Slack channel.
<table>
<tr>
<th>Status</th>
<th>Branch</th>
<th>Result</th>
</tr>
<tr>
<td>✅</td>
<td>chart/v1-2x-test</td>
<td><a href="https://github.com/apache/airflow/pull/70644"><img src="https://img.shields.io/badge/PR-70644-blue" alt="PR Link"></a></td>
</tr>
</table>
--
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: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Document how to rotate the Fernet key with the Helm chart [airflow]
Posted by "Miretpl (via GitHub)" <gi...@apache.org>.
Miretpl commented on code in PR #70242:
URL: https://github.com/apache/airflow/pull/70242#discussion_r3641000045
##########
chart/newsfragments/70242.doc.rst:
##########
@@ -0,0 +1 @@
+Document how to rotate the Fernet key when deploying with the Helm chart.
Review Comment:
Newsfragment rather not needed for only doc change.
##########
chart/docs/production-guide.rst:
##########
@@ -260,6 +260,82 @@ generated using the secret key has a short expiry time though. Make sure that ti
that you run Airflow components on is synchronized (for example using ntpd). You might get
"forbidden" errors when the logs are accessed otherwise.
+Fernet Key
+----------
+
+Airflow uses a Fernet key to encrypt sensitive data, such as connection passwords, stored in the metadata database.
+See :doc:`Fernet <apache-airflow:security/secrets/fernet>` for background on how this works. If you do not provide a
+key, the chart generates one and stores it in the ``<RELEASE_NAME>-fernet-key`` Kubernetes Secret the first time you
+run ``helm install``.
+
+.. warning::
+
+ The chart only creates that Secret on ``helm install`` -- it is not re-created or otherwise updated by
+ ``helm upgrade``. This applies both to the auto-generated key and to a key you pass through ``fernetKey`` in the
+ values file, so neither can be changed by re-running ``helm upgrade``. To rotate the Fernet key you need to manage
+ the Secret yourself, as described below.
+
+To provide your own key, either set ``fernetKey`` in the values file:
+
+.. code-block:: yaml
+ :caption: values.yaml
+
+ fernetKey: <fernet_key>
+
+.. warning::
+
+ Due to security concerns, it is advised to use a Kubernetes Secret instead of setting the Fernet key directly in
+ the values file. Never commit a ``values.yaml`` containing a plaintext Fernet key to version control.
+
+or create your own Kubernetes Secret containing a ``fernet-key`` key with a base64-encoded value, and point the chart at it with ``fernetKeySecretName``:
+
+.. code-block:: bash
+
+ kubectl create secret generic my-fernet-key --from-literal="fernet-key=<fernet_key>"
+
+.. code-block:: yaml
+ :caption: values.yaml
+
+ fernetKeySecretName: my-fernet-key
+
+.. note::
+
+ ``kubectl create secret`` only creates an object in the cluster -- it is not tracked anywhere else. Manage this
+ Secret through your normal Infrastructure-as-Code process (for example a GitOps repository, a Sealed Secret, or
Review Comment:
```suggestion
Secret through your Infrastructure-as-a-Code process (for example, a GitOps repository, a Sealed Secret, or
```
##########
chart/docs/production-guide.rst:
##########
@@ -260,6 +260,82 @@ generated using the secret key has a short expiry time though. Make sure that ti
that you run Airflow components on is synchronized (for example using ntpd). You might get
"forbidden" errors when the logs are accessed otherwise.
+Fernet Key
+----------
+
+Airflow uses a Fernet key to encrypt sensitive data, such as connection passwords, stored in the metadata database.
+See :doc:`Fernet <apache-airflow:security/secrets/fernet>` for background on how this works. If you do not provide a
+key, the chart generates one and stores it in the ``<RELEASE_NAME>-fernet-key`` Kubernetes Secret the first time you
+run ``helm install``.
+
+.. warning::
+
+ The chart only creates that Secret on ``helm install`` -- it is not re-created or otherwise updated by
+ ``helm upgrade``. This applies both to the auto-generated key and to a key you pass through ``fernetKey`` in the
+ values file, so neither can be changed by re-running ``helm upgrade``. To rotate the Fernet key you need to manage
+ the Secret yourself, as described below.
+
+To provide your own key, either set ``fernetKey`` in the values file:
+
+.. code-block:: yaml
+ :caption: values.yaml
+
+ fernetKey: <fernet_key>
+
+.. warning::
+
+ Due to security concerns, it is advised to use a Kubernetes Secret instead of setting the Fernet key directly in
+ the values file. Never commit a ``values.yaml`` containing a plaintext Fernet key to version control.
+
+or create your own Kubernetes Secret containing a ``fernet-key`` key with a base64-encoded value, and point the chart at it with ``fernetKeySecretName``:
+
+.. code-block:: bash
+
+ kubectl create secret generic my-fernet-key --from-literal="fernet-key=<fernet_key>"
+
+.. code-block:: yaml
+ :caption: values.yaml
+
+ fernetKeySecretName: my-fernet-key
+
+.. note::
+
+ ``kubectl create secret`` only creates an object in the cluster -- it is not tracked anywhere else. Manage this
+ Secret through your normal Infrastructure-as-Code process (for example a GitOps repository, a Sealed Secret, or
+ an External Secrets Operator resource) so it is not lost on a cluster migration or a full redeploy.
+
+Rotating the Fernet key
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+Once connections, variables and triggers have been encrypted with a Fernet key, changing the key outright makes the
+existing encrypted values unreadable. To rotate the key without losing access to them, follow the same procedure as
+:doc:`Rotating encryption keys <apache-airflow:security/secrets/fernet>`, applied to the Kubernetes Secret that backs
+``AIRFLOW__CORE__FERNET_KEY``:
+
+#. Make sure you are using a self-managed Secret through ``fernetKeySecretName`` -- as noted above, the
+ chart-generated Secret cannot be updated through ``helm upgrade``.
+#. Update the ``fernet-key`` value in that Secret to a comma-separated list ``new_fernet_key,old_fernet_key``, using
+ the same ``kubectl create secret`` command as above with ``--dry-run=client -o yaml`` piped into ``kubectl apply``
+ so it updates the existing Secret in place instead of failing because it already exists:
+
+ .. code-block:: bash
+
+ kubectl create secret generic my-fernet-key \
+ --from-literal="fernet-key=new_fernet_key,old_fernet_key" \
+ --dry-run=client -o yaml | kubectl apply -f -
+
+ Then restart the Airflow components (for example with ``kubectl rollout restart``) so they pick up the new value --
+ Kubernetes does not refresh environment variables sourced from a Secret in already-running pods.
Review Comment:
```suggestion
Then restart the Airflow components (for example with ``kubectl rollout restart``) so they pick up the new value
```
I would say that this is generic Kubernetes knowledge, and it is rather unlikely for people without it to try to rotate Fernet Key.
##########
chart/docs/production-guide.rst:
##########
@@ -260,6 +260,82 @@ generated using the secret key has a short expiry time though. Make sure that ti
that you run Airflow components on is synchronized (for example using ntpd). You might get
"forbidden" errors when the logs are accessed otherwise.
+Fernet Key
+----------
+
+Airflow uses a Fernet key to encrypt sensitive data, such as connection passwords, stored in the metadata database.
+See :doc:`Fernet <apache-airflow:security/secrets/fernet>` for background on how this works. If you do not provide a
+key, the chart generates one and stores it in the ``<RELEASE_NAME>-fernet-key`` Kubernetes Secret the first time you
+run ``helm install``.
+
+.. warning::
+
+ The chart only creates that Secret on ``helm install`` -- it is not re-created or otherwise updated by
+ ``helm upgrade``. This applies both to the auto-generated key and to a key you pass through ``fernetKey`` in the
+ values file, so neither can be changed by re-running ``helm upgrade``. To rotate the Fernet key you need to manage
+ the Secret yourself, as described below.
Review Comment:
```suggestion
The chart only creates that Secret on ``helm install`` -- it is not re-created or otherwise updated by
``helm upgrade``. This applies both to the auto-generated key and to a key you pass through ``fernetKey`` in the values file. To rotate the Fernet key, you need to manage the Secret yourself, as described below.
```
##########
chart/docs/production-guide.rst:
##########
@@ -260,6 +260,82 @@ generated using the secret key has a short expiry time though. Make sure that ti
that you run Airflow components on is synchronized (for example using ntpd). You might get
"forbidden" errors when the logs are accessed otherwise.
+Fernet Key
+----------
+
+Airflow uses a Fernet key to encrypt sensitive data, such as connection passwords, stored in the metadata database.
+See :doc:`Fernet <apache-airflow:security/secrets/fernet>` for background on how this works. If you do not provide a
+key, the chart generates one and stores it in the ``<RELEASE_NAME>-fernet-key`` Kubernetes Secret the first time you
+run ``helm install``.
+
+.. warning::
+
+ The chart only creates that Secret on ``helm install`` -- it is not re-created or otherwise updated by
+ ``helm upgrade``. This applies both to the auto-generated key and to a key you pass through ``fernetKey`` in the
+ values file, so neither can be changed by re-running ``helm upgrade``. To rotate the Fernet key you need to manage
+ the Secret yourself, as described below.
+
+To provide your own key, either set ``fernetKey`` in the values file:
+
+.. code-block:: yaml
+ :caption: values.yaml
+
+ fernetKey: <fernet_key>
+
+.. warning::
+
+ Due to security concerns, it is advised to use a Kubernetes Secret instead of setting the Fernet key directly in
+ the values file. Never commit a ``values.yaml`` containing a plaintext Fernet key to version control.
+
+or create your own Kubernetes Secret containing a ``fernet-key`` key with a base64-encoded value, and point the chart at it with ``fernetKeySecretName``:
+
+.. code-block:: bash
+
+ kubectl create secret generic my-fernet-key --from-literal="fernet-key=<fernet_key>"
+
+.. code-block:: yaml
+ :caption: values.yaml
+
+ fernetKeySecretName: my-fernet-key
+
+.. note::
+
+ ``kubectl create secret`` only creates an object in the cluster -- it is not tracked anywhere else. Manage this
+ Secret through your normal Infrastructure-as-Code process (for example a GitOps repository, a Sealed Secret, or
+ an External Secrets Operator resource) so it is not lost on a cluster migration or a full redeploy.
+
+Rotating the Fernet key
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+Once connections, variables and triggers have been encrypted with a Fernet key, changing the key outright makes the
+existing encrypted values unreadable. To rotate the key without losing access to them, follow the same procedure as
+:doc:`Rotating encryption keys <apache-airflow:security/secrets/fernet>`, applied to the Kubernetes Secret that backs
+``AIRFLOW__CORE__FERNET_KEY``:
+
+#. Make sure you are using a self-managed Secret through ``fernetKeySecretName`` -- as noted above, the
+ chart-generated Secret cannot be updated through ``helm upgrade``.
+#. Update the ``fernet-key`` value in that Secret to a comma-separated list ``new_fernet_key,old_fernet_key``, using
+ the same ``kubectl create secret`` command as above with ``--dry-run=client -o yaml`` piped into ``kubectl apply``
+ so it updates the existing Secret in place instead of failing because it already exists:
+
+ .. code-block:: bash
+
+ kubectl create secret generic my-fernet-key \
+ --from-literal="fernet-key=new_fernet_key,old_fernet_key" \
+ --dry-run=client -o yaml | kubectl apply -f -
+
+ Then restart the Airflow components (for example with ``kubectl rollout restart``) so they pick up the new value --
+ Kubernetes does not refresh environment variables sourced from a Secret in already-running pods.
+#. Run ``airflow rotate-fernet-key`` to re-encrypt existing connections, variables and triggers with the new key.
+#. Update the Secret again, the same way, so it only contains ``new_fernet_key``, and restart the components once
+ more:
Review Comment:
```suggestion
#. Update the Secret, so it only contains ``new_fernet_key``, and restart the components once more:
```
##########
chart/docs/production-guide.rst:
##########
@@ -260,6 +260,82 @@ generated using the secret key has a short expiry time though. Make sure that ti
that you run Airflow components on is synchronized (for example using ntpd). You might get
"forbidden" errors when the logs are accessed otherwise.
+Fernet Key
+----------
+
+Airflow uses a Fernet key to encrypt sensitive data, such as connection passwords, stored in the metadata database.
+See :doc:`Fernet <apache-airflow:security/secrets/fernet>` for background on how this works. If you do not provide a
+key, the chart generates one and stores it in the ``<RELEASE_NAME>-fernet-key`` Kubernetes Secret the first time you
+run ``helm install``.
+
+.. warning::
+
+ The chart only creates that Secret on ``helm install`` -- it is not re-created or otherwise updated by
+ ``helm upgrade``. This applies both to the auto-generated key and to a key you pass through ``fernetKey`` in the
+ values file, so neither can be changed by re-running ``helm upgrade``. To rotate the Fernet key you need to manage
+ the Secret yourself, as described below.
+
+To provide your own key, either set ``fernetKey`` in the values file:
+
+.. code-block:: yaml
+ :caption: values.yaml
+
+ fernetKey: <fernet_key>
+
+.. warning::
+
+ Due to security concerns, it is advised to use a Kubernetes Secret instead of setting the Fernet key directly in
+ the values file. Never commit a ``values.yaml`` containing a plaintext Fernet key to version control.
+
+or create your own Kubernetes Secret containing a ``fernet-key`` key with a base64-encoded value, and point the chart at it with ``fernetKeySecretName``:
+
+.. code-block:: bash
+
+ kubectl create secret generic my-fernet-key --from-literal="fernet-key=<fernet_key>"
+
+.. code-block:: yaml
+ :caption: values.yaml
+
+ fernetKeySecretName: my-fernet-key
+
+.. note::
+
+ ``kubectl create secret`` only creates an object in the cluster -- it is not tracked anywhere else. Manage this
+ Secret through your normal Infrastructure-as-Code process (for example a GitOps repository, a Sealed Secret, or
+ an External Secrets Operator resource) so it is not lost on a cluster migration or a full redeploy.
+
+Rotating the Fernet key
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+Once connections, variables and triggers have been encrypted with a Fernet key, changing the key outright makes the
+existing encrypted values unreadable. To rotate the key without losing access to them, follow the same procedure as
+:doc:`Rotating encryption keys <apache-airflow:security/secrets/fernet>`, applied to the Kubernetes Secret that backs
+``AIRFLOW__CORE__FERNET_KEY``:
+
+#. Make sure you are using a self-managed Secret through ``fernetKeySecretName`` -- as noted above, the
+ chart-generated Secret cannot be updated through ``helm upgrade``.
+#. Update the ``fernet-key`` value in that Secret to a comma-separated list ``new_fernet_key,old_fernet_key``, using
+ the same ``kubectl create secret`` command as above with ``--dry-run=client -o yaml`` piped into ``kubectl apply``
+ so it updates the existing Secret in place instead of failing because it already exists:
+
+ .. code-block:: bash
+
+ kubectl create secret generic my-fernet-key \
+ --from-literal="fernet-key=new_fernet_key,old_fernet_key" \
+ --dry-run=client -o yaml | kubectl apply -f -
+
+ Then restart the Airflow components (for example with ``kubectl rollout restart``) so they pick up the new value --
+ Kubernetes does not refresh environment variables sourced from a Secret in already-running pods.
+#. Run ``airflow rotate-fernet-key`` to re-encrypt existing connections, variables and triggers with the new key.
Review Comment:
```suggestion
#. Run ``airflow rotate-fernet-key``, in one of the Airflow components pods, to re-encrypt existing connections, variables and triggers with the new key.
```
##########
chart/docs/production-guide.rst:
##########
@@ -260,6 +260,82 @@ generated using the secret key has a short expiry time though. Make sure that ti
that you run Airflow components on is synchronized (for example using ntpd). You might get
"forbidden" errors when the logs are accessed otherwise.
+Fernet Key
+----------
+
+Airflow uses a Fernet key to encrypt sensitive data, such as connection passwords, stored in the metadata database.
+See :doc:`Fernet <apache-airflow:security/secrets/fernet>` for background on how this works. If you do not provide a
+key, the chart generates one and stores it in the ``<RELEASE_NAME>-fernet-key`` Kubernetes Secret the first time you
+run ``helm install``.
+
+.. warning::
+
+ The chart only creates that Secret on ``helm install`` -- it is not re-created or otherwise updated by
+ ``helm upgrade``. This applies both to the auto-generated key and to a key you pass through ``fernetKey`` in the
+ values file, so neither can be changed by re-running ``helm upgrade``. To rotate the Fernet key you need to manage
+ the Secret yourself, as described below.
+
+To provide your own key, either set ``fernetKey`` in the values file:
+
+.. code-block:: yaml
+ :caption: values.yaml
+
+ fernetKey: <fernet_key>
+
+.. warning::
+
+ Due to security concerns, it is advised to use a Kubernetes Secret instead of setting the Fernet key directly in
+ the values file. Never commit a ``values.yaml`` containing a plaintext Fernet key to version control.
+
+or create your own Kubernetes Secret containing a ``fernet-key`` key with a base64-encoded value, and point the chart at it with ``fernetKeySecretName``:
+
+.. code-block:: bash
+
+ kubectl create secret generic my-fernet-key --from-literal="fernet-key=<fernet_key>"
+
+.. code-block:: yaml
+ :caption: values.yaml
+
+ fernetKeySecretName: my-fernet-key
+
+.. note::
+
+ ``kubectl create secret`` only creates an object in the cluster -- it is not tracked anywhere else. Manage this
+ Secret through your normal Infrastructure-as-Code process (for example a GitOps repository, a Sealed Secret, or
+ an External Secrets Operator resource) so it is not lost on a cluster migration or a full redeploy.
+
+Rotating the Fernet key
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+Once connections, variables and triggers have been encrypted with a Fernet key, changing the key outright makes the
+existing encrypted values unreadable. To rotate the key without losing access to them, follow the same procedure as
+:doc:`Rotating encryption keys <apache-airflow:security/secrets/fernet>`, applied to the Kubernetes Secret that backs
+``AIRFLOW__CORE__FERNET_KEY``:
+
+#. Make sure you are using a self-managed Secret through ``fernetKeySecretName`` -- as noted above, the
+ chart-generated Secret cannot be updated through ``helm upgrade``.
Review Comment:
```suggestion
#. Make sure you are using a self-managed Secret through ``fernetKeySecretName``
```
This information is close enough to this part of the text that it doesn't need to be repeated.
--
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: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Document how to rotate the Fernet key with the Helm chart [airflow]
Posted by "Miretpl (via GitHub)" <gi...@apache.org>.
Miretpl merged PR #70242:
URL: https://github.com/apache/airflow/pull/70242
--
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: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Document how to rotate the Fernet key with the Helm chart [airflow]
Posted by "bugraoz93 (via GitHub)" <gi...@apache.org>.
bugraoz93 commented on code in PR #70242:
URL: https://github.com/apache/airflow/pull/70242#discussion_r3631474308
##########
chart/docs/production-guide.rst:
##########
@@ -260,6 +260,59 @@ generated using the secret key has a short expiry time though. Make sure that ti
that you run Airflow components on is synchronized (for example using ntpd). You might get
"forbidden" errors when the logs are accessed otherwise.
+Fernet Key
+----------
+
+Airflow uses a Fernet key to encrypt sensitive data, such as connection passwords, stored in the metadata database.
+See :doc:`Fernet <apache-airflow:security/secrets/fernet>` for background on how this works. If you do not provide a
+key, the chart generates one and stores it in the ``<RELEASE_NAME>-fernet-key`` Kubernetes Secret the first time you
+run ``helm install``.
+
+.. warning::
+
+ The chart only creates that Secret on ``helm install`` -- it is not re-created or otherwise updated by
+ ``helm upgrade``. This applies both to the auto-generated key and to a key you pass through ``fernetKey`` in the
+ values file, so neither can be changed by re-running ``helm upgrade``. To rotate the Fernet key you need to manage
+ the Secret yourself, as described below.
+
+To provide your own key, either set ``fernetKey`` in the values file:
+
+.. code-block:: yaml
+ :caption: values.yaml
+
+ fernetKey: <fernet_key>
+
+.. warning::
+
+ Due to security concerns, it is advised to use a Kubernetes Secret instead of setting the Fernet key directly in the values file.
+
+or create your own Kubernetes Secret containing a ``fernet-key`` key with a base64-encoded value, and point the chart at it with ``fernetKeySecretName``:
+
+.. code-block:: bash
+
+ kubectl create secret generic my-fernet-key --from-literal="fernet-key=<fernet_key>"
Review Comment:
Maybe good to mention proposing an IaC approach to make it persistent, otherwise it can be gone on next cluster migration or full redeploy. At least, we should mention lifetime of it as infrastructure
##########
chart/docs/production-guide.rst:
##########
@@ -260,6 +260,59 @@ generated using the secret key has a short expiry time though. Make sure that ti
that you run Airflow components on is synchronized (for example using ntpd). You might get
"forbidden" errors when the logs are accessed otherwise.
+Fernet Key
+----------
+
+Airflow uses a Fernet key to encrypt sensitive data, such as connection passwords, stored in the metadata database.
+See :doc:`Fernet <apache-airflow:security/secrets/fernet>` for background on how this works. If you do not provide a
+key, the chart generates one and stores it in the ``<RELEASE_NAME>-fernet-key`` Kubernetes Secret the first time you
+run ``helm install``.
+
+.. warning::
+
+ The chart only creates that Secret on ``helm install`` -- it is not re-created or otherwise updated by
+ ``helm upgrade``. This applies both to the auto-generated key and to a key you pass through ``fernetKey`` in the
+ values file, so neither can be changed by re-running ``helm upgrade``. To rotate the Fernet key you need to manage
+ the Secret yourself, as described below.
+
+To provide your own key, either set ``fernetKey`` in the values file:
+
+.. code-block:: yaml
+ :caption: values.yaml
+
+ fernetKey: <fernet_key>
+
+.. warning::
+
+ Due to security concerns, it is advised to use a Kubernetes Secret instead of setting the Fernet key directly in the values file.
+
+or create your own Kubernetes Secret containing a ``fernet-key`` key with a base64-encoded value, and point the chart at it with ``fernetKeySecretName``:
+
+.. code-block:: bash
+
+ kubectl create secret generic my-fernet-key --from-literal="fernet-key=<fernet_key>"
+
+.. code-block:: yaml
+ :caption: values.yaml
+
+ fernetKeySecretName: my-fernet-key
+
+Rotating the Fernet key
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+Once connections, variables and triggers have been encrypted with a Fernet key, changing the key outright makes the
+existing encrypted values unreadable. To rotate the key without losing access to them, follow the same procedure as
+:doc:`Rotating encryption keys <apache-airflow:security/secrets/fernet>`, applied to the Kubernetes Secret that backs
+``AIRFLOW__CORE__FERNET_KEY``:
+
+#. Make sure you are using a self-managed Secret through ``fernetKeySecretName`` -- as noted above, the
Review Comment:
We should mention how to update secrets too with kubectl since the creation is like that, we can add update statement too or refer above snippet please
##########
chart/docs/production-guide.rst:
##########
@@ -260,6 +260,59 @@ generated using the secret key has a short expiry time though. Make sure that ti
that you run Airflow components on is synchronized (for example using ntpd). You might get
"forbidden" errors when the logs are accessed otherwise.
+Fernet Key
+----------
+
+Airflow uses a Fernet key to encrypt sensitive data, such as connection passwords, stored in the metadata database.
+See :doc:`Fernet <apache-airflow:security/secrets/fernet>` for background on how this works. If you do not provide a
+key, the chart generates one and stores it in the ``<RELEASE_NAME>-fernet-key`` Kubernetes Secret the first time you
+run ``helm install``.
+
+.. warning::
+
+ The chart only creates that Secret on ``helm install`` -- it is not re-created or otherwise updated by
+ ``helm upgrade``. This applies both to the auto-generated key and to a key you pass through ``fernetKey`` in the
+ values file, so neither can be changed by re-running ``helm upgrade``. To rotate the Fernet key you need to manage
+ the Secret yourself, as described below.
+
+To provide your own key, either set ``fernetKey`` in the values file:
+
+.. code-block:: yaml
+ :caption: values.yaml
+
+ fernetKey: <fernet_key>
+
Review Comment:
Let add never add plain secret into values.yaml as a warning as this is sensitive
--
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: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Document how to rotate the Fernet key with the Helm chart [airflow]
Posted by "Aaryan123456679 (via GitHub)" <gi...@apache.org>.
Aaryan123456679 commented on code in PR #70242:
URL: https://github.com/apache/airflow/pull/70242#discussion_r3644744921
##########
chart/newsfragments/70242.doc.rst:
##########
@@ -0,0 +1 @@
+Document how to rotate the Fernet key when deploying with the Helm chart.
Review Comment:
Removed the newsfragment -- agreed, a docs-only change doesn't need one.
##########
chart/docs/production-guide.rst:
##########
@@ -260,6 +260,82 @@ generated using the secret key has a short expiry time though. Make sure that ti
that you run Airflow components on is synchronized (for example using ntpd). You might get
"forbidden" errors when the logs are accessed otherwise.
+Fernet Key
+----------
+
+Airflow uses a Fernet key to encrypt sensitive data, such as connection passwords, stored in the metadata database.
+See :doc:`Fernet <apache-airflow:security/secrets/fernet>` for background on how this works. If you do not provide a
+key, the chart generates one and stores it in the ``<RELEASE_NAME>-fernet-key`` Kubernetes Secret the first time you
+run ``helm install``.
+
+.. warning::
+
+ The chart only creates that Secret on ``helm install`` -- it is not re-created or otherwise updated by
+ ``helm upgrade``. This applies both to the auto-generated key and to a key you pass through ``fernetKey`` in the
+ values file, so neither can be changed by re-running ``helm upgrade``. To rotate the Fernet key you need to manage
+ the Secret yourself, as described below.
Review Comment:
Applied.
##########
chart/docs/production-guide.rst:
##########
@@ -260,6 +260,82 @@ generated using the secret key has a short expiry time though. Make sure that ti
that you run Airflow components on is synchronized (for example using ntpd). You might get
"forbidden" errors when the logs are accessed otherwise.
+Fernet Key
+----------
+
+Airflow uses a Fernet key to encrypt sensitive data, such as connection passwords, stored in the metadata database.
+See :doc:`Fernet <apache-airflow:security/secrets/fernet>` for background on how this works. If you do not provide a
+key, the chart generates one and stores it in the ``<RELEASE_NAME>-fernet-key`` Kubernetes Secret the first time you
+run ``helm install``.
+
+.. warning::
+
+ The chart only creates that Secret on ``helm install`` -- it is not re-created or otherwise updated by
+ ``helm upgrade``. This applies both to the auto-generated key and to a key you pass through ``fernetKey`` in the
+ values file, so neither can be changed by re-running ``helm upgrade``. To rotate the Fernet key you need to manage
+ the Secret yourself, as described below.
+
+To provide your own key, either set ``fernetKey`` in the values file:
+
+.. code-block:: yaml
+ :caption: values.yaml
+
+ fernetKey: <fernet_key>
+
+.. warning::
+
+ Due to security concerns, it is advised to use a Kubernetes Secret instead of setting the Fernet key directly in
+ the values file. Never commit a ``values.yaml`` containing a plaintext Fernet key to version control.
+
+or create your own Kubernetes Secret containing a ``fernet-key`` key with a base64-encoded value, and point the chart at it with ``fernetKeySecretName``:
+
+.. code-block:: bash
+
+ kubectl create secret generic my-fernet-key --from-literal="fernet-key=<fernet_key>"
+
+.. code-block:: yaml
+ :caption: values.yaml
+
+ fernetKeySecretName: my-fernet-key
+
+.. note::
+
+ ``kubectl create secret`` only creates an object in the cluster -- it is not tracked anywhere else. Manage this
+ Secret through your normal Infrastructure-as-Code process (for example a GitOps repository, a Sealed Secret, or
Review Comment:
Applied.
##########
chart/docs/production-guide.rst:
##########
@@ -260,6 +260,82 @@ generated using the secret key has a short expiry time though. Make sure that ti
that you run Airflow components on is synchronized (for example using ntpd). You might get
"forbidden" errors when the logs are accessed otherwise.
+Fernet Key
+----------
+
+Airflow uses a Fernet key to encrypt sensitive data, such as connection passwords, stored in the metadata database.
+See :doc:`Fernet <apache-airflow:security/secrets/fernet>` for background on how this works. If you do not provide a
+key, the chart generates one and stores it in the ``<RELEASE_NAME>-fernet-key`` Kubernetes Secret the first time you
+run ``helm install``.
+
+.. warning::
+
+ The chart only creates that Secret on ``helm install`` -- it is not re-created or otherwise updated by
+ ``helm upgrade``. This applies both to the auto-generated key and to a key you pass through ``fernetKey`` in the
+ values file, so neither can be changed by re-running ``helm upgrade``. To rotate the Fernet key you need to manage
+ the Secret yourself, as described below.
+
+To provide your own key, either set ``fernetKey`` in the values file:
+
+.. code-block:: yaml
+ :caption: values.yaml
+
+ fernetKey: <fernet_key>
+
+.. warning::
+
+ Due to security concerns, it is advised to use a Kubernetes Secret instead of setting the Fernet key directly in
+ the values file. Never commit a ``values.yaml`` containing a plaintext Fernet key to version control.
+
+or create your own Kubernetes Secret containing a ``fernet-key`` key with a base64-encoded value, and point the chart at it with ``fernetKeySecretName``:
+
+.. code-block:: bash
+
+ kubectl create secret generic my-fernet-key --from-literal="fernet-key=<fernet_key>"
+
+.. code-block:: yaml
+ :caption: values.yaml
+
+ fernetKeySecretName: my-fernet-key
+
+.. note::
+
+ ``kubectl create secret`` only creates an object in the cluster -- it is not tracked anywhere else. Manage this
+ Secret through your normal Infrastructure-as-Code process (for example a GitOps repository, a Sealed Secret, or
+ an External Secrets Operator resource) so it is not lost on a cluster migration or a full redeploy.
+
+Rotating the Fernet key
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+Once connections, variables and triggers have been encrypted with a Fernet key, changing the key outright makes the
+existing encrypted values unreadable. To rotate the key without losing access to them, follow the same procedure as
+:doc:`Rotating encryption keys <apache-airflow:security/secrets/fernet>`, applied to the Kubernetes Secret that backs
+``AIRFLOW__CORE__FERNET_KEY``:
+
+#. Make sure you are using a self-managed Secret through ``fernetKeySecretName`` -- as noted above, the
+ chart-generated Secret cannot be updated through ``helm upgrade``.
Review Comment:
Applied -- removed the repeated helm upgrade note.
##########
chart/docs/production-guide.rst:
##########
@@ -260,6 +260,82 @@ generated using the secret key has a short expiry time though. Make sure that ti
that you run Airflow components on is synchronized (for example using ntpd). You might get
"forbidden" errors when the logs are accessed otherwise.
+Fernet Key
+----------
+
+Airflow uses a Fernet key to encrypt sensitive data, such as connection passwords, stored in the metadata database.
+See :doc:`Fernet <apache-airflow:security/secrets/fernet>` for background on how this works. If you do not provide a
+key, the chart generates one and stores it in the ``<RELEASE_NAME>-fernet-key`` Kubernetes Secret the first time you
+run ``helm install``.
+
+.. warning::
+
+ The chart only creates that Secret on ``helm install`` -- it is not re-created or otherwise updated by
+ ``helm upgrade``. This applies both to the auto-generated key and to a key you pass through ``fernetKey`` in the
+ values file, so neither can be changed by re-running ``helm upgrade``. To rotate the Fernet key you need to manage
+ the Secret yourself, as described below.
+
+To provide your own key, either set ``fernetKey`` in the values file:
+
+.. code-block:: yaml
+ :caption: values.yaml
+
+ fernetKey: <fernet_key>
+
+.. warning::
+
+ Due to security concerns, it is advised to use a Kubernetes Secret instead of setting the Fernet key directly in
+ the values file. Never commit a ``values.yaml`` containing a plaintext Fernet key to version control.
+
+or create your own Kubernetes Secret containing a ``fernet-key`` key with a base64-encoded value, and point the chart at it with ``fernetKeySecretName``:
+
+.. code-block:: bash
+
+ kubectl create secret generic my-fernet-key --from-literal="fernet-key=<fernet_key>"
+
+.. code-block:: yaml
+ :caption: values.yaml
+
+ fernetKeySecretName: my-fernet-key
+
+.. note::
+
+ ``kubectl create secret`` only creates an object in the cluster -- it is not tracked anywhere else. Manage this
+ Secret through your normal Infrastructure-as-Code process (for example a GitOps repository, a Sealed Secret, or
+ an External Secrets Operator resource) so it is not lost on a cluster migration or a full redeploy.
+
+Rotating the Fernet key
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+Once connections, variables and triggers have been encrypted with a Fernet key, changing the key outright makes the
+existing encrypted values unreadable. To rotate the key without losing access to them, follow the same procedure as
+:doc:`Rotating encryption keys <apache-airflow:security/secrets/fernet>`, applied to the Kubernetes Secret that backs
+``AIRFLOW__CORE__FERNET_KEY``:
+
+#. Make sure you are using a self-managed Secret through ``fernetKeySecretName`` -- as noted above, the
+ chart-generated Secret cannot be updated through ``helm upgrade``.
+#. Update the ``fernet-key`` value in that Secret to a comma-separated list ``new_fernet_key,old_fernet_key``, using
+ the same ``kubectl create secret`` command as above with ``--dry-run=client -o yaml`` piped into ``kubectl apply``
+ so it updates the existing Secret in place instead of failing because it already exists:
+
+ .. code-block:: bash
+
+ kubectl create secret generic my-fernet-key \
+ --from-literal="fernet-key=new_fernet_key,old_fernet_key" \
+ --dry-run=client -o yaml | kubectl apply -f -
+
+ Then restart the Airflow components (for example with ``kubectl rollout restart``) so they pick up the new value --
+ Kubernetes does not refresh environment variables sourced from a Secret in already-running pods.
Review Comment:
Applied.
##########
chart/docs/production-guide.rst:
##########
@@ -260,6 +260,82 @@ generated using the secret key has a short expiry time though. Make sure that ti
that you run Airflow components on is synchronized (for example using ntpd). You might get
"forbidden" errors when the logs are accessed otherwise.
+Fernet Key
+----------
+
+Airflow uses a Fernet key to encrypt sensitive data, such as connection passwords, stored in the metadata database.
+See :doc:`Fernet <apache-airflow:security/secrets/fernet>` for background on how this works. If you do not provide a
+key, the chart generates one and stores it in the ``<RELEASE_NAME>-fernet-key`` Kubernetes Secret the first time you
+run ``helm install``.
+
+.. warning::
+
+ The chart only creates that Secret on ``helm install`` -- it is not re-created or otherwise updated by
+ ``helm upgrade``. This applies both to the auto-generated key and to a key you pass through ``fernetKey`` in the
+ values file, so neither can be changed by re-running ``helm upgrade``. To rotate the Fernet key you need to manage
+ the Secret yourself, as described below.
+
+To provide your own key, either set ``fernetKey`` in the values file:
+
+.. code-block:: yaml
+ :caption: values.yaml
+
+ fernetKey: <fernet_key>
+
+.. warning::
+
+ Due to security concerns, it is advised to use a Kubernetes Secret instead of setting the Fernet key directly in
+ the values file. Never commit a ``values.yaml`` containing a plaintext Fernet key to version control.
+
+or create your own Kubernetes Secret containing a ``fernet-key`` key with a base64-encoded value, and point the chart at it with ``fernetKeySecretName``:
+
+.. code-block:: bash
+
+ kubectl create secret generic my-fernet-key --from-literal="fernet-key=<fernet_key>"
+
+.. code-block:: yaml
+ :caption: values.yaml
+
+ fernetKeySecretName: my-fernet-key
+
+.. note::
+
+ ``kubectl create secret`` only creates an object in the cluster -- it is not tracked anywhere else. Manage this
+ Secret through your normal Infrastructure-as-Code process (for example a GitOps repository, a Sealed Secret, or
+ an External Secrets Operator resource) so it is not lost on a cluster migration or a full redeploy.
+
+Rotating the Fernet key
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+Once connections, variables and triggers have been encrypted with a Fernet key, changing the key outright makes the
+existing encrypted values unreadable. To rotate the key without losing access to them, follow the same procedure as
+:doc:`Rotating encryption keys <apache-airflow:security/secrets/fernet>`, applied to the Kubernetes Secret that backs
+``AIRFLOW__CORE__FERNET_KEY``:
+
+#. Make sure you are using a self-managed Secret through ``fernetKeySecretName`` -- as noted above, the
+ chart-generated Secret cannot be updated through ``helm upgrade``.
+#. Update the ``fernet-key`` value in that Secret to a comma-separated list ``new_fernet_key,old_fernet_key``, using
+ the same ``kubectl create secret`` command as above with ``--dry-run=client -o yaml`` piped into ``kubectl apply``
+ so it updates the existing Secret in place instead of failing because it already exists:
+
+ .. code-block:: bash
+
+ kubectl create secret generic my-fernet-key \
+ --from-literal="fernet-key=new_fernet_key,old_fernet_key" \
+ --dry-run=client -o yaml | kubectl apply -f -
+
+ Then restart the Airflow components (for example with ``kubectl rollout restart``) so they pick up the new value --
+ Kubernetes does not refresh environment variables sourced from a Secret in already-running pods.
+#. Run ``airflow rotate-fernet-key`` to re-encrypt existing connections, variables and triggers with the new key.
Review Comment:
Applied.
##########
chart/docs/production-guide.rst:
##########
@@ -260,6 +260,82 @@ generated using the secret key has a short expiry time though. Make sure that ti
that you run Airflow components on is synchronized (for example using ntpd). You might get
"forbidden" errors when the logs are accessed otherwise.
+Fernet Key
+----------
+
+Airflow uses a Fernet key to encrypt sensitive data, such as connection passwords, stored in the metadata database.
+See :doc:`Fernet <apache-airflow:security/secrets/fernet>` for background on how this works. If you do not provide a
+key, the chart generates one and stores it in the ``<RELEASE_NAME>-fernet-key`` Kubernetes Secret the first time you
+run ``helm install``.
+
+.. warning::
+
+ The chart only creates that Secret on ``helm install`` -- it is not re-created or otherwise updated by
+ ``helm upgrade``. This applies both to the auto-generated key and to a key you pass through ``fernetKey`` in the
+ values file, so neither can be changed by re-running ``helm upgrade``. To rotate the Fernet key you need to manage
+ the Secret yourself, as described below.
+
+To provide your own key, either set ``fernetKey`` in the values file:
+
+.. code-block:: yaml
+ :caption: values.yaml
+
+ fernetKey: <fernet_key>
+
+.. warning::
+
+ Due to security concerns, it is advised to use a Kubernetes Secret instead of setting the Fernet key directly in
+ the values file. Never commit a ``values.yaml`` containing a plaintext Fernet key to version control.
+
+or create your own Kubernetes Secret containing a ``fernet-key`` key with a base64-encoded value, and point the chart at it with ``fernetKeySecretName``:
+
+.. code-block:: bash
+
+ kubectl create secret generic my-fernet-key --from-literal="fernet-key=<fernet_key>"
+
+.. code-block:: yaml
+ :caption: values.yaml
+
+ fernetKeySecretName: my-fernet-key
+
+.. note::
+
+ ``kubectl create secret`` only creates an object in the cluster -- it is not tracked anywhere else. Manage this
+ Secret through your normal Infrastructure-as-Code process (for example a GitOps repository, a Sealed Secret, or
+ an External Secrets Operator resource) so it is not lost on a cluster migration or a full redeploy.
+
+Rotating the Fernet key
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+Once connections, variables and triggers have been encrypted with a Fernet key, changing the key outright makes the
+existing encrypted values unreadable. To rotate the key without losing access to them, follow the same procedure as
+:doc:`Rotating encryption keys <apache-airflow:security/secrets/fernet>`, applied to the Kubernetes Secret that backs
+``AIRFLOW__CORE__FERNET_KEY``:
+
+#. Make sure you are using a self-managed Secret through ``fernetKeySecretName`` -- as noted above, the
+ chart-generated Secret cannot be updated through ``helm upgrade``.
+#. Update the ``fernet-key`` value in that Secret to a comma-separated list ``new_fernet_key,old_fernet_key``, using
+ the same ``kubectl create secret`` command as above with ``--dry-run=client -o yaml`` piped into ``kubectl apply``
+ so it updates the existing Secret in place instead of failing because it already exists:
+
+ .. code-block:: bash
+
+ kubectl create secret generic my-fernet-key \
+ --from-literal="fernet-key=new_fernet_key,old_fernet_key" \
+ --dry-run=client -o yaml | kubectl apply -f -
+
+ Then restart the Airflow components (for example with ``kubectl rollout restart``) so they pick up the new value --
+ Kubernetes does not refresh environment variables sourced from a Secret in already-running pods.
+#. Run ``airflow rotate-fernet-key`` to re-encrypt existing connections, variables and triggers with the new key.
+#. Update the Secret again, the same way, so it only contains ``new_fernet_key``, and restart the components once
+ more:
Review Comment:
Applied.
--
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: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org