Azure

Azure connects your cloud infrastructure into Navigator: virtual machine inventory, and vulnerability findings on those VMs from Microsoft Defender for Cloud.

Beta. This connector was built from Azure’s documentation and hasn’t been verified against a live account yet. It may return incomplete data or fail in ways we haven’t seen. If something looks wrong, contact support@chartingcyber.com.

At a glance

Required permissions

Create (or reuse) an Azure app registration, then assign it an Azure RBAC role. This is a different kind of permission than the other Microsoft connectors use: Entra ID, Intune, and Defender grant Graph API permissions inside the app registration itself; Azure instead needs a role assignment (IAM), since it’s reading Azure Resource Manager data (virtual machines and Defender for Cloud findings), not Microsoft Graph data.

Do not add any Microsoft Graph “API permissions” for this connector (the “API permissions” blade inside the app registration itself, where Entra ID/Intune/Defender’s permissions live) — a Graph permission like PrivilegedAccess.Read.AzureResources looks plausibly related (it’s about Azure resources) but is unrelated to what this connector needs and will not work; it grants read access to Entra Privileged Identity Management data, not to Azure Resource Manager. If you’ve added a Graph permission for this app registration hoping it would cover Azure, remove it — it isn’t required and isn’t sufficient.

The exact role, by its exact name, is Reader (a built-in Azure RBAC role, category “General,” full description “View all resources, but does not allow you to make any changes”). It is assigned entirely outside the app registration’s own pages, via Access control (IAM) on a management group/subscription — never via Entra ID’s “Roles and administrators” blade. That blade lists a completely different, unrelated catalog of Entra directory roles (Global Reader, Directory Readers, Security Reader, etc.) — Reader (the Azure RBAC role this connector needs) will never appear there, however you search. If you searched for “Reader” and didn’t find it, this is almost certainly why — you were very likely looking at Entra ID’s role list, not Azure’s.

Either way, Reader is read-only and sufficient for both APIs this connector calls (Azure Resource Graph and Defender for Cloud sub-assessments) — no write access is needed anywhere.

Step 0: elevate access (root management group path only — skip if scoping per subscription)

Nobody has access to the root management group’s Access control (IAM) page by default — not even a Global Administrator — because Microsoft Entra ID and Azure RBAC are deliberately separate authorization systems. A Global Administrator has to briefly elevate access first:

1. Sign in to the Azure Portal as a Global Administrator.
2. In the top search bar, type “Microsoft Entra ID” and select it (this is the Entra ID overview blade, not any specific sub-page yet).
3. In its left sidebar, click Properties.
4. Set Access management for Azure resources to Yes, click Save, then sign out and back in (the new access doesn’t take effect until you do).
5. This temporarily grants you the User Access Administrator role at the root scope — enough to complete the steps below. Once you’re done, come back to this same Properties page and set the toggle back to No. The Reader role you grant to the app registration is permanent either way; only your own elevated access is temporary and should be removed once this one-time setup is done, per Microsoft’s own least-privilege guidance.

Exact click-by-click navigation to assign the Reader role

The two most common ways to end up in the wrong place: searching for the role inside Microsoft Entra ID instead of a management group/subscription’s own Access control (IAM) page, and searching for the role by typing into the wrong box (the role picker has both a category-tab view and a free-text search — use the search box, not the tabs, if Reader doesn’t immediately jump out). Follow these steps exactly:

1. In the Azure Portal’s top search bar (not the Entra ID blade), type “Management groups” and select it from the results.
2. Click Tenant Root Group in the list (its name may also just be your tenant’s display name, followed by “(Tenant Root Group)”).
3. In the left-hand sidebar of the Tenant Root Group’s own page, click Access control (IAM). (This sidebar is scoped to the management group you clicked into — it is not the same “Access control (IAM)” you might see elsewhere, e.g. on a single resource.)
4. Click + Add near the top, then Add role assignment from the dropdown.
5. On the Role tab, use the search box (not the “Privileged administrator roles”/“Job function roles” category tabs) and type Reader. Select the role named exactly Reader — description “View all resources, but does not allow you to make any changes.” Do not select “Reader and Data Access,” “Storage Blob Data Reader,” or any other role with “Reader” in the name; those are unrelated, narrower roles for other services.
6. Click Next to reach the Members tab. Near the top, “Assign access to” offers two options — User, group, or service principal vs Managed identity. These look similar but search entirely different sets of objects: Managed identity only searches actual Azure managed identities (like the ones this app’s own infrastructure uses internally) and will never show an app registration, no matter what you type. Make sure User, group, or service principal is selected — this is the one that includes app registrations.
   • Before searching, go find the exact name to type: Entra ID → App registrations → (your app) → Overview, and copy the Display name field shown there. Don’t search by the Application (client) ID (a GUID) — the picker searches by display name, not by ID.
   • Click + Select members, type the display name (the first 3-4 characters is usually enough — the search runs asynchronously, so give it a moment after typing before assuming it found nothing), and confirm your app registration appears in the results list (it’ll have a small app/gear-style icon distinguishing it from actual user accounts in the same results).
   • If it still doesn’t appear with the correct toggle selected: check Entra ID → Enterprise applications → All applications for the same name. Every app registration automatically gets a matching Enterprise Application (its service principal) in the same tenant — if it’s missing there too, the app registration was likely just created and hasn’t finished propagating yet (usually resolves within a minute or two; try again shortly).
   • Once found, select it, click Select, then Review + assign (twice — there’s a confirmation step).
7. Turn off the elevated access from Step 0 (Entra ID → Properties → Access management for Azure resources → No) — it’s no longer needed.

If you’d rather scope this to one or a few specific subscriptions instead of the whole tenant, skip Step 0 entirely (no elevation needed for a subscription you already have Owner/User Access Administrator on) and replace steps 1–3 above: search for “Subscriptions” instead of “Management groups,” click into the specific subscription, then its own Access control (IAM) in the left sidebar. Repeat for each additional subscription you want included.

Setup

1. In the Azure Portal, go to Entra ID → App registrations and create a new app registration (or reuse one you’ve already set up for Entra ID, Intune, or Defender).
2. Under Certificates & secrets, create a new client secret and copy its value immediately. It’s only shown once.
3. Note your Tenant ID and the app registration’s Client ID.
4. Assign the Reader Azure RBAC role to this app registration — see Required permissions above for the exact role name and click-by-click navigation. Do not add anything under this app registration’s own API permissions page for this connector.
5. In Navigator, go to Connectors → Add a Connector → Azure.
6. Enter the Tenant ID, Client ID, and Client Secret. Leave Subscription IDs blank — Navigator auto-discovers every subscription the app registration can now see (all of them, if assigned at the root management group). Only enter a comma-separated list if you deliberately want to limit Navigator to a subset.
7. Save. Navigator validates the credentials and enqueues a first sync immediately.

Vendor documentation

Microsoft’s own instructions: Register an application with the Microsoft identity platform for the app registration steps, Elevate access to manage all Azure subscriptions and management groups and Assign Azure roles using the Azure portal for the Reader role assignment, and Azure Resource Graph: Resources plus Defender for Cloud: Sub-assessments - List All for the two APIs this connector calls.

What data this connector provides

• Devices: virtual machines across every subscription in scope (either the list you entered, or every subscription your Reader role assignment covers if left blank), via Azure Resource Graph. Includes hostname, OS platform (Windows or Linux), VM size (used as the closest analog to a physical device’s model field), and MAC address.
• Vulnerabilities: active findings on those VMs from Microsoft Defender for Cloud’s vulnerability assessment, including CVE IDs and severity where available. Only findings currently flagged as active are ingested, not resolved or not-applicable checks.

Known limitations

• IP addresses aren’t populated yet. Getting them requires a further lookup against each VM’s network interface (and, for a public IP, one more lookup beyond that), which isn’t wired up in this first version.
• Hardware specs (CPU, RAM, storage) aren’t populated. Azure reports a VM’s size as a name (like Standard_D2s_v3) rather than actual numbers, and translating that into real specs needs a separate, region-specific lookup this connector doesn’t perform yet.
• OS version detail beyond “Windows” or “Linux” isn’t populated. The only version-like field available reflects what image the VM was originally deployed from, not its current patched state, so it’s deliberately left out rather than shown as if it were current.
• Software inventory isn’t available through this connector. Real per-VM installed-software data requires Azure’s Change Tracking & Inventory feature, a separate setup with its own prerequisites, and isn’t ingested from this connector today.
• A virtual machine’s own device record has no Entra directory identity attached. If you’ve also connected Entra ID, Intune, or Defender, matching between an Azure VM and the same device reported by those connectors relies on hostname and MAC address rather than an exact ID match.