Microsegmentation namespaces
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.
We recommend the following namespace scheme.
- Parent namespace: represents your organization.
- Children namespaces: cloud accounts, private clouds, bare-metal infrastructure, projects, or teams.
- Grandchild namespaces: 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.
- Great-grandchild namespaces: the Kubernetes namespaces of your clusters.
The following example shows an organization named /acme with two children namespaces: aws-dev and aws-prod.
The aws-dev namespace contains the development environment and the aws-prod account contains the production environment.
Both contain the same resources, but one set is under development and the other is in production.
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:
- Propagate rulesets--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.
- Achieve multi-tenancy--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.
