Restrict Communication from webserver to any other components

Hello,

I have very strictt security requirements in my environment. One of these requirements is the lack of communication between the Web server and any other component. We strictly isolate the Web server as an entry point for large-scale attacks and the limited ability to audit operations from other components. Ideally, in our scenario, the Web server would only read data from the database and not communicate with any other component in any configuration. Unfortunately, this is not possible at the moment. The webserver tries to communicate with the components, which ends up with a not user-friendly error

The Web server communicates with other components. This communication occurs in the following scenarios:
- When a Celery executor is used, Web server communicates with Redis to add a new task to the queue. See: https://github.com/apache/airflow/blob/950c16d0b0ab67bb7af11909de751029faf0313a/airflow/www/views.py#L1144
- When a Kubernetes executor is used, Web server communicates with K8S API to create a new Pod. See: https://github.com/apache/airflow/blob/950c16d0b0ab67bb7af11909de751029faf0313a/airflow/www/views.py#L1144
- When a Celery executor is used, Web server communicates with Worker to fetch logs. See: https://github.com/apache/airflow/blob/950c16d0b0ab67bb7af11909de751029faf0313a/airflow/utils/log/file_task_handler.py#L173
- When a Kubernetes executor is used, Web server communicates with Worker to K8S API. See: https://github.com/apache/airflow/blob/950c16d0b0ab67bb7af11909de751029faf0313a/airflow/utils/log/file_task_handler.py#L141

I would like this communication to be limited or, if it is not, a readable error message would be displayed, eg "This operation could not be performed due to security restrictions".

Best regards,
Kamil Breguła

Start by tracing the webserver operations linked in airflow/www/views.py and airflow/utils/log/file_task_handler.py. Compare the Celery/Redis and Kubernetes communication paths, then define a supported restriction or readable failure behavior for each scenario. Done means the webserver no longer performs prohibited communication, or consistently reports the stated security restriction.

Written by the indexing model from the issue text.