Just because you can, doesn’t mean you should, right? Wrong. Restricting access to the default namespace in Kubernetes is critical to running a secure and stable Kubernetes environment, particularly if you’re running Kubernetes at any kind of scale. Here’s why.
For the uninitiated, namespaces are objects that logically partition a K8s cluster into pools of isolated resources; they help different projects, teams, or customers to share a Kubernetes cluster without concern for unintended interaction.
At a more technical level, Namespaces allow administrators / platform managers to segregate and assign resources to individual users, teams, or applications. They also provide the basic building blocks for resource usage allowance, access control and isolation for applications or groups of users. Effective use of Namespaces means you can increase resource efficiencies as a cluster can now be used to manage a diverse set of workloads.
Unless a namespace is stipulated when creating a resource or performing management commands, Kubernetes assumes the default namespace. This means that it is very possible that users end up deploying their applications within, and can make inadvertent changes to running applications in the default namespace. In addition, it’s difficult to apply mandatory quota requirements and advanced RBAC to the default namespace, so accidental self-DDOS is completely possible if a user deploys a misbehaving application in the default namespace, which is clearly not ideal.
It is so important to restrict access to the default namespace that CIS security recommendations, and in fact every single major Kubernetes provider recommends this as a best practice.
The risks of not using namespaces effectively are:
- Users are not mandated to deploy applications within resource constraints, leading to careless deployments and risks of unexpected cluster resource exhaustion,
- Unpredictable application performance issues for end users as apps compete for contended resources,
- Insufficient network isolation between application deployments,
- Security risks as configmaps and secrets are available to everyone that has access to a namespace, and by default everyone has access to the default namespace,
- Security risks as users can manipulate others resource in the default namespace.
To ensure applications can get access to the resources they need to run efficiently and predictably (without conflicting demands) we need to restrict access to the default namespace and force users to deploy only within isolated, and constrained namespaces.
As with all things Kubernetes, this can be done using CLI-based tools like Kubectl but it’s harder than it needs to be, easy to get wrong, and nearly impossible to scale beyond a few users/clusters.
Portainer lets you do two things easily; first, it lets you disable the ability to see, and deploy to, the default namespace, forcing users to only deploy within their allocated namespaces. Second, Portainer applies and enforces quota restrictions per namespace, so that every deployment has a quota assigned. In Portainer Business edition, we extend the quota assignment/enforcement beyond just CPU and RAM, and into Storage, Load Balancers, and Ingress controllers. This ensures that access to every single critical resource is managed by limits.
At Portainer, we recognize the importance of Namespaces in Kubernetes and have worked to provide Platform Managers with the visibility and control they need, without the need to use the CLI manually, or create their own scripts/tooling.
It takes just a few seconds to restrict access to the default namespace inside Portainer Business (see toggle on/off in the video below).
Once access to the default namespace has been constrained, Platform Managers can use the tools inside Portainer Business to set and manage resource quotas on each namespace, which is hugely important for any organization seeking to deploy Kubernetes in a production environment at scale.
The video below shows how easy it is to set up storage quotas for a defined namespace.
See for yourself, with a demo or free trial
Let us introduce you to a world of fast and easy app deployment, governance, and management in Docker/Swarm and Kubernetes. Join a group demo to see how Portainer Business helps to make Engineering and DevOps teams more accurate and efficient in container management.
COMMENTS