potiuk opened a new pull request, #72206:
URL: https://github.com/apache/airflow/pull/72206
`standard_airflow_environment` emitted the metadata database connection
unconditionally:
```yaml
{{- if
.Values.enableBuiltInSecretEnvVars.AIRFLOW__DATABASE__SQL_ALCHEMY_CONN }}
- name: AIRFLOW__DATABASE__SQL_ALCHEMY_CONN
```
Every component including that helper got it — including Celery worker pods
and the `base` container of the KubernetesExecutor task-pod template. Task code
inherits its container's environment, so Dag-author code could open a direct
connection to the metadata database.
In Airflow 3 a task pod has no functional need for it: the task SDK talks to
the Execution API, not the database.
## Approach
Callers now state whether the component uses the database, through an
`IncludeMetadataDb` flag on the include. This is the same shape as the existing
`IncludeJwtSecret` flag a few lines above, which already splits the JWT signing
secret by component need — so this follows the chart's own convention rather
than introducing a new one.
All 20 call sites are explicit: the thirteen components that talk to the
database pass `true`, the three pod-template sites pass `false`.
## The Celery worker case is conditional, and that is not cosmetic
Workers pass the existing `$keda` variable rather than a constant.
When KEDA autoscales the workers, its `ScaledObject` reads the connection
from an environment variable **on the worker pod spec** (`connectionFromEnv:
AIRFLOW_CONN_AIRFLOW_DB`, or `KEDA_DB_CONN`). KEDA has to be able to find it
there, so the variable cannot be removed while KEDA is doing the scaling —
removing it breaks autoscaling rather than hardening it.
KEDA is disabled by default, so a default deployment no longer carries the
credentials. A deployment that enables KEDA still puts a connection string in
the worker environment; `KEDA_DB_CONN` exists and can be pointed at a separate,
least-privilege connection, which is the mitigation available today. Closing
that remaining case properly would mean moving KEDA to a
`TriggerAuthentication` secret reference, which is a larger change and out of
scope here.
KubernetesExecutor task pods have no such exception — KEDA does not scale
them — so they lose the credentials unconditionally.
## Verification
Rendered end to end rather than only asserted in unit tests:
| Configuration | `AIRFLOW__DATABASE__SQL_ALCHEMY_CONN` /
`AIRFLOW_CONN_AIRFLOW_DB` in the worker deployment |
|---|---|
| CeleryExecutor (default) | **0** |
| CeleryExecutor + `keda.enabled=true` | 2 — kept, as KEDA requires |
`helm lint` clean; Celery, Kubernetes, Local and Celery+KEDA all render.
Tests: 33 KEDA, 41 `test_airflow_common`, 113 `test_pod_template_file`. Two
new regression tests — one per surface — both of which fail if the source
change is reverted. The two tests that assert the complete env list now give
the worker its own expected set, in the same style as the existing JWT
carve-out in that file.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
