# Kustomize namespace: Set Namespace on All Resources

> The namespace field sets metadata.namespace on every namespaced resource. Reference for behavior, reference rewriting, and the cluster-scoped gotchas in CI.

Source: https://latchkey.dev/learn/command-reference/kustomize-namespace-transformer  
Updated: 2026-06-30

The namespace field stamps a single namespace onto every namespaced resource in the build.

One line moves a whole overlay into a target namespace. Kustomize also rewrites references such as ServiceAccount subjects in RoleBindings to match.

## What it does

Setting namespace adds or overwrites metadata.namespace on every namespaced resource the build produces. Kustomize also updates known cross-references, for example the namespace of subjects in a RoleBinding that point at a ServiceAccount in the same build.

## Common usage

```kustomization.yaml
# overlays/prod/kustomization.yaml
namespace: prod-web
resources:
  - ../../base
```

## Behavior

| Resource type | Effect |
| --- | --- |
| Deployment, Service, etc. | metadata.namespace set to the value |
| Namespace object | Its metadata.name is also set to the value |
| RoleBinding subjects | Subject namespace rewritten to match |
| ClusterRole, ClusterRoleBinding | Cluster-scoped, namespace not added |

## In CI

Use namespace per overlay so dev and prod land in separate namespaces from one base. Confirm the namespace exists or include a Namespace manifest, since kubectl apply -k will fail if the target namespace is missing and not created in the same apply.

## Common errors in CI

"namespaces \"prod-web\" not found" at apply time means the namespace is not created by this build; add a Namespace resource or create it first. The transformer does not touch cluster-scoped objects, so do not expect a ClusterRole to gain a namespace. If references are not rewritten, the subject kind or name does not match a resource in the same build.

## Using this in CI

A runner has no kubeconfig, no cached context, and no interactive auth. Every kubectl invocation in CI needs the context supplied explicitly, and most confusing CI failures here are the command running against the wrong cluster or no cluster at all.

```Terminal
# never rely on the ambient context on a runner
kubectl --context "$KUBE_CONTEXT" -n "$NAMESPACE" get pods

# confirm what you are actually connected to before mutating anything
kubectl config current-context
kubectl cluster-info

# fail fast instead of hanging on an unreachable API server
kubectl --request-timeout=30s get nodes
```

> Always set `--request-timeout` in CI. Without it an unreachable API server hangs until the job times out, which turns a thirty-second failure into a twenty-minute one.

## FAQ

### Kustomize namespace: Set Namespace on All Resources?

One line moves a whole overlay into a target namespace. Kustomize also rewrites references such as ServiceAccount subjects in RoleBindings to match.

### What it does?

Setting namespace adds or overwrites metadata.namespace on every namespaced resource the build produces. Kustomize also updates known cross-references, for example the namespace of subjects in a RoleBinding that point at a ServiceAccount in the same build.

### In CI?

Use namespace per overlay so dev and prod land in separate namespaces from one base. Confirm the namespace exists or include a Namespace manifest, since kubectl apply -k will fail if the target namespace is missing and not created in the same apply.

### Common errors in CI?

"namespaces \"prod-web\" not found" at apply time means the namespace is not created by this build; add a Namespace resource or create it first. The transformer does not touch cluster-scoped objects, so do not expect a ClusterRole to gain a namespace.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt