Security & API Access Overview
Prepared for customer security assessment.Integration Summary
1. Purpose of This Document
This document is provided to support your organisation’s security assessment of the nOps Azure integration. It lists the Azure API calls nOps makes, the exact RBAC permissions required, the resources in your environment, and what nOps does not access. nOps offers two integration tiers:- Savings Analysis: Read-only cost visibility, resource inventory, and optimisation recommendations.
- Commitment Management: Automated purchasing and lifecycle management of Azure Reservations and Savings Plans. This tier builds on Savings Analysis and adds one Azure Lighthouse delegation on each purchase subscription. It gives nOps staff Reader, Reservation Purchaser, and Savings plan Purchaser there.
Supported Agreement TypesnOps supports Enterprise Agreement (EA) and Microsoft Customer Agreement (MCA) only. Cloud
Solution Provider (CSP) subscriptions are not supported.
2. Authentication Model
nOps uses a multi-tenant app called nOps.io. Its app registration lives in nOps’s own tenant. During onboarding, a Global Administrator or Privileged Role Administrator grants admin consent through Microsoft’s standard admin-consent flow. This adds the nOps.io enterprise application (a service principal) to your Microsoft Entra ID tenant. No app registration is created in your tenant, and nOps never stores your credentials.2.1 What the Consent Screen Shows
Microsoft’s consent screen shows the app nOps.io from publisher nOps Inc (verified publisher) and lists exactly these permissions:
The screen also says that if you accept, the app gets access to the specified resources for
all users in your organisation, and no one else will be prompted to review these permissions.
2.2 What Consent Does and Does Not Do
- Consent adds the nOps.io enterprise application to your tenant and approves the permissions above for your whole organisation, so no one else is prompted.
- Consent by itself gives nOps no access to your subscriptions, billing, or storage. nOps only gets Azure access from the roles you assign during setup (Section 4).
- nOps never signs in as your users. The consent callback only receives your tenant ID and whether consent was granted.
- nOps connects using the app’s own identity: app-only tokens from Microsoft Entra ID, with only the roles you assign.
- For the Azure integration, nOps does not call Microsoft Graph.
3. Azure APIs Called
The following tables list the API endpoints nOps calls, grouped by service area. Apart from getting a token (#1) and the optional backfill run (#10), every Savings Analysis call is a read. Calls use the base URL https://management.azure.com unless a full URL is shown.3.1 Sign-In, Subscriptions & Role Assignments
3.2 Billing Account Discovery
Used to find your billing account structure. All calls are reads.nOps does not assign billing roles. For EA, you assign EnrollmentReader yourself by
running a script in Azure Cloud Shell (a PUT to
/providers/Microsoft.Billing/billingAccounts/{id}/billingRoleAssignments/{guid}),
because Microsoft only supports assigning EA billing roles to a service principal through
the REST API. For MCA, you assign the billing role in the Azure portal.3.3 FOCUS Export & Export Files
nOps does not create the FOCUS export or change its settings. You create it during setup. nOps reads its settings, its run history, and the files it writes. If you ask nOps to backfill history, nOps also starts a one-off run of the export for each past month.FOCUS Export Data FlowThe FOCUS export you create writes daily Parquet files to focus-exports/nops-clara
inside the dedicated storage account. The nOps data ingestion service reads these files from outside Azure using static IPs 44.246.45.84, 52.11.53.164, and 52.39.155.200. If you enforce storage firewalls, only these three IPs need to be whitelisted, with “Allow Azure services on the trusted services list” enabled.
3.4 Commitment Management Checks During Verify
For Commitment Management, Verify reads the Lighthouse delegations on each purchase subscription (#3), the billing profile list (#6, MCA billing account), and the two calls below. All of them are reads, made by nOps.io with the Reader and billing reader roles from Savings Analysis.Savings Analysis Verify doesn’t make these calls, and doesn’t check for a Lighthouse delegation.
nOps doesn’t call
listKeys on the export storage account in either tier.3.5 Reservations API (Commitment Management Only)
nOps staff buy in the Azure portal through the Lighthouse delegation, signed in to the nOps tenant, so the portal makes these calls for them. The PUT purchase call (#17) creates a new reservation billed to a purchase subscription. The order is created in the nOps tenant, owned by the staff member who bought it; nOps adds its operations team as a co-owner of every order. No existing resources are modified or deleted.3.6 Savings Plans API (Commitment Management Only)
As with reservations, the Azure portal makes these calls when nOps staff buy. The PUT purchase call (#19) creates a new savings plan billed to a purchase subscription (billingScopeId is
/subscriptions/{id}), in the nOps tenant. No existing resources are modified or deleted.
3.7 APIs nOps Does Not Call
- Azure Advisor (
Microsoft.Advisor) recommendations - Creating Cost Management exports or changing their settings (you create the FOCUS export yourself)
- Assigning billing roles (for EA, you run the EnrollmentReader assignment yourself)
- Microsoft Graph
4. Required RBAC Permissions (Savings Analysis)
The following roles are assigned during the Savings Analysis onboarding process. This is the complete list. The role at the Management Group scope cascades to all subscriptions underneath. The storage-account role is scoped only to the single dedicated nopsfocus storage account.4.1 Management Group Scope
4.2 Storage Account Scope (Dedicated Only)
4.3 Billing Scope
You assign one of these, depending on your billing account type and how you connect it.Not assigned for Savings Analysis: Cost Management Contributor, Monitoring Reader,
Reservations Reader, Savings Plan Reader, Owner on the storage account, any Azure Lighthouse
delegation, and any Azure Policy assignment.
5. Additional Permissions (Commitment Management)
Commitment Management is an optional tier that lets nOps buy and manage Reservations and Savings Plans for you. It adds one Azure Lighthouse delegation, “nOps Commitment Management”, on each purchase subscription (the subscription a purchase is billed to). nOps staff use it from the nOps tenant (9a93f7e1-76f9-4a8d-a15e-5eeb73cf1d18) to buy in the Azure portal. Nothing is
assigned to nOps.io for Commitment Management.
5.1 Purchase Subscription Scope
The delegation gives the nOps Customer Access Operators group these built-in roles:
EA uses one purchase subscription in the enrollment. MCA uses one in each billing profile nOps
buys for, because shared commitments apply per billing profile. Any subscription works; an
empty one keeps purchasing apart from your workloads. Lighthouse can’t delegate Owner, roles
that read data, or permission to assign roles, so none of these can.
Where purchases live. Azure creates a commitment in the tenant of whoever buys it, so the
reservations and savings plans nOps staff buy live in the nOps tenant and are owned by the
buyer. You pay for them through your purchase subscription, they apply to your resources, and
you see them in Cost Management + Billing. Microsoft documents that reservations don’t support
roles assigned through Lighthouse; purchases work, but Microsoft treats this path as unsupported.
If you stop using nOps, nOps moves your reservations to your tenant. Savings plans can’t change
tenant after purchase.
Not assigned for Commitment Management: no roles for nOps.io, no tenant-scope roles
(Reservations Administrator, Reservations Contributor, Savings Plan Reader or Contributor), no
billing write roles (EA Purchaser, Billing account or profile contributor), no Cost Management
Contributor or Monitoring Reader, and no Owner on the storage account.
6. Resources in Your Environment
nOps does not deploy resources into your environment. Admin consent adds the nOps.io enterprise application, and you create everything else yourself during setup.6.1 nOps.io Enterprise Application
Admin consent adds the nOps.io enterprise application (a service principal) to your Microsoft Entra ID tenant. This is the identity used for all API access described in this document. It is not an App Registration: the nOps app registration lives in nOps’s own tenant.6.2 FOCUS Export Resources (Created by You)
You create these in the Azure portal during Savings Analysis setup. nOps does not create them.These resources incur minimal cost: only standard Azure Blob Storage fees for the exported
cost data.
6.3 Required Resource Providers
7. What nOps Does Not Access
The following are out of scope for the nOps Savings Analysis integration. nOps does not call the APIs for these items. Where noted, the Savings Analysis roles in Section 4 also block access.8. Network Requirements
If your organisation enforces firewalls on storage accounts, the following nOps IP addresses must be whitelisted on the FOCUS export storage account. Additionally, ensure Allow Azure services on the trusted services list is enabled on the storage account firewall. If your storage account allows public network access (the default), no firewall configuration is needed.9. Billing Policy Requirements
The following billing policies apply only to Commitment Management. Savings Analysis has no billing policy dependencies.10. Security Summary
The table below summarises the key security properties of the nOps Azure integration for Savings Analysis.For security questions, contact your nOps account team.