Remove JWT secrets from triggerer, worker and dag-processor

[deepujain]

Summary

Deployments that use the chart-managed jwt-secret (dag-processor, triggerer, workers) did not have the checksum/jwt-secret pod template annotation. When the JWT secret value was updated, those pods were not restarted automatically, unlike the api-server and scheduler which already had the annotation. This adds the same annotation (gated by semverCompare ">=3.0.0" and not .Values.jwtSecretName) so a change to the jwt-secret triggers a rollout.

Change

• chart/templates/dag-processor/dag-processor-deployment.yaml: Add checksum/jwt-secret annotation when Airflow >= 3.0 and chart manages the JWT secret.
• chart/templates/triggerer/triggerer-deployment.yaml: Same.
• chart/templates/workers/worker-deployment.yaml: Same.

Condition matches the pattern used in scheduler and api-server so behavior is consistent.

Fixes

Fixes #62146

[jscheffl]

Thanks for this fix... although I am not really sure if this is needed.

Triggerer, workers are just "clients" in repect to JWT tokens. They consume workload and execute. These components are not issuing new JWT. So if the JWT changes I assume these do not need a re-deployment.
The other way around I'd rather say, these two components should not have to know and should not have access to JWT at all to harden security.

For Dag Processor I am 80% sure only, this is running an internal API Server. In future this should get to be an API client as well. I assume no knowledge aout JWT is needed to process Dags. I assume a rotation is not needed there as well.

Other maintainer opinions welcome... maybe happy to be enlightened.

[deepujain]

Thanks for the review.

Triggerer and workers : They act as clients (consume/execute), they don’t issue JWTs, so they don’t need to be restarted when the JWT secret rotates. And from a security perspective, they ideally shouldn’t have access to the JWT secret at all.

Dag processor, Same idea: if it only runs the internal API server (and may become an API client later), it doesn’t need the JWT secret to process DAGs, so no need to restart it on JWT rotation.

The PR only added the checksum where the chart already injects the JWT secret (via the shared env when enableBuiltInSecretEnvVars.AIRFLOW__API_AUTH__JWT_SECRET is true), so the intent was “when the secret is rotated, restart these pods so they pick up the new value.”

[jscheffl]

Okay, yeah then... to correct this can we reverse it and rather say: The JWT should not be populated to Pods where not needed? The signal is that they have no checksum.

[deepujain]

Addressed the review: JWT secret is now only injected into api-server and scheduler (not dag-processor, triggerer, or workers). Removed the checksum/jwt-secret annotation from those three; updated the shared helper to use an IncludeJwtSecret flag and adjusted the helm test expectations. Rebased on main; ran prek (static checks) and helm tests (test_airflow_common, test_annotations, apiserver)
all passed.

Ready for another look once CI is green.

[jscheffl]

Looks much better and thanks for the rework!

Changed the title of PR to match current state - is this OK in your view?

Some small comments or I mis-understand.

[jscheffl]

The "wait-for-migrations" does not need the JWT secret in my view.

[jscheffl]

The "wait-for-migrations" does not need the JWT secret in my view.

[deepujain]

Agreed on wait-for-migrations: it only needs DB/config to run migrations, not the JWT secret. I’ve updated the chart so the wait-for-migrations init container uses IncludeJwtSecret: false in both api-server and scheduler

[Miretpl]

If JWT secret is not needed in all components, maybe we should remove it from standard_airflow_environment?