Kubernetes Namespace / Environment
What does zop.dev create for 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.
| Field | Value |
|---|---|
| Cloud | aws |
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
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.