The Lowdown on Locked Namespaces

• Are Namespaces a Security Feature?
• What Can Go Wrong?
• What Can We Do About It?
• Takeaways

At ControlPlane, we put Kubernetes under a security lens to make sure that even apparently non-critical features aren’t introducing security risks that would hinder the security posture of our clients’ clusters. Kubernetes namespaces are one of the most critical resources in any Kubernetes environment, and they are often overlooked from a security standpoint. This blog post provides insights into the security implications of namespace misconfigurations and offers strategies to mitigate associated risks.

Are Namespaces a Security Feature?

Kubernetes namespaces are fundamental tools for organising resources within a cluster. While not inherently a security feature, namespaces are crucial in facilitating various security measures within Kubernetes environments.

One of the primary use cases of namespaces in Kubernetes is facilitating Role-Based Access Control (RBAC). By segregating resources into distinct namespaces, RBAC ensures proper authorisation and access control at user and workload levels. Utilising role bindings, administrators can define granular access policies in the context of each namespace, thereby enhancing security within the cluster.

Namespaces also influence networking functionalities within Kubernetes clusters. Internal DNS resolution, for instance, relies on namespace configuration to enable seamless communication between services and Pods. Additionally, Network Policies, governed by namespace selectors, regulate traffic flows between Pods belonging to different namespaces, enhancing network micro-segmentation.

The recently published v1.0 release of Gateway API even features cross-namespace routing support, which allows HTTP routes instantiated in different application namespaces to target a centralised gateway object in a platform namespace for separation of duties and reduction of overall costs. This is also based on namespace selectors.

Security context restrictions, such as the predefined security profiles provided by Pod Security Standards (PSS) since Kubernetes 1.25, contribute to securing Pods and the underlying nodes. These settings enforce Pod and container security restrictions, mitigating risks associated with privilege escalation and unauthorised access to cluster resources.

Finally, namespace-bound features like Resource Quotas and Limit Ranges play a crucial role in resource management within Kubernetes environments. Administrators can prevent resource abuse by setting limits on storage, compute, and object count at the namespace level and ensuring fair resource allocation across applications.

What Can Go Wrong?

Misconfiguration is a leading cause of cloud insecurity, and namespace misconfigurations can lead to various security threats within Kubernetes clusters. From privilege escalation to network policy bypasses, not to mention resource exhaustion and DNS spoofing, attackers can exploit insecure settings in namespace-level configurations to compromise cluster security and disrupt operations.

Interestingly enough, several of the aforementioned security features are based on appropriate namespace labelling, therefore attackers may attempt to tamper with existing namespace labels or create new labels to bypass existing security controls.

More importantly, you don’t need a cluster role and a cluster role binding to label an existing namespace, although namespaces are global resources.

Consider the example role below, which grants the PATCH verb for namespace objects and is constrained to the private namespace:

kind: Role
metadata:
  name: ns-patcher
  namespace: private
rules:
- apiGroups:
  - ""
  resources:
  - namespaces
  verbs:
  - patch

An attacker who stole a token from a service account with the role above may gain unauthorised access to a Gateway API shared gateway object from a compromised application namespace by “guessing” the namespace selector for it, leading to unauthorised exposure of internal-facing systems or even worse, to data exfiltration.

As another attack path, the same malicious user may bypass existing security context restrictions on all the Pods by enforcing a privileged PSS level through namespace re-labelling.

What Can We Do About It?

To mitigate risks associated with namespace misconfigurations, adopting security best practices is essential:

• Implement the least privilege principle for RBAC policies, steering away from wildcards as much as possible
• Audit and monitor namespace changes regularly
• Utilise immutable labels for namespace selectors to prevent tampering, such as the built-in kubernetes.io/metadata.name
• Leverage policy engines for additional namespace-level restrictions, such as forbidding label creation on production namespaces and enforcing strict naming conventions

Takeaways

In conclusion, Kubernetes namespaces play a vital role in securing cluster environments. While not inherently security features, namespaces serve as foundational components for implementing various security measures. By understanding the significance of namespaces and adopting best practices for configuration and management, organisations can bolster the security of their Kubernetes deployments and mitigate the risks associated with namespace misconfigurations.

You can check out the full video of the talk presented at KubeCon + CloudNativeCon Europe 2024:

Download the slides from the talk using this link.