Skip to main content
Version: Next 🚧

Namespace Boundary Enforcement

Policy: Namespace Boundary Enforcement​

By default, pods in different namespaces, and with different labels, can communicate. To avoid this behavior, it is necessary to create additional rules to restrict it.

This new label, NeuvectorNamespaceBoundary, allows you to implement a restriction to the communication between pods belonging to the same namespace or sharing natural boundaries (i.e. part of the same application).

Enable/disable namespace boundary enforcement​

To enable or disable this policy against a namespace, you need to set the following label:

  • Enable Namespace Boundary Enforcement

kubectl label namespace <namespace> NeuvectorNamespaceBoundary=enabled

  • Disable Namespace Boundary Enforcement

kubectl label namespace <namespace> NeuvectorNamespaceBoundary=disabled

  • [Optional] Remove the label > This will disable Namespace Boundary Enforcement

kubectl label namespace <namespace> NeuvectorNamespaceBoundary-

Example​

Example policy ingress/egress traffic on a namespace’s natural boundary.

eg.)

There are 2 namespaces ns1, ns2.

In ns1 there is pod1(with label=app1,label=one) and pod2(with label=app2, label=two),

In ns2 there is pod3(with label=app1,label=three) and pod4(with label=app2, label=four),

There are 2 groups g1, and g2.

g1 is created using "label=app1" which includes pod1 and pod3.

g2 is created using "label=app2" which includes pod2 and pod4.

Network policy: from g1 to g2, app any, port any, action allow.

With this policy, pod1 can talk to both pod2 and pod4, pod3 can talk to pod2 and pod4.

Without the namespace boundary enforcement if the user wants to only allow pod1 to communicate to pod2 within same namespace ns1, pod3 to pod4 within the same namespace ns2, then additional custom groups and network policies need to be created:

Group g-1 is created using "label=one" which includes pod1.

Group g-4 is created using "label=four" which includes pod4.

Network policy: from g-1 to g-4 app any port any action deny.

Group g-3 is created using "label=three" which includes pod3.

Group g-2 is created using "label=two" which includes pod2.

Network policy: from g-3 to g-2, app any, port any, action deny.

With namespace boundary enforcement we can realize the same function, without creating additional groups and policies, to allow only pod1 to talk to pod2 but not pod1 to pod4, pod3 to pod4 but not pod3 to pod2. This saves you from creating additional rules to realize this restriction.