Why don't we consider adding namespace attributes to the selector to associate cross-namespace applications?

General Discussions
1

As thought at Name+label+selector scoping for configuration composition · Issue #1698 · kubernetes/kubernetes · GitHub.

My specific scenario is that I have the domain name gateway in namespace=ingress-nginx, and the ip gateway in namespace=app,

  1. Only one node
  2. I hope they can each use 80,443
  3. I plan to use LoadBalancer service to easily switch gateway endpoints by switching selectors.
    But I found that so far, selector can still only use the label of the current namespace.

So, we still need to stop the lb service first to free up 80,443. In the same way, this is similar to the hostPort solution

Why don’t we consider adding namespace attributes to the selector to associate cross-namespace applications?
Is there a better solution for my scenario?

2

Unrestricted cross-namespace access causes a confused-deputy scenario where one cluster user can bypass another user’s policies and expose the victim’s services when they did not intend to be exposed.

Gateway API has a more formal model for bi-directional “granting” of this.

1 Like
3

// Gateway API has a more formal model for bi-directional “granting” of this.
Great, can you share the link to this ability? :slight_smile:

4

anyone interested in this issue, please jump to Cross-Namespace routing - Kubernetes Gateway API.

I am investigating how this solution can be integrated into my scenario.:slight_smile: