Enable restrictions on tenant namespaces labels

[GlassOfWhiskey]

As of today (Kubernetes 1.20.x) NetworkPolicy resources can only address namespaces by their labels, not by their names. But if tenant admins can assign arbitrary labels to their namespaces, NetworkPolicy resources can easily be bypassed.

A common use case when it is necessary to allow ingress traffic from a different namespace is when exposing an IngressController resource to tenant users. Supposing to use Contour, we have a projectcontour namespace that must be able to forward packets to a backend service located in a tenant-related namespace tenant-ns.

Wanting to allow this kind of communication, a cluster admin must create a tenant with a networkPolicy of this kind:

ingress:
  from:
    - podSelector:
        matchLabels:
          app: envoy
      namespaceSelector:
        matchLabels:
          name: projectcontour
      ...
podSelector: {}

Now suppose to have another tenant called malicioustenant. If the tenant admin creates a namespace

apiVersion: v1
kind: Namespace
metadata:
  labels:
    name: projectcontour
  name: malicioustenant-ns

then traffic from the malicioustenant-ns is not filtered by the previous NetworkPolicy.

It is true that this flaw can be removed by introducing ad-hoc policies, e.g. using the OPA Gatekeeper, but the frequent nature of this use case (every cluster equipped with an IngressController needs this feature) makes it convenient to allows Capsule users to directly manage this aspect in Capsule.

Commonly, the protected labels are common to the entire cluster and not tenant-related. Therefore, the best solution could probably be to add something like a protectedNamespaceLabelsList or protectedNamespaceLabelsRegex configurable option in the Helm chart, as has been done for the namespace names with the protectedNamespaceRegex option.

[prometherion]

Thanks for the feedback, I'm marking this as a bug since it could lead to a big attack surface especially considering how network segregation through NetworkPolicy resources is mandatory in multi-tenant contexts.