Simple named list of routable namespace for Gateways

[shaneutt]

I have a controller which can start with a predefined list of namespaces by name which are the namespaces that controllers will support for routing operations. These namespaces have historically not been labeled, but instead simply referenced by name. In the Gateway implementation for this controller I'm considering how to define the FromNamespaces as labels are problematic for a variety of reasons, and I was considering this:

diff --git a/apis/v1alpha2/gateway_types.go b/apis/v1alpha2/gateway_types.go
index 398b122..12a2e22 100644
--- a/apis/v1alpha2/gateway_types.go
+++ b/apis/v1alpha2/gateway_types.go
@@ -405,6 +405,9 @@ const (
        // Only Routes in the same namespace as the Gateway may be attached to this
        // Gateway.
        NamespacesFromSame FromNamespaces = "Same"
+       // NamespacesFromNames indicates that only routes which are in the specific
+       // namespaces (provided by name) may be attached to this Gateway.
+       NamespacesFromNames FromNamespaces = "Names"
 )
 
 // RouteNamespaces indicate which namespaces Routes should be selected from.
@@ -430,6 +433,18 @@ type RouteNamespaces struct {
        //
        // +optional
        Selector *metav1.LabelSelector `json:"selector,omitempty"`
+
+       // Names must be specified when From is set to "Names". In that case, only
+       // Routes which are in the list of namespaces will be selected by this
+       // Gateway. This field is ignored for other values of "From".
+       //
+       // This can be paired with Selector in order to have that selector only
+       // apply to namespaces included in the list.
+       //
+       // Support: Core
+       //
+       // +optional
+       Names []string `json:"names,omitempty"`
 }
 
 // RouteGroupKind indicates the group and kind of a Route resource.

I would appreciate feedback on this, whether that be support for it or alternative suggestions.

Thanks!

[hbagdi]

This API could be potentially used in a security-sensitive setting. And in these settings, names are arbitrary, but labels are not. Which I find sometimes weird as well.
But I think that was the rationale for us to drop the Namespace name-based reference that we had before.

There could be other reasons that I can't seem to recall anymore. Maybe @robscott ?

[robscott]

I haven't kept up to date with this, but I think there have been some similar discussions/feature requests related to network policy. I think it would be useful to run this by the broader sig-net community to see what kind of prior art/discussions there are. This is one case where I'd lean towards labeling the namespaces instead of adding new fields to Gateway API.

@shaneutt Would having a list of namespace names enable new use cases or would it just make existing ones more convenient? Would matchExpressions combined with the kubernetes.io/metadata.name label on each namespace be a sufficient workaround? For example kubernetes.io/metatadata.name in (foo, bar) is theoretically valid, although rather verbose to represent with yaml.

[shaneutt]

Right now this is specifically coming up when dealing with pre-provisioned gateways (Gateway resources that will refer to previously existing underlying gateway servers, already serving Ingress) where there's already a known list of namespaces by name which are supported for Ingress. The most obvious options to deal with this appear to be:

1. ask the end-user to manually label the namespaces to support gateway resources, and forever after that manage those labels manually for any new namespaces or changes to existing namespaces.
2. automate the labeling of the existing namespaces

The former isn't great, and the latter has a bunch of it's own problems.

[robscott]

Could you just use a selector with the default namespace labels?

matchExpressions:
- key: "kubernetes.io/metadata.name"
  operator: "In"
  values: ["foo", "bar"]

[shaneutt]

Actually yes I think I can just do this matchExpressions. I totally overlooked this when I was originally asking and now I feel really silly. Thank you.

[robscott]

No worries, I also completely missed this option the first time around.