Kubernetes namespaces divide a given cluster into virtual clusters, helping to separate and manage resources while still keeping them within the same physical cluster. By segregating workloads and applying policies per namespace, you can create boundaries that keep your multi-tenant environments safe and organized.
This blog post explores the concept of Kubernetes namespaces and discusses how to leverage them to enhance security within your Kubernetes clusters. We'll cover use cases, benefits, the role of default namespaces, and best practices for security.
Kubernetes Security For Dummies
Containers can be susceptible to vulnerabilities, high complexities, and risks requiring dedicated hardening to keep a secure infrastructure. Discover new approaches to securing your containerized apps and Kubernetes clusters in this user-friendly book.
Download now
Use cases and benefits
Kubernetes namespaces play a pivotal role in many scenarios, particularly in environments where resource isolation, efficient management, and robust security are paramount. Look to Kubernetes namespaces to meet the following objectives:
Isolation in multi-tenant environments: Namespaces provide the necessary isolation to prevent conflicts and enhance security in a single cluster that hosts multiple teams or applications. Each team or application can operate within its own active namespace, effectively creating a sandboxed environment—like a cluster for development. This isolation ensures that the actions in one namespace do not affect other namespaces, maintaining stability and security across the entire cluster.
Efficient resource management: Namespaces facilitate efficient management of cluster resources. Administrators can control CPU, memory, and storage resource allocation and consumption by applying resource quotas and limits within namespaces. With quotas and limits in place, no single namespace can monopolize resources, leading to a more balanced and fair distribution across the cluster.
Simplified access and policy management: Namespaces simplify access control and policy enforcement within each namespace for objects. With Kubernetes role-based access control (RBAC), you can define who has access to which resources within each namespace. This approach helps enforce security policies and ensures users have only the permissions they need to do their jobs within their production namespace.
By leveraging these benefits, you can enhance the security and efficiency of your Kubernetes clusters, ensuring smooth and secure operations in both development and production environments.
Kubernetes namespaces vs. container namespaces
Understanding the distinction between Kubernetes and container namespaces is crucial for effectively managing security within your clusters. Both concepts are essential in the Kubernetes ecosystem but provide different scopes of control and serve different purposes:
Scope of control
Kubernetes namespaces partition cluster resources among multiple users. They are meant for scenarios with numerous users across different teams or projects. Kubernetes namespaces provide a way to segregate and manage the resources within the cluster, such as pods, services, and deployments within separate namespaces. In addition, each namespace can have separate RBAC policies and resource quotas. Users operate on the specific namespace by setting namespace fields in resource definitions or using namespace flags in their tooling. This also enables you to have the same service or resource names in different namespaces within the same cluster.
Container namespaces are a feature of the Linux kernel that provides isolation for processes, network interfaces, and other resources within a single host. Container namespaces include PID namespaces for process isolation, network namespaces for network isolation, and mount namespaces for file system isolation. These namespaces ensure that containers can run independently and securely on the same host without interfering with each other.
Security implications
Using Kubernetes namespaces, you can implement role-based access control (RBAC) to define who can access and perform actions within each namespace. In short, RBAC makes sure that users and services have the minimum necessary permissions. Additionally, applying resource quotas and network policies at the namespace level helps prevent resource abuse and secures network traffic.
Container namespaces provide isolation at the operating-system level so that processes within one container cannot see or interact with processes in another container. This isolation is fundamental to container security because it helps prevent privilege escalation and interference between containers.
Understanding and leveraging both types of namespaces is crucial for maintaining a secure and efficient Kubernetes environment. Properly configuring these namespaces provides robust isolation and control, which are foundational to Kubernetes security best practices.
The role of default namespaces
Kubernetes has four initial namespaces that serve specific purposes within the cluster:
default
The default namespace is where Kubernetes places objects that do not explicitly specify a namespace, which is why it’s the working namespace for most users and applications. However, using the default namespace for all resources can lead to clutter and potential conflicts. To maintain organization and control, it's best practice to create custom namespaces for different applications, teams, or environments.
kube-system
The kube-system namespace is reserved for the Kubernetes control plane components and other system-related pods. This includes the Kubernetes API server, scheduler, controller manager, and add-ons like DNS and network plugins. Access to the kube-system namespace should be tightly controlled because it contains critical components that are essential to a cluster's operation.
kube-public
The kube-public namespace is readable by all users, including those who are not authenticated, and it can be used for cluster information that needs to be widely accessible. (A common use case is storing public configuration data.) Sensitive data should never be placed in the kube-public namespace due to its open accessibility.
Kube-node-lease
This namespace holds lease objects for each node, enabling the kubelet to send heartbeats. Heartbeats help the control plane quickly detect and respond to node failures.
Using these default namespaces appropriately helps maintain the organization and security of your Kubernetes clusters. For production environments, consider creating dedicated namespaces for different applications and teams to enhance isolation and management.
Best practices for securing Kubernetes namespaces
Securing your Kubernetes namespaces involves adopting several best practices:
1. Implement role-based access control (RBAC)
As we’ve seen, role-based access control (RBAC) is essential for securing Kubernetes namespaces by defining who can access and perform actions within each namespace.
Actionable items:
Define roles: Create roles with specific permissions for different user responsibilities.
Assign roles to users or groups: Use RoleBinding and ClusterRoleBinding for customized controls.
The following defines a role with permissions for managing pods and services in the development namespace and binds this role to a specific user:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: development
name: developer-role
rules:
- apiGroups: [""]
resources: ["pods", "services"]
verbs: ["get", "list", "watch", "create", "update", "delete"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: developer-binding
namespace: development
subjects:
- kind: User
name: developer1
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: developer-role
apiGroup: rbac.authorization.k8s.io2. Use resource quotas and limits
Resource quotas and limits help manage the consumption of shared cluster resources, preventing any single namespace from overconsuming resources.
Actionable items:
Define resource quotas: Set limits on the total resources that each namespace can consume.
Apply resource limits: Define resource limits for individual pods within namespaces.
The following defines a resource quota for the development namespace, limiting the number of pods and the total CPU and memory usage:
apiVersion: v1
kind: ResourceQuota
metadata:
name: dev-resource-quota
namespace: development
spec:
hard:
pods: "10"
requests.cpu: "4"
requests.memory: "8Gi"
limits.cpu: "10"
limits.memory: "16Gi"
3. Create security contexts for pods and containers
Security contexts define privilege levels and access controls for pods and containers, helping to enforce safe defaults and reduce risks.
Actionable items:
Set security contexts: Define security contexts in the pod specification to control permissions and capabilities.
Enable read-only file systems: Configure containers to use read-only file systems wherever possible to prevent unauthorized modifications.
The following YAML file configures a pod with specific user and group IDs, prevents privilege escalation within the container, and sets the root file system to read-only:
apiVersion: v1
kind: Pod
metadata:
name: secure-pod
namespace: development
spec:
securityContext:
runAsUser: 1000
runAsGroup: 3000
fsGroup: 2000
containers:
- name: secure-container
image: nginx
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
4. Isolate network traffic
Isolating network traffic using network policies helps prevent attacks from compromised applications and ensures secure communication within the cluster.
Actionable items:
Define network policies: Create policies to control the traffic flow between pods across different namespaces.
Restrict external access: Implement policies restricting pod access to external networks, allowing only necessary outbound traffic.
The following NetworkPolicy allows pods in the development namespace to access only specific IP ranges and ports, effectively restricting unnecessary external access:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: restrict-external-access
namespace: development
spec:
podSelector: {}
policyTypes:
- Egress
egress:
- to:
- ipBlock:
cidr: 10.0.0.0/8
ports:
- protocol: TCP
port: 80
- protocol: TCP
port: 443Integrating with Wiz: Enhancing Kubernetes security
Wiz is a comprehensive security platform designed to enhance Kubernetes security from the control plane to the namespace level. Along with full-stack security, real-time monitoring, and protection of cluster resources, Wiz provides several key features to bolster Kubernetes security:
Namespace-level security: Wiz gives you complete visibility of your clusters and how they are secured, including namespaces. With several hundred OOTB policies covering best practices and industry frameworks like CIS Benchmarks, detect potential misconfigurations and drifts and remediate them with actionable information.
Resource monitoring: Wiz monitors all the components of your Kubernetes environment, both via agentless scanning and in real time using its sensor. This gives you a complete overview of the most critical risks and real-time detection of malicious behavior, reducing potential breaches, and blocking threats.
Integration into your ecosystem: Wiz integrates seamlessly throughout the SDLC, securing your containerized applications while eliminating friction between different teams.
If you’re ready to strengthen the security of your Kubernetes clusters, sign up for a demo today. See firsthand how Wiz can protect your cluster resources, enforce namespace-level security, and ensure a secure and efficient Kubernetes environment!
Learn why the fastest growing companies choose Wiz to secure containers, Kubernetes, and cloud environments from build-time to real-time.
