Kubernetes Namespace / Environment
What does zop.dev create for Kubernetes Namespace / Environment?
zop.dev provisions GKE namespaces with every AWS-variant primitive plus GCP identity: Workload Identity service accounts, Secret Manager IAM bindings, Artifact Registry grants for artifact_users, and per-service and per-cron-job Pub/Sub editor service accounts whose keys land in Kubernetes secrets, giving 1 messaging identity per workload.
| Field | Value |
|---|---|
| Cloud | gcp |
A GKE namespace in zop.dev is a full application environment with identity and messaging pre-wired. Beyond the standard RBAC, ingress, and certificates, it configures Workload Identity and per-service Pub/Sub access automatically.
AWS namespace primitives plus GCP identity wiring
All the namespace primitives from the AWS variant (namespace, RBAC bindings, cert issuer and wildcard certificate, 4 ingress variants, basic auth, service accounts, GitHub Actions secrets) plus Workload Identity service accounts, Secret Manager IAM bindings, Artifact Registry IAM for artifact_users, per-service and per-cronjob Pub/Sub topic and subscription IAM with dedicated pubsub_editor service accounts and keys stored as Kubernetes secrets, a TLS secret, and read-replica ExternalName services.
The AWS attachment maps, extended for GCP
Same services / cron_jobs / sql / helm_charts attachment maps as AWS, extended with pubsub grants and artifact_users.A Pub/Sub editor per service and per cron job
Pub/Sub editor credentials are minted per service and per cron job, so messaging access is scoped to the workload.
Messaging identity is per workload
The distinctive move on GCP: every service and every cron job that touches Pub/Sub gets its
own pubsub_editor service account, with topic and subscription IAM granted per workload.
The blast radius follows: a leaked credential or an over-chatty consumer implicates one
workload, not the namespace, and “which identity read this subscription” has exactly one
answer. Access reviews stop being archaeology because the identity graph mirrors the workload
graph one-to-one.
The keys in secrets are the caveat
Those per-workload service accounts authenticate through exported keys stored as Kubernetes secrets. Those are static credentials, in a namespace whose other identities (the Workload Identity service accounts) are deliberately keyless. The asymmetry is worth naming: WI covers the general case with no key material at all, while the Pub/Sub path still ships keys that live in etcd and never expire on their own. Treat them accordingly: they are in scope for rotation, and anyone with secret-read access in the namespace can read them, which is one more reason namespace RBAC tiers matter.
Secrets readable only by their owner
Secret Manager access is granted through namespace-scoped IAM bindings, so a workload can read the secrets bound to it and nothing else. The failure this prevents is the shared-vault pattern where every app in the cluster can technically read every credential and the difference between can and does is one bug.
The rest of the environment rides along
Everything the AWS variant provides arrives here too (tiered RBAC, cert issuer and wildcard
certificate, 4 ingress variants, basic auth, GitHub Actions wiring), plus a TLS secret,
Artifact Registry grants for artifact_users, and ExternalName services covering read
replicas as well as primaries, so replica endpoints get stable in-cluster names too.