Prerequisites

Overview

To successfully integrate your Azure environment with Upwind using the SaaS deployment model, ensure the following prerequisites are met. Select the deployment method that matches your setup - Terraform or Azure Resource Manager (ARM) templates - to see its prerequisites.

No scanner quota needed

With SaaS, the CloudScanner compute runs in Upwind-managed subscriptions, so you do not need to reserve Spot VM quota or any other scanner capacity in your own subscriptions.

Terraform

1. Access to your Azure tenant. Ensure you can sign in to the Azure tenant you are connecting with an identity that is permitted to create the required identities and role assignments.

2. Azure CLI authentication. Ensure the Azure CLI is installed and that you are logged in (az login) to the correct tenant. The readiness check in the onboarding flow runs through the Azure CLI.

3. Terraform installation. Ensure Terraform is installed on your local machine. You can download the latest version of Terraform from the official website. Follow the installation instructions specific to your operating system.

4. Permissions to create the Upwind service principals. When you let onboarding create the service principals for Upwind (the default), the identity running Terraform must be able to create service principals in your Microsoft Entra tenant - for example, through the Cloud Application Administrator or Application Administrator Entra role. If it cannot, have your Entra administrator provision them first and use existing service principals instead.

5. Permissions to assign roles at the connected scope. The identity running Terraform must be able to create role assignments at the scope you connect - for example, the Owner role over the tenant root management group, management groups, or subscriptions in scope. To onboard at the tenant or management-group scope, you may first need to elevate access to manage the tenant root.

Azure Resource Manager

1. Access to your Azure tenant. Ensure you can sign in to the Azure tenant you are connecting with an identity that is permitted to create the required identities and role assignments.

2. Azure CLI authentication. Ensure the Azure CLI is installed and that you are logged in (az login) to the correct tenant. Both the readiness check and the ARM deployment script run through the Azure CLI.

3. Permissions to create the Upwind service principals. When you let onboarding create the service principals for Upwind (the default), the identity running the deployment must be able to create service principals in your Microsoft Entra tenant - for example, through the Cloud Application Administrator or Application Administrator Entra role. If it cannot, have your Entra administrator provision them first and use existing service principals instead.

4. Permissions to assign roles at the connected scope. The identity running the deployment must be able to create role assignments at the scope you connect - for example, the Owner role over the tenant root management group, management groups, or subscriptions in scope. To onboard at the tenant or management-group scope, you may first need to elevate access to manage the tenant root.

5. Azure Deployment Stack Contributor role. ARM template onboarding deploys resources using deployment stacks, which requires the built-in Azure Deployment Stack Contributor role at the onboarding scope, in addition to the role-assignment permissions above. The readiness check does not verify this role, so confirm it is assigned before deploying.

tip

The Readiness check in the onboarding flow runs a preflight script that validates these prerequisites for you and highlights any missing access before you proceed.

Service Principals for the Upwind Applications

SaaS onboarding uses two multi-tenant applications registered in Upwind's own Microsoft Entra tenant: a Fetcher application and a Snapshot application. Onboarding does not create an application registration or a client secret in your tenant. Instead, a service principal for each Upwind application must exist in your tenant, and the Azure roles are assigned to those service principals.

Application	Service principal in the console	Client ID in the generated snippet	Used for
Fetcher	Onboarding Service Principal	fetcher_app_client_id	Read-only discovery and inventory through Azure Resource Manager, and read-only Microsoft Graph access for identity posture.
Snapshot	Scanner Service Principal	snapshot_app_client_id	The customer-side scan workflow: creating snapshots, authorizing the cross-tenant snapshot copy, and deleting snapshots after the scan.

For the roles each service principal holds, see Architecture.

This splits cleanly across teams: your Entra administrator provisions the two service principals, and your Azure administrator runs the onboarding deployment that assigns their roles. If you hold both sets of privileges, do them in that order.

note

If the identity running the deployment can create service principals in Microsoft Entra, choose Create a new Service Principal during onboarding and skip the rest of this section - the deployment provisions both service principals for you.

What to Ask Your Entra Administrator For

In the Assign the required Azure roles step of the onboarding flow, keep Create a new Service Principal selected and copy both application client IDs from the Terraform or ARM snippet the console generates. In the Terraform snippet they are fetcher_app_client_id and snapshot_app_client_id; in the ARM snippet they are the Fetcher and Snapshot app client ID parameters. Then send your Entra administrator the following.

Item	Value
Operation	Create a service principal (enterprise application) for each of two existing multi-tenant applications
Application (client) IDs	The Fetcher and Snapshot app client ID values from the console
Target tenant	Your Microsoft Entra tenant ID
Return to you	The Object ID of each created service principal, labeled Fetcher or Snapshot

Select Use an existing Service Principal in the onboarding flow and enter the returned Object IDs:

• Onboarding Service Principal Object ID: the Object ID of the Fetcher service principal.
• Scanner Service Principal Object ID: the Object ID of the Snapshot service principal.

warning

Enter the service principal Object ID, not the application (client) ID. Swapping the two Object IDs also fails validation, because each service principal holds a different set of roles.

Each service principal can be created in either of two ways. They differ in the Entra role required and in whether Microsoft Graph consent is included. For background, see Create an enterprise application from a multitenant application .

Option A: Tenant-Wide Admin Consent

Requires the Privileged Role Administrator role. Substitute the values and open each URL in a browser, once for the Fetcher application and once for the Snapshot application:

https://login.microsoftonline.com/<tenant-id>/adminconsent?client_id=<fetcher-app-client-id>
https://login.microsoftonline.com/<tenant-id>/adminconsent?client_id=<snapshot-app-client-id>

Accepting creates the service principal in your tenant and grants any Microsoft Graph permissions the application requests in a single step. For the Fetcher application, this includes Upwind's read-only Microsoft Graph permissions. See Grant tenant-wide admin consent .

After consenting, look up the Object ID of each service principal:

az ad sp show --id <fetcher-app-client-id> --query id -o tsv
az ad sp show --id <snapshot-app-client-id> --query id -o tsv

Option B: Create the Service Principals Only

Requires Cloud Application Administrator or Application Administrator. Neither role can consent to Microsoft Graph application permissions, so use this option when tenant-wide consent needs separate approval, and have consent for the Fetcher application's Microsoft Graph permissions granted afterwards.

az ad sp create --id <fetcher-app-client-id>
az ad sp show --id <fetcher-app-client-id> --query id -o tsv

az ad sp create --id <snapshot-app-client-id>
az ad sp show --id <snapshot-app-client-id> --query id -o tsv

The az ad sp show commands return the Object IDs to hand back.

Microsoft Graph Permissions Requested

The Fetcher application uses these to map identities, groups, and policies for identity posture. All are read-only.

Permission	Purpose
User.Read.All	Read user profiles in the directory.
Group.Read.All	Read groups and group memberships.
RoleManagement.Read.All	Read directory role and RBAC assignments.
Directory.Read.All	Read general directory data.
Policy.Read.All	Read conditional access and other directory policies.
UserAuthenticationMethod.Read.All	Read users' registered authentication methods, such as MFA state.