Review use of the Kubernetes default namespace

Description

Placing unrelated workloads in the default namespace can make operational ownership and permission boundaries harder to manage. Organize resources by service, environment or team.

A namespace name alone does not create security isolation. Configure the actual boundaries with RBAC, NetworkPolicy and resource policies.

Potential impact

Operators may accidentally modify or delete another application’s resources.
Shared permissions and policies may apply more broadly than necessary.

Remediation

Set the intended metadata.namespace on namespaced resources. This does not apply to cluster-scoped resources.
Create the target namespace first and configure least-privilege RBAC, required NetworkPolicies and ResourceQuotas.
When moving existing resources, plan creation in the new namespace, dependencies and data migration, then test access.

Examples

These metadata comparisons omit the required specs. Prepare the payments namespace first. The existing kubernetes_cron_job resource uses the legacy API; use the supported kubernetes_cron_job_v1 in current configurations.

Before

hcl

resource "kubernetes_pod" "example" {
  metadata {
    name      = "app"
    namespace = "default"
  }
}

resource "kubernetes_cron_job" "example" {
  metadata {
    name = "batch-job"
  }
}

After

hcl

resource "kubernetes_pod" "example" {
  metadata {
    name      = "app"
    namespace = "payments"
  }
}

resource "kubernetes_cron_job" "example" {
  metadata {
    name      = "batch-job"
    namespace = "payments"
  }
}

Explanation:

Before: The Pod explicitly uses default and the CronJob omits the namespace. Check the effective default for omitted values.
After: Both resources explicitly use payments. Access and network policies are still required separately.