Description
Namespaces are a basic unit for Kubernetes operations and authorization management. Mixing resources from different teams, services or environments in one namespace can obscure ownership and the permissions each party needs.
Sharing a namespace is not inherently a vulnerability. Decide whether separation is needed for the operating model; different namespace names alone do not provide network isolation or a strong security boundary.
Potential impact
- Management responsibilities and permission scope can become unclear across teams or services.
- Identifying impact and applying operational policies can become more difficult during an incident.
Remediation
- Assess whether services, teams and environments need separate administrative boundaries. Put workloads with different permissions and ownership into suitable namespaces.
- Configure namespace RBAC, ResourceQuota and supported NetworkPolicies together. Check Secret and Service references and connection paths for workloads that move.
Examples
The example images and namespaces illustrate placement only. Supply real images and separately prepare the destination namespaces, permissions and network policies.
Before
apiVersion: v1
kind: Pod
metadata:
name: frontend
namespace: shared-all
spec:
containers:
- name: app
image: example/frontend:v1
---
apiVersion: v1
kind: Pod
metadata:
name: billing
namespace: shared-all
spec:
containers:
- name: app
image: example/billing:v1
Both workloads use shared-all. This can be valid for intentional shared management; review the actual permission scope.
After
apiVersion: v1
kind: Pod
metadata:
name: frontend
namespace: frontend-team
spec:
containers:
- name: app
image: example/frontend:v1
---
apiVersion: v1
kind: Pod
metadata:
name: billing
namespace: billing-team
spec:
containers:
- name: app
image: example/billing:v1
Namespaces are separated by team. Names alone do not block access, so apply the actual policies.