# Kubernetes Namespace / Environment

> zop.dev provisions each AKS namespace with the standard primitives (tiered RBAC, 4 ingress variants, a cert issuer, basic auth) plus 3 AAD groups, an azuread_application with separate service principals for services and cron jobs to reach ACR, Key Vault secrets, and MySQL and PostgreSQL ExternalName aliases.

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

---

An AKS namespace in zop.dev is a complete environment with Azure-native identity and secret handling. Registry credentials and secrets flow from AAD and Key Vault rather than static config.

## Namespace primitives plus AAD and Key Vault wiring

Namespace primitives (RBAC, ingress variants, cert issuer, basic auth) plus three AAD groups per namespace, an azuread_application with service principal and password for ACR access (separate service principals for services and cron jobs), Key Vault secrets, and MySQL/PostgreSQL ExternalName services.

## The services, cron_jobs, and sql attachment maps

```text
Same services / cron_jobs / sql attachment maps as other providers, with Key Vault as the secret store.
```

## ACR credentials minted per namespace

ACR pull credentials are minted per namespace via dedicated service principals.

## Two service principals per namespace

Registry access on Azure is minted per namespace: an AAD application with a service principal
for services and a second one for cron jobs, each holding a password credential for ACR. The
split means a leaked or throttled credential implicates one workload class in one namespace,
not the whole cluster, though it also means passwords that expire, twice per namespace. The
signature failure is image pulls dying in a single namespace with no deploy in sight; the
cause is almost always a lapsed service principal password, and the fix is rotation, not a
rollback.

## Key Vault is the secret path

Application secrets flow from Azure Key Vault rather than living as static values in config.
The namespace's Key Vault secrets are created at provisioning, so the pattern is set before
the first deployment: secrets have one authoritative home, workloads read from it, and
rotating a value happens in the vault instead of across manifests. What the namespace holds
locally is only what Kubernetes itself needs: the RBAC bindings, the basic-auth secret, the
cert issuer's material.

## Databases get names that do not move

MySQL and PostgreSQL endpoints are aliased into the namespace as ExternalName services, so
applications connect to a stable in-cluster name while the actual flexible-server hostname
stays an implementation detail. Swapping or re-provisioning a database becomes a change to the
alias target, with 0 application config changes and no redeploy.

## Three groups make access reviewable

Each namespace carries its own AAD admin, editor, and viewer groups on top of the cluster
tiers. Environment-scoped access is therefore a group membership, which is the reviewable
kind: who can touch production is a directory query, and revocation is one removal that takes
effect everywhere the group is bound.