Description
default is a valid namespace for ordinary resources; using it is not inherently incorrect. When several applications share it, however, permission boundaries and operational ownership can become harder to manage. Avoid mixing business workloads into system-purpose namespaces such as kube-system and kube-public.
Namespaces provide scope for permissions and policies. Separate names do not automatically isolate network traffic or access, so configure RBAC, NetworkPolicy and other required controls as well.
Potential impact
- Mixing operational and application resources can complicate management.
- Permission and policy scopes may become unclear.
- Understanding and containing an incident's impact can become harder.
Remediation
- Use dedicated application namespaces where operational requirements call for them.
- Preserve the purpose of system namespaces and apply RBAC, NetworkPolicy and resource quotas according to actual requirements.
- Define namespace creation rules and ownership, and test effective permissions and network access.
Examples
Replace the sample image with the actual application image and create the cosmic-pod namespace first.
Before
yaml
apiVersion: v1
kind: Pod
metadata:
name: frontend
namespace: default
spec:
containers:
- name: app
image: images.my-company.example/app:v4
After
yaml
apiVersion: v1
kind: Pod
metadata:
name: frontend
namespace: cosmic-pod
spec:
containers:
- name: app
image: images.my-company.example/app:v4
Explanation:
- Before: Uses
default. This is valid, but review whether permissions and operational ownership should be separated by application. - After: Uses a dedicated namespace with a valid lowercase name. Apply the required RBAC and network policies separately.