Enable configuration of cookie Path setting

[dontspamterry]

Description
Allow configuration of the Path portion of the cookie scope from the webserver. There are already cookie config settings introduced in 1.10.3, i.e.

cookie-secure
cookie-samesite

Proposing another config value be exposed called cookie-path

Use case / motivation
I have a scenario where I would like to share the same domain to access two different Airflow deploys via a path. For example

https://<domain>/airflow-stack-a
https://<domain>/airflow-stack-b

I have this model currently set up using Kubernetes, an nginx-ingress controller, and ingresses defined for each of my two stacks. In a web browser, I can access any of the aforementioned URLs, log in, and interact with Airflow. However, if I try to access the second URL for the second stack, the cookie presented by the webserver will have the same Domain and Path scope, causing interactions with the first stack to produce an Access Denied message and log me out. The cookie scope cannot be shared with the same Domain unless we have the ability to also set the Path in the Cookie.

For deployments in Kubernetes, we'd like to take advantage of an nginx-ingress controller such that we only need one LoadBalancer with the routing to each stack controlled by its Ingress. This would better fit into our model of having 10+ Airflow stacks on a single Kubernetes cluster without the need to have to provision 10+ LoadBalancers, one for each stack.

Seeking some guidance/input on whether this is a good idea or not.

Are you willing to submit a PR?
Yes! Just need to find the time to figure out what to do to set up a local/Breeze env, apply the change, test, and submit the PR. I'm a newbie to Python web development, but doing a quick glance of the code, looks like it should just involve adding support for a new config setting and then propagating this to SESSION_COOKIE_PATH in the Flask config.

Related Issues

[boring-cyborg[bot]]

Thanks for opening your first issue here! Be sure to follow the issue template!

[mik-laj]

This would better fit into our model of having 10+ Airflow stacks on a single Kubernetes cluster without the need to have to provision 10+ LoadBalancers, one for each stack.

You don't have to create new LoadBalancers for each domain. One Ingress can handle multiple domains. See: https://kubernetes.io/docs/concepts/services-networking/ingress/#name-based-virtual-hosting
This is a bit more problematic if you need to use multiple namespaces, but I know Nginx can handle this.

In newer versions of Kubernetes, a single Load Balancer will be able to handle multiple namespaces without too much trouble. See: https://kubernetes.io/blog/2021/04/22/evolving-kubernetes-networking-with-the-gateway-api/ and https://gateway-api.sigs.k8s.io/

[mik-laj]

looks like it should just involve adding support for a new config setting and then propagating this to SESSION_COOKIE_PATH in the Flask config.

You can pass any parameter. configuration file to Flask using the webserver_config.py file. See:

airflow/airflow/www/app.py

Line 75 in e4deb0f

flask_app.config.from_pyfile(settings.WEBSERVER_CONFIG, silent=True)

[dontspamterry]

This would better fit into our model of having 10+ Airflow stacks on a single Kubernetes cluster without the need to have to provision 10+ LoadBalancers, one for each stack.

You don't have to create new LoadBalancers for each domain. One Ingress can handle multiple domains. See: https://kubernetes.io/docs/concepts/services-networking/ingress/#name-based-virtual-hosting
This is a bit more problematic if you need to use multiple namespaces, but I know Nginx can handle this.

In newer versions of Kubernetes, a single Load Balancer will be able to handle multiple namespaces without too much trouble. See: https://kubernetes.io/blog/2021/04/22/evolving-kubernetes-networking-with-the-gateway-api/ and https://gateway-api.sigs.k8s.io/

Hi @mik-laj , my setup is presently a single LoadBalancer that is routing to two Airflow stacks, each in a different namespace. I have a Route53 record that serves as the friendly name in front of the LoadBalancer. I've tested that the Ingress routing works if I access my two stacks from two different web browsers such that the session cookie does not collide if one the same browser.

Thanks for pointing out that line of code. Maybe a code change won't be required after all 🤞