Affected Stackable version
26.3
Affected Apache Airflow version
3.1.6
Current and expected behavior
When deploying Airflow 3.x behind a reverse proxy (e.g. Istio, nginx), Uvicorn needs to be started with --proxy-headers to trust X-Forwarded-Proto, X-Forwarded-For and X-Forwarded-Port headers.
Without this flag, Airflow constructs OIDC redirect URIs and other absolute URLs using the internal HTTP scheme instead of the external HTTPS scheme, breaking OAuth2/OIDC authentication flows.
The Stackable Airflow operator generates the following container startup command for the webservers role:
airflow api-server &
There is no supported way to append --proxy-headers to this command.
UVICORN_PROXY_HEADERS=true does not work — Airflow starts Uvicorn programmatically via uvicorn.run(), not via the Uvicorn CLI, so Click's auto_envvar_prefix is never evaluated
AIRFLOW__WEBSERVER__ENABLE_PROXY_FIX does not exist in Airflow 3.x — it was a Werkzeug/WSGI config for the old Flask webserver which has been removed
There is no airflow.cfg config key or environment variable equivalent for --proxy-headers in Airflow 3.x (confirmed in Airflow source)
The only current workaround is podOverrides copying the entire generated bash startup script with the flag appended, which is fragile and will break on operator updates.
The AirflowCluster CRD should expose a way to enable proxy header trust, e.g.:
spec:
webservers:
config:
proxyHeaders: true
or at minimum document the supported podOverrides pattern for this use case.
Environment
Stackable Airflow Operator version: current stable
Airflow version: 3.1
Proxy: Istio Gateway with X-Forwarded-Proto: https set via VirtualService
Many thanks, Hilbert and Cloudius
Possible solution
No response
Additional context
No response
Environment
No response
Would you like to work on fixing this bug?
None
Affected Stackable version
26.3
Affected Apache Airflow version
3.1.6
Current and expected behavior
When deploying Airflow 3.x behind a reverse proxy (e.g. Istio, nginx), Uvicorn needs to be started with --proxy-headers to trust X-Forwarded-Proto, X-Forwarded-For and X-Forwarded-Port headers.
Without this flag, Airflow constructs OIDC redirect URIs and other absolute URLs using the internal HTTP scheme instead of the external HTTPS scheme, breaking OAuth2/OIDC authentication flows.
The Stackable Airflow operator generates the following container startup command for the webservers role:
airflow api-server &
There is no supported way to append --proxy-headers to this command.
UVICORN_PROXY_HEADERS=true does not work — Airflow starts Uvicorn programmatically via uvicorn.run(), not via the Uvicorn CLI, so Click's auto_envvar_prefix is never evaluated
AIRFLOW__WEBSERVER__ENABLE_PROXY_FIX does not exist in Airflow 3.x — it was a Werkzeug/WSGI config for the old Flask webserver which has been removed
There is no airflow.cfg config key or environment variable equivalent for --proxy-headers in Airflow 3.x (confirmed in Airflow source)
The only current workaround is podOverrides copying the entire generated bash startup script with the flag appended, which is fragile and will break on operator updates.
The AirflowCluster CRD should expose a way to enable proxy header trust, e.g.:
spec:
webservers:
config:
proxyHeaders: true
or at minimum document the supported podOverrides pattern for this use case.
Environment
Stackable Airflow Operator version: current stable
Airflow version: 3.1
Proxy: Istio Gateway with X-Forwarded-Proto: https set via VirtualService
Many thanks, Hilbert and Cloudius
Possible solution
No response
Additional context
No response
Environment
No response
Would you like to work on fixing this bug?
None