Enable Namespace Isolation by Default

Namespaces Overview

Namespaces

Network communication between namespaces is allowed by default. The default namespace behavior is siffucient for several uses cases. For example, a single team or single application using a given cluster, and when all namespaces are within the same administrative and security boundary. For various teams across multiple applications however, isolated namespaces might be ideal.

For instance, you can have separate namespaces for databases, or monitoring. Resource names must be unique within a namespace, but they can be the same across different namespaces. Pods in a standard namespace exhibit the following network behavior:

• Pods in standard namespaces can communicate with other pods in the cluster without using NAT.

• Pods and services in standard namespaces share the same default-podnetwork and default-servicenetwork.

Isolated Namespaces

An isolated namespace enables you to segment resources at a network layer to prevent communication with other namespaces. This is helpful to introduce security mechanisms and reduce lateral movement within a cluster. You can create an isolated namespace to isolate a pod from all other pods outside of its namespace, without the added complexity of explicitly configuring a network policy. Each isolated namespace has its own pod network and service network. This means that pods in isolated namespaces cannot reach pods or services in other isolated or standard namespaces. Pods in isolated namespace can only communicate with pods in the same namespace. The only exception is when a pod in an isolated namespace needs access to a Kubernetes service, such as Core DNS. In this case, the pod uses the cluster's default-servicenetwork to access the services.

Pods in an isolated namespace exhibit the following network behavior:

• Pods in isolated namespaces can only communicate with pods in the same namespace.
• Pods in isolated namespaces can reach services in non-isolated namespaces.
• The IP addresses and service IP addresses of pods in isolated namespaces are allocated from the same subnet as the cluster's pod and service subnet.
• Pods in an isolated namespace can access the underlay network, or IP fabric network, though IP fabric forwarding and fabric source NAT.

Default Namespace Isolation

CN2 release 23.3 lets you enable namespace isolation by default via an enhanced kubemanager. In 23.3, the following changes enhance the kubemanager spec:

• IsolateNamespaces: Set the enable field in this object to ensure that all namespaces created within the assiocated cluster are isolated. You can toggle this field at any time but it doesn't affect existing namespaces.
• Enable: Set to true to activate the IsolateNamespace field.
• ExceptionList: Enter a list of namespaces that won't be affected by the IsolateNamespaces feature. When you enable IsolateNamespaces and a namespace must be non-isolated, the name of that namespace must be added to the ExceptionList before you create the namespace.
• DefaultForwardingMode: Specify the forwarding mode to be used by all isolated namespaces within this cluster. The available options are:
  • fabric-snat ( Fabric SNAT)
  • ip-fabric ( IP Fabric Forwarding)

Leave this field blank if you don't require any forwarding for the isolated namespaces. Any forwarding mode specified as an explicit label on the namespace itself takes priority over the DefaultForwardingMode setting. Any namespace explicitly created as an isolated namespace will take priority over the state of the enable field or presence of the name in the exception list.

Note:

These fields only exist for CN2 release 23.3 or later. Release 23.3 has a new apiVersion (v1) for the configplane.juniper.net group. These fields are not present for v1alpha1.

The following is an example kubemanager configuration.