Microsegmentation namespaces


Microsegmentation namespaces define logical groups of resources. You should group your resources according to their users, which may be inside or outside of your organization. An optimal namespace scheme will make it easier to provide a good user experience and control access. Some goals, recommendations, and considerations follow.

  • Operator namespaces—namespaces have hierarchical relationships, like folders in a file system. You can propagate objects from parent to child, but never from child to child or child to parent. The users responsible for administering the system, called operators, should have namespaces near the top of the hierarchy. This allows the operators to propagate objects to the child namespaces. Propagation reduces manual work effort and allows the operators to ensure that the children conform to basic security requirements.

  • Security zones—grouping resources according to their level of exposure to users outside your organization helps you control access with network policies. Let’s consider a common example: separating the development from the production environment. Developers within your organization can access the development environment and innovate in a safe space. Once they’ve stabilized and tested the code, they push it to the production environment, which is available to users outside of the organization.

  • Multi-tenancy—creating a namespace per team or project provides better usability. Users can log into the Microsegmentation Console and view just the resources that pertain to them. It also protects users from each other, prevents unauthorized modifications, and allows you to follow the principle of least privilege.


Microsegmentation offers full flexibility. You can design your namespace scheme however you like. For ease of use, we recommend conforming to the following guidelines.

  • Four levels deep
  • Kubernetes enforcers deployed at grandchild level
  • Host enforcers deployed at great grandchild level
  • One great grandchild namespace per host enforcer

Following these guidelines keeps your processing units all in the great grandchild level. The documentation expects you to follow this basic guidance.

Example namespace scheme

The following diagrams illustrates an example namespace scheme that provides multi-tenancy, isolates developers from operators, and separates the development environment from the production environment.

The parent namespace should bear the name of your organization. Our example shows the namespace scheme of Acme, Inc. and our parent namespace is /acme.

You can create child namespaces that map to cloud provider, multi/hybrid cloud group of assets, private assets, cloud account, VPC, business unit, team, project, or any combination. In our example, we have created two children that represent teams: team-a and team-b.

Only the operators can access the children namespaces /acme/team-a and /acme/team-a. The operators set policy in the children namespaces and propagate it down to the grandchildren. Developers can view the propagated policy, but cannot modify it. The following diagram illustrates the first three levels of our example scheme.

/acme /acme/team-a/prod /acme/team-a/dev policy operator a developer a policy policy /acme/team-a /acme/team-b /acme/team-b/prod /acme/team-b/dev policy developer b operator b policy policy policy

The diagram below depicts the third and fourth levels of our example scheme, focusing on /acme/team-a/dev and /acme/team-a/prod.

developerIP addresses /acme/team-a/dev policy /acme/team-a/prod policy /acme/team-a/dev/vm policy monolithic web application /acme/team-a/dev/k8s-ns policy web server backend app pod pod /acme/team-a/prod/vm policy monolithic web application /acme/team-a/prod/k8s-ns policy backend app pod pod publicinternet web server

The namespaces and policies ensure that:

  • Apps under development cannot access the production database.
  • Only the production web server accepts requests from the public internet.