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

Source: https://zop.dev/integrations/provision/azure/azure-ad-users-groups
Updated: 2026-08-19

---

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

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