Airflow 3.x: replace hard-coded JWT secret key with one read from a secret (or auto-generated)

[adwk67]

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)

[lfrancke]

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]

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]

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.