# Microsoft Azure IAM permissions

> ZopNight reads an Azure subscription through 3 built-in roles: Reader for inventory, Monitoring Reader for the utilisation metrics that idle findings need, and Cost Management Reader for spend. That is 120 read permissions. Acting on findings adds the custom Zopnight Write Access role, granted separately.

Source: https://zop.dev/integrations/azure/permissions
Updated: 2026-08-20

---

## Common questions

### Which Azure roles does ZopNight need?

Three built-in ones for reading: Reader at subscription scope for inventory, Monitoring Reader for the utilisation metrics that idle and rightsizing findings depend on, and Cost Management Reader for spend. That is 120 read permissions, none of which can change anything.

### Is Contributor or Owner ever required?

No. ZopNight's writes come from the custom Zopnight Write Access role, plus Zopnight AKS Access for cluster and node-pool operations: 68 write permissions across the two. The other write entries on this page, such as Microsoft.Authorization/roleAssignments/write, belong to ZopDay's provisioning role and are needed only if you provision or deploy with ZopDay.

### Why does the write role need deallocate rather than powerOff?

Because a VM that is stopped but still allocated keeps billing for compute. ZopNight issues Microsoft.Compute/virtualMachines/deallocate/action, which releases the capacity. Granting powerOff/action instead produces schedules that appear to work and save nothing.

## Reader roles now, Zopnight Write Access later

Azure is role-based rather than action-based, so the honest answer is a list of roles, not a
list of strings. Read-only discovery needs **Reader** at subscription scope, **Monitoring
Reader** for the utilisation metrics that idle and rightsizing findings depend on, and **Cost
Management Reader** for spend.

Those roles, plus the cluster reads in **Zopnight AKS Access**, the workspace reads in
**Zopnight Databricks Access**, a few AI-service roles and the optional **Search Service
Contributor** grant for AI Search inventory, cover every read action ZopNight uses. The reader
roles cannot change anything; Search Service Contributor can, which is why that grant is optional.

Acting on findings needs the custom **Zopnight Write Access** role, plus **Zopnight AKS
Access** for cluster and node-pool operations. The provisioning and deployment entries in the
list above, such as `Microsoft.Authorization/roleAssignments/write`, Key Vault secret reads and
writes, and DNS record writes, are not part of that grant. They belong to ZopDay's separate
**ZopDay Infrastructure Access** role and are needed only if you provision or deploy with ZopDay.

## Service principal or workload identity federation?

Both are supported and the choice is a real one.

- **Workload identity federation** stores **no secret**. Azure trusts a ZopNight OIDC token
  directly, so there is nothing to rotate and nothing to leak. Prefer it.
- **Service principal** uses a client ID, secret and tenant ID. Universally supported, but the
  secret is stored and you own its rotation.

## Why deallocate, not power off

Stopping an Azure VM through the guest OS leaves it **allocated**, and an allocated VM keeps
billing for compute. ZopNight always issues `deallocate`, which releases the capacity and stops
the compute charge. The disks keep billing either way, which is a separate finding.

This is why the write role needs `virtualMachines/deallocate/action` specifically, and why
granting only `powerOff/action` produces schedules that appear to work and save nothing.

## Namespace scheduling

AKS carries an extra purpose, `namespace_scheduling`: scaling every Deployment and StatefulSet
in a namespace to zero and suspending its CronJobs, then restoring the prior replica counts.
It needs cluster access rather than subscription-level rights, which is why it sits in its own
role instead of the general write grant.