Microsoft Azure permissions

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.