Microsegmentation namespaces define logical groups of resources.
They 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.
You should group your resources according to their users, which may be inside or outside of your organization.
An optimal namespace scheme makes it easier to provide a good user experience and control access.
The top level namespace is automatically set to your Prisma Tenant ID and you cannot delete it.
The second level namespace should represent the Cloud Account (AWS, Azure, GCP).
This namespace is automatically created when you onboard accounts, and can be deleted.
The next namespace depends on the workload type which can be either a VM or Kubernetes resource. If it is a Kubernetes resource, then it should be the name of the Kubernetes cluster, otherwise specify a name that logically defines the contained VMs. If it is a Kubernetes cluster there will be one more level which aligns with the Kubernetes cluster namespaces.
We recommend the following namespace scheme.
: represents your organization.
: cloud accounts, private clouds, bare-metal infrastructure, projects, or teams.
: represent either Kubernetes/OpenShift clusters or VMs.
Each cluster needs its own grandchild namespace.
You can put more than one VM in a namespace if you wish.
The Microsegmentation namespaces and network rulesets ensure that apps under development cannot access the production database and only the production web server accepts requests from the public internet.
Access to the parent namespace is restricted to operators.
The operators set rules in the parent namespace and propagate them down to the children.
Developers can view the propagated rulesets, but cannot modify them.
Microsegmentation namespaces make it easier to:
--the users responsible for administering the system, called operators, have namespaces near the top of the hierarchy.
This allows them 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.
Establish security zones
--grouping resources according to their level of exposure to users outside your organization helps you control access with network rulesets.
In our example above, we’ve separated the development and production environments.
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.
--users can log into the Microsegmentation Console and view just the resources that pertain to them.
This protects users from each other, prevents unauthorized modifications, and allows you to follow the principle of least privilege.