Azure
Azure organizational onboarding enables the tenant to seamlessly connect its Azure subscriptions to Upwind, providing centralized visibility, control, and protection across all resources.
Upwind uses Terraform to onboard a tenant. The Terraform deploys all relevant roles so it can access all resources and connect to the Upwind backend. The entire flow and its instructions is documented in the Azure instructions guide.
Resources & Permissions Provisioned
This section details exactly what the onboarding Terraform creates in your Azure environment, and why each role and permission is needed.
Onboarding scope (where the roles are applied)
Onboarding is applied at a configurable scope. The same set of roles is provisioned regardless of which scope is chosen - only the breadth of where they apply changes:
- Tenant (root management group) - roles are assigned at the tenant root, covering every current and future subscription.
- Management group(s) - roles are assigned at one or more management groups, covering the subscriptions beneath them.
- Specific subscriptions - roles are assigned only to an explicit include list, or to all subscriptions minus an exclude list.
The scope is resolved with the following priority: include list → exclude list → tenant root → management groups → all enabled subscriptions. When the optional CloudScanner infrastructure is deployed, one subscription is designated the orchestrator subscription and always receives the scanner infrastructure and its identities, even if it is not otherwise in scope.
1. Identity used by Upwind
Upwind authenticates to the tenant's environment through a single application identity. There are two supported options, covered in the onboarding docs:
- Module-created (default) - onboarding creates an Azure AD (Entra ID) application registration, its service principal, and a long-lived client secret (the credential Upwind stores and uses to authenticate).
- Bring-your-own (BYO) application - the tenant supplies an existing application registration, and onboarding reuses it rather than creating one. Useful when application registration is centrally controlled.
In both cases, all of the Azure read roles below are granted to this application's service principal.
2. Cloud configuration read access (CSPM)
To inventory and assess the tenant's resources, the service principal is granted a set of built-in Azure reader roles at the chosen scope. These are read-only.
| Built-in role | Why it is needed |
|---|---|
| Reader | Baseline read access to inventory all Azure resources and their configuration. |
| Security Reader | Read Microsoft Defender for Cloud security posture, alerts, and recommendations. |
| Key Vault Reader | Read Key Vault metadata and configuration (not secret values). |
| Cosmos DB Account Reader Role | Read Cosmos DB account configuration. |
| Backup Reader | Read backup vault and protection configuration. |
| Log Analytics Reader | Read Log Analytics workspace configuration. |
| Cognitive Services Data Reader | Read Azure AI / Cognitive Services configuration for posture coverage. |
In addition, a small custom role is created and assigned to grant one permission not covered by the built-in readers:
| Custom permission | Why it is needed |
|---|---|
Microsoft.Web/sites/config/list/Action | List App Service / Function App configuration (e.g. app settings) for posture assessment of web workloads. |
3. Microsoft Graph (directory) read access
So Upwind can map identities, groups, and policies for identity posture, the application is granted read-only Microsoft Graph application permissions. These require tenant administrator consent and are all read-only.
These Graph permissions are granted automatically only when onboarding creates the application (the default). For a bring-your-own application, onboarding does not modify the existing app's API permissions - the tenant is responsible for granting the equivalent Graph permissions on its application.
| Graph permission | Why it is needed |
|---|---|
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 (e.g. MFA status). |
4. CloudScanner infrastructure (optional, agentless workload scanning)
The resources in this section are created only when CloudScanner is enabled (i.e. scanner credentials are supplied). They power agentless scanning - disk snapshotting for vulnerability/secret detection, container image scanning, and serverless function scanning. If a tenant onboards for CSPM only, none of section 4 is deployed.
4a. Supporting resources (in the orchestrator subscription)
- Resource group (
upwind-cs-rg-<org-id>) to hold the scanner infrastructure. - Key Vault (
kv-<hash>) - RBAC-enabled, soft-delete + purge protection on - storing the scanner client ID and secret. Optionally locked down with network deny rules + a private DNS zone, and optionally configured with diagnostic logging to a dedicated Log Analytics workspace. - Three user-assigned managed identities, each used by a different scanner component:
- Worker identity (
upwind-cs-vmss-identity-<org-id>) - runs the scans. - Scaler identity (
upwind-cs-scaler-function-identity-<org-id>) - scales the worker fleet up and down. - Disk-encryption identity (
upwind-cs-disk-encryption-identity-<org-id>) - handles encrypted-disk access.
- Worker identity (
4b. Custom roles created and assigned for CloudScanner
| Custom role | Assigned to | Scope | Purpose & key permissions |
|---|---|---|---|
| CloudScannerDeploymentRole (Deployer) | Upwind service principal | Orchestrator subscription | Deploy and manage the scanner infrastructure: resource groups, deployments, Key Vault, Compute, Network, Storage, Operational Insights, Container Apps, managed-identity assignment, and deployment scripts / container instances (for SSH key generation). |
| CloudScannerWorkerRole (Worker) | Worker identity | Orchestrator subscription | Perform scans: read/write/delete disks & snapshots, begin disk access, read disk encryption sets, read VMs/VM scale sets, attach/detach data disks to scale-set instances, and join worker VMs to subnets. |
| CloudScannerScalerRole (Scaler) | Scaler identity | Orchestrator subscription | Scale the worker fleet: read/write/delete VM scale sets and instances, and read/delete disks and snapshots. |
| CloudScannerTargetRole (Target) | Worker identity | Each in-scope target (tenant / management group / subscription) | Reach into tenant workloads to scan them: read VMs/VM scale sets, read disks & disk encryption sets, begin disk access (for snapshotting), pull container images from ACR, and list App Service site config. |
| CloudScannerAppServiceScmRole (App Service SCM) | Worker identity | Each in-scope target | Function scanning only: read App Service sites and access the SCM/publish endpoint (Microsoft.Web/sites/read, Microsoft.Web/sites/publish/Action). |
4c. Built-in roles assigned for CloudScanner
| Built-in role | Assigned to | Scope | Purpose |
|---|---|---|---|
| Storage Blob Data Reader | Worker identity | In-scope targets (or specific function storage accounts) | Read blob data for serverless function scanning. (Function scanning only.) |
| Storage File Data Privileged Reader | Worker identity | In-scope targets (or specific function storage accounts) | Read file-share data for serverless function scanning. (Function scanning only.) |
| Key Vault Crypto Service Encryption User | Disk-encryption identity | Orchestrator subscription | Use customer-managed keys to access encrypted disks during scanning. |
| Key Vault Secrets User | Worker & Scaler identities | The CloudScanner Key Vault | Read the scanner credentials stored in the Key Vault. |
| Key Vault Administrator | Terraform deployer (the operator running onboarding) | The CloudScanner Key Vault | Allows the onboarding run to write the scanner secrets into the Key Vault. |
Summary
For a CSPM-only onboarding, Upwind uses one application identity (created by the module or brought by the tenant) with read-only Azure roles (section 2), one minor custom read permission, and - for module-created apps - read-only Microsoft Graph permissions (section 3). When agentless CloudScanner is enabled, onboarding additionally deploys a self-contained set of scanner resources and the scoped roles in section 4 needed to snapshot and scan workloads. All cross-tenant access uses scoped custom roles or built-in reader roles - no broad owner/contributor-style write access is granted outside the dedicated orchestrator subscription where Upwind manages its own scanner infrastructure.