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's usually needed 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​

Customer made request to policy ingress/egress traffic on namespace’s natural boundary.

eg.)

There are 2 namespaces ns1, ns2,

in ns1 there are pod1(with label=app1,label=one) and pod2(with label=app2, label=two),

in ns2 there are pod3(with label=app1,label=three) and pod4(with label=app2, label=four),

There are 2 groups g1, 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 namespace boundary enforcement if user wants to only allow pod1 communicates to pod2 within same namespace ns1, pod3 to pod4 within same namespace ns2, 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 same function, without creating additional groups and policies, to allow only pod1 talk to pod2 but not pod1 to pod4, pod3 to pod4 but not pod3 to pod2.