# 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.

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

---

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

```text
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.