# Kubernetes Namespace / Environment

> zop.dev turns one EKS namespace into a full environment: tiered RBAC, a cert-manager Issuer with a wildcard Certificate, 4 ingress variants, a SecretProviderClass for the AWS secrets CSI driver, an IRSA service account, ExternalName database aliases, and GitHub Actions secrets. A DynamoDB attachment additionally mints a scoped IAM user with an access key.

Source: https://zop.dev/integrations/provision/aws/kubernetes-namespace
Updated: 2026-08-19

---

A namespace is an isolated environment inside the cluster where a team deploys its services, cron jobs, and datastore connections. zop.dev turns namespace creation into full environment provisioning: RBAC, TLS certificates, ingress, secrets wiring, and CI/CD variables come pre-configured.

## A namespace with RBAC, TLS, ingress, and CI wiring

Namespace, RBAC role bindings (admin/editor/viewer), cert-manager Issuer plus wildcard Certificate, 4 ingress variants (default, custom, path-based, wildcard-custom), basic-auth secret, SecretProviderClass for the AWS secrets CSI driver, service account with IRSA/OIDC policy, ExternalName services for database endpoints, and GitHub Actions secrets and variables.

## Resource kinds a namespace can attach

```text
Attachable resource kinds: services (full deployment spec with HPA, probes, PDB, ingress_list, infra_alerts), cron_jobs, sql_db/sql_list (RDS attach), local_redis, cassandra_db, dynamo_db tables, kafka topics, arbitrary helm_charts, custom_namespace_secrets, ingress_custom_domain.
```

## DynamoDB attachments add a scoped IAM user

DynamoDB attachments create a per-namespace IAM policy scoped to table/\<cluster>-\<ns>* plus an IAM user, access key, and Secrets Manager entries.

## An environment, not a label

Creating a namespace here provisions the environment around it: RBAC bindings for the admin,
editor, and viewer tiers; a cert-manager Issuer with a wildcard Certificate; 4 ingress variants
(default, custom, path-based, wildcard-custom); a basic-auth secret; a SecretProviderClass for
the AWS secrets CSI driver; a service account carrying an IRSA/OIDC policy; ExternalName
services aliasing database endpoints; and GitHub Actions secrets and variables. The CI wiring
is the easily-missed one: pipeline credentials exist before the first pipeline runs.

## Attachments mint cloud identities

The namespace is also the attachment point for datastores, and some attachments reach out of
the cluster. Attaching `dynamo_db` tables creates a per-namespace IAM policy scoped to
`table/<cluster>-<ns>*`, an IAM user, an access key, and Secrets Manager entries. That is a
static AWS credential created as a side effect of a Kubernetes-looking operation. It needs
rotation and cleanup like any IAM user, and deleting the namespace is not automatically the
same as retiring it.

`sql_db` attachments are gentler: an ExternalName alias to the RDS endpoint, so connection
strings reference a stable in-cluster name rather than a cloud hostname.

## The name propagates into AWS

The namespace's name is embedded in DynamoDB table prefixes, secret names, and IAM policy
scoping. Renaming an environment is therefore not a rename at all: it is a new namespace, new
identities, and a data migration. Choose names as if they are permanent, because the ARNs they
end up inside effectively are.

## What bills and what does not

The namespace, RBAC, certificates (Let's Encrypt via cert-manager), and ingress definitions
cost nothing by themselves. The billable residue lives in AWS: every Secrets Manager entry
bills per secret per month, and each attachment-minted IAM user adds its credentials to that
count.