Azure AD Users & Groups
What does zop.dev create for Azure AD Users & Groups?
zop.dev bulk-creates azuread_user accounts and 3 cluster-level AAD groups (admins, editors, viewers) with role assignments, then 3 more groups per namespace, all derived from user_access configuration. Directory objects cost nothing; the credentials to watch are the separate per-namespace service principals whose ACR passwords expire.
| Field | Value |
|---|---|
| Cloud | azure |
Azure access is governed through Azure Active Directory. zop.dev provisions the AAD users and groups that map to cluster and namespace access tiers, so RBAC reflects your team structure automatically.
Bulk azuread_user creation and tiered groups
Bulk azuread_user creation (k8s/azure/aad), three cluster-level AAD groups (admins/editors/viewers) with role assignments, and three more AAD groups per namespace.
User lists drive group membership
User lists per access tier; group membership derived from user_access configuration.ACR service principals for services and cron jobs
Namespace provisioning also creates separate AAD applications and service principals for ACR access (one for services, one for cron jobs).
Groups are the unit of access
Role assignments target the groups, not the people. Granting someone editor access to a cluster is a membership change in one AAD group, and revoking it is the removal. No policy edit, no redeploy, and an access review reads as a membership listing. The three-tier shape (admins, editors, viewers) repeats at cluster level and again per namespace, so scoping someone to a single environment is group membership too, three groups deep rather than a custom role.
Where the users come from
The k8s/azure/aad module bulk-creates azuread_user accounts from the per-tier lists in
user_access. That makes the configuration file the roster: a name added to a list becomes a
directory user with tier membership on the next run. The mirror image is the part to manage:
names removed from the list are departures the directory needs to reflect, and an AAD user
nobody prunes retains whatever their groups grant.
The service principals are the aging credentials
Alongside the human identities, namespace provisioning creates AAD applications with service principals for ACR access, one for services and one for cron jobs, each carrying a password credential. Unlike group memberships, these expire. A service principal password lapsing surfaces as image pulls failing across one namespace with no code change anywhere. That is worth recognizing on sight, because the fix (rotate the credential) is nowhere near where the symptom appears.
Nothing here bills, everything here gates
AAD users, groups, and role assignments carry no charge at this tier, so there is no cost pressure on any of it. What they gate is everything else: the groups decide cluster and namespace access, and the service principals decide whether deployments can pull images at all. Free resources, load-bearing behaviour.