Repository navigation
Airflow 3.x: replace hard-coded JWT secret key with one read from a secret (or auto-generated) #639
Description
The experimental support for Airflow 3.x includes temporary use of a hard-coded constant for the JWT secret. This should be replaced with a value from a secret, which can be auto-generated if defined as such in the custom resource.
Further to https://github.com/stackabletech/decisions/issues/59, this will be done by creating the key in a named secret (if it does not already exist).
Previously
We can use the existing credentialsSecret by adding a JWT key:
---
apiVersion: v1
kind: Secret
metadata:
name: test-airflow-credentials
type: Opaque
stringData:
adminUser.username: airflow
...
jwt.key: thisISaJwTSECRET_1234
...
Two issues, discovered during the initial 3.x PR, should be investigated:
operator restart results in airflow cluster restart (that should not be happening)the session / token in the UI is still valid (no obvious explanation for this)
Metadata
Metadata
Assignees
Labels
No labels
Activity
lfrancke commentedon Aug 28, 2025
So, the suggestion is to adapt the Airflow CRD to either take a secret or auto-generate one?
That is fine with me in principle. Please make it consistent with however it's done in other operators (naming/structure) wise.
And can you let me know if the CRD change would warrant a new CRD version or not?
adwk67 commentedon Aug 29, 2025
The suggestion is to extend the existing secret that airflow already uses for various things (admin user, celery, postgresql). This would be a minimal and non-breaking change. But that is already different to how we do it for other operators (in that the secret is used for multiple things) and I think there was some discussion in the past to bring this in line. The Airflow CRD would not change at all.
lfrancke commentedon Aug 29, 2025
Ah! In that case it does make sense to consider briefly whether it's best practice to stuff multiple things in a secret or not. And to check what others are doing.