You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the Helm chart starts Airflow components using bash -c exec airflow some-command. In all cases there is no actual requirement for the shell for interpolation/substitution. The Helm chart should be updated to remove the requirement for a shell and instead start the Airflow components directly (this is similar to a prior issue which changed the Redis template in the same way).
Use case/motivation
Mainly, this would enable hardened (shell-less) images (i.e. third-party images such as Docker's hardened image) to be used as a drop-in replacement with the official chart. You can currently override all the main container's commands and arguments, but you cannot override, for example, the wait-for-airflow-migrations init container, which means you need a custom derivative of the chart. This is a very minor change that would not result in a functional change, but would create less friction for those who require distroless/hardened images.
I have to admit when I created this issue I forgot about the rather complex entrypoint present in the image. It seems that Docker is actually an outlier in not including a shell in their image (chainguard's has one). I guess this issue actually warrants more discussion because it would change the functionality of the chart. It seems to me the following bash functions would be skipped if you overrode the image entrypoint:
check_uid_gid
create_system_user_if_missing
set_pythonpath_for_root_user
wait_for_airflow_db
wait_for_celery_broker (for workers)
I think skipping create_system_user_if_missing would be problematic to skip because it is present for OpenShift compatibility. However, it might be possible to get around it by making sure fsGroup is set in the pod security contexts. Also, the log groomers sidecars require a shell (although they are disabled by default).
I think the main question is whether OpenShift compatibility would be broken if you override the entrypoint. For the Helm chart, I don't think most of the entrypoint script's features apply, except maybe waiting for the DB. I don't have an OpenShift environment to test in however.
Activity
amordoch commentedon Apr 17, 2026
I have to admit when I created this issue I forgot about the rather complex entrypoint present in the image. It seems that Docker is actually an outlier in not including a shell in their image (chainguard's has one). I guess this issue actually warrants more discussion because it would change the functionality of the chart. It seems to me the following bash functions would be skipped if you overrode the image entrypoint:
I think skipping
create_system_user_if_missingwould be problematic to skip because it is present for OpenShift compatibility. However, it might be possible to get around it by making surefsGroupis set in the pod security contexts. Also, the log groomers sidecars require a shell (although they are disabled by default).potiuk commentedon Apr 17, 2026
If you have some proposals how to implement it - feel free.
potiuk commentedon Apr 19, 2026
BTW. Yes - we actually even have an issue to convert our image to hardened images #59625 which this one should be a sub-task of.
amordoch commentedon Apr 21, 2026
I think the main question is whether OpenShift compatibility would be broken if you override the entrypoint. For the Helm chart, I don't think most of the entrypoint script's features apply, except maybe waiting for the DB. I don't have an OpenShift environment to test in however.