# The Default Namespace Should Not Be Used - Source: https://support.icompaas.com/support/solutions/articles/62000234221-the-default-namespace-should-not-be-used- - Section: [Solutions](https://support.icompaas.com/support/solutions) › [CIS Amazon EKS](https://support.icompaas.com/support/solutions/62000112685) › [CIS Amazon Elastic Kubernetes Service (EKS) Benchmark](https://support.icompaas.com/support/solutions/folders/62000169234) - Last updated: 2026-05-29 - Publisher: iCompaas, Inc. (https://www.icompaas.com) **Profile Applicability:** **• Level 1** **Description:** Kubernetes provides a default namespace where objects are placed if no namespace is specified during their creation. Using this default namespace makes the application of Role-Based Access Control (RBAC) and other security measures more difficult and less effective. **Rationale:** To ensure better resource isolation and improve security, Kubernetes resources should be segregated into dedicated namespaces. This allows for more granular control and enables the implementation of RBAC policies, network policies, and other security measures at the namespace level. **Impact: Pros:** - Improved security and access control by using separate namespaces. - Better organization and easier management of resources. **Cons:** - Requires additional administrative effort to manage and configure namespaces. **Default Value:** Unless a specific namespace is mentioned during object creation, Kubernetes places resources in the default namespace. **Pre-requisites:** - Knowledge of Kubernetes namespaces and RBAC configuration. - Administrative access to the Kubernetes cluster. ### **Remediation** **Test Plan:** **Using AWS Console:** 1. Navigate to the Kubernetes cluster in the AWS Console. 2. Check the resources in the default namespace. 3. Confirm that only system-managed resources like the Kubernetes service remain in the default namespace. **Using AWS CLI:** 1. Run the following command to list objects in the default namespace: kubectl get $(kubectl api-resources --verbs=list --namespaced=true -o name | paste -sd, -) --ignore-not-found -n default 2. Alternatively, check for pods in the default namespace: kubectl get pods -n default The result should ideally show No resources found in default namespace. ### **Implementation Plan** **Using AWS Console:** 1. Create new namespaces for different applications and workloads. 2. Assign resources to their respective namespaces during creation. 3. Configure RBAC and network policies at the namespace level to ensure proper access controls. **Using AWS CLI:** 1. Create a new namespace using the following command: kubectl create namespace 2. When creating resources, ensure they are assigned to the appropriate namespace. For example, create a deployment in the newly created namespace: kubectl create deployment --image= -n ### **Backout Plan** **Using AWS Console:** 1. If there are issues with resource isolation, review the namespaces and ensure that all resources are properly assigned to their respective namespaces. 2. If necessary, delete any unwanted resources from the default namespace. **Using AWS CLI:** 1. Remove any resources from the default namespace if they were mistakenly created there: kubectl delete deployment -n default 2. Ensure that future resources are created in the correct namespace by setting the appropriate context or specifying the namespace during creation. ### **References:** 1. [Kubernetes Documentation on Namespaces](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/)

	ontrol ID	Control Description
v8	16.7	Use standard, industry-recommended hardening configuration templates for application infrastructure, including cloud containers and PaaS components.
v7	5.1	Maintain documented, standard security configuration standards for all authorized operating systems and software.

## Related compliance guidance - [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them. - [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.