Azure permissions

Permissions North.Cloud requires from your Azure account.

Azure IAM Permissions and Deployment

North requires carefully scoped Azure permissions so our application can read the billing and usage data our ML engine needs to produce automated FinOps recommendations. We limit every permission to the minimum needed for your financial analysis. We do not request access to your workloads or to your application data.

Azure uses Workload Identity Federation to give North secure, fine-grained access. No North service account keys and no client secrets are created in your tenant.

---

What North CAN NOT do

• Read the contents of any resource. This covers database rows, Key Vault secret values, log records, and blob data outside the north-exports container.
• Create, modify, or delete any Azure resource.
• Access keys, secrets, passwords, or any other credential in your environment.
• Run Log Analytics queries. That needs the Log Analytics Reader role, which North is not granted.
• Make purchases, modify subscriptions, or change billing settings, unless you grant the optional purchasing roles below.

What North CAN do

• Read the cost export Parquet files in the north-exports container.
• Query aggregated cost data through the Cost Management API, read-only.
• Read your reservation and savings plan details, for commitment coverage and utilization analytics.
• Read the configuration and metadata of resources across your tenant, and their metrics through Azure Monitor. North uses this for compute right-sizing.

The following sections explain the roles North receives and why each one is needed.

---

Permission Groups Explained

North receives five RBAC role assignments. Every one of them is read-only.

Role	Scope	What it grants
Storage Blob Data Reader	The north-exports container only	Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read
Cost Management Reader	Billing account	Microsoft.CostManagement/*/read, Microsoft.Billing/*/read
Reservations Reader	Microsoft.Capacity provider	Microsoft.Capacity/reservationOrders/read, Microsoft.Capacity/reservations/read
Savings Plan Reader	Microsoft.BillingBenefits provider	Microsoft.BillingBenefits/savingsPlanOrders/read, Microsoft.BillingBenefits/savingsPlans/read
Reader	Tenant-root management group	*/read. See below.

1. Billing data

Storage Blob Data Reader lets North read your export files from the dedicated container. North cannot reach any other container and cannot reach any other storage account.

Cost Management Reader lets North query cost data through the Cost Management API. It cannot create, modify, or delete anything.

2. Commitment data

Reservations Reader and Savings Plan Reader let North read the details of the reservations and savings plans you hold. North needs both to report commitment coverage and utilization.

If either grant is missing, onboarding still completes. North cannot read your commitment inventory in that case, so coverage and utilization figures on the Commitments page will be incomplete.

3. Right-sizing data

Reader is the one grant that is not narrowed to a single provider. It grants */read: read access to the configuration and metadata of every resource in the tenant, plus resource metrics through Azure Monitor. North uses it to size and right-size your compute. It reads Virtual Machine and Virtual Machine Scale Set inventory through Azure Resource Graph, and CPU, network, and disk metrics through Azure Monitor.

Reader is assigned at the tenant-root management group because Azure RBAC inherits downward. One assignment therefore covers every subscription in your billing account, and North never has to enumerate them.

Reader carries no dataActions, so it cannot read the contents of anything. It grants no write access, no delete access, and no configuration access of any kind.

North asks for Reader rather than Azure's built-in Monitoring Reader role. Monitoring Reader covers the same reads and adds Microsoft.Support/*, which includes Microsoft.Support/supportTickets/write, the ability to open support tickets in your tenant. North does not need that, so North asks for the smaller role.

4. Auto-Purchasing (Optional) – Buying Commitments in Your Own Account

The five roles above are read-only. They let North recommend commitments. They do not let North buy anything. Autobot needs two more roles before it can purchase commitments directly in your own Azure subscription.

These roles are optional. Grant them only if you want Autobot to purchase on your behalf. North verifies them separately, and a missing purchasing role does not affect your account's overall verification status.

Role	What it lets Autobot buy
Reservation Purchaser	Azure reservations
Savings plan Purchaser	Azure savings plans

Assign both to the same App Registration you created for cost and usage onboarding. No second app registration and no second federated credential are needed.

Assign both roles at the subscription scope, /subscriptions/<your-subscription-id>. A tenant-root assignment does not work. These built-in roles grant roleAssignments/read at their own scope only, not at the tenant root above it, so a tenant-root grant fails with AuthorizationFailed even when the roles look correctly assigned.

---

Permissions Used During Onboarding

The list below covers every Azure action the onboarding performs. Grant these if your organization uses custom roles instead of the built-in roles.

Entra ID: App Registration and Workload Identity Federation

Permission	Action
Create App Registration	microsoft.directory/applications/create
Read App Registration	microsoft.directory/applications/read
Read Service Principal	microsoft.directory/servicePrincipals/read
Create Service Principal	microsoft.directory/servicePrincipals/create
Create Federated Credential	microsoft.directory/applications/credentials/update
List Federated Credentials	microsoft.directory/applications/credentials/read

Subscription: resource group, storage, and provider registration

Permission	Action
Register resource provider	Microsoft.Resources/subscriptions/providers/register/action
Check provider registration	Microsoft.Resources/subscriptions/providers/read
Create resource group	Microsoft.Resources/subscriptions/resourceGroups/write
Create storage account	Microsoft.Storage/storageAccounts/write
Read storage account	Microsoft.Storage/storageAccounts/read
Check storage name availability	Microsoft.Storage/checkNameAvailability/read
Create blob container	Microsoft.Storage/storageAccounts/blobServices/containers/write
Check blob container existence	Microsoft.Storage/storageAccounts/blobServices/containers/read

RBAC: role assignments

Permission	Action
Assign roles	Microsoft.Authorization/roleAssignments/write

Billing: Cost Management exports

Permission	Action
Create and update exports	Microsoft.CostManagement/exports/write

Azure Onboarding lists which roles the person running the onboarding needs, and at which scope.

---

Security Model

North uses Workload Identity Federation to authenticate.

• No stored secrets. There is no client secret and no certificate, so there is nothing to rotate, leak, or expire.
• Short-lived tokens. Access tokens are valid for one hour and are obtained on demand.
• Scoped access. Each token is minted for a single audience. That is either Azure Blob Storage, to read the export files, or Azure Resource Manager, for the read-only metadata, commitment, and metric queries above.
• Auditable. Every authentication event appears in your Entra ID sign-in logs.
• Revocable. Delete the App Registration or the Federated Credential to revoke all access immediately.

Data isolation

• North reads blob data from the north-exports container only.
• Access is always read-only, unless you grant the optional purchasing roles. North cannot modify or delete your data.