Azure
Adding an Azure subscription does two things:
- Inventory discovery reads the subscription's resources into Inventory and keeps them current with a daily discovery.
- Group export, optionally, pushes a Group to the subscription as an Azure IP Group, kept in sync automatically, so you can reference it in Azure Firewall policy rules.
Connect signs in to the subscription as a user-assigned managed identity you create, through a federated credential, so you never create or store a client secret.
Before you start
| Prerequisite | Why it's needed | Where to check |
|---|---|---|
| The subscription ID (a GUID) | It identifies the subscription in Connect | Azure portal: Subscriptions |
| Permission to create a subscription-scoped deployment, including a custom role definition and a role assignment (Owner, or User Access Administrator plus Contributor) | The provisioning command creates a resource group, an identity, a custom role, and assigns it | Subscriptions > your subscription > Access control (IAM) |
| Azure CLI, or Azure Cloud Shell, signed in to the tenant | The command uses az stack sub create | Cloud Shell has the CLI preinstalled |
For Group export, you'll also need the Azure region to create IP Groups in. IP Groups are regional resources, and a firewall or policy in any region or subscription can reference them. The firewall's region is the usual choice.
Set up an Azure account
- In Connect, go to Integrations and click New Integration Account.
- Provider: Azure. Enter the Azure Subscription ID, a name, and a project.
- Azure Subscription ID must be the subscription's real ID, because Connect uses it to reach the subscription. Name is just the label shown throughout Connect.
- Under Connect Access, choose Read Only for inventory alone, or Read & Write to also export Groups to this subscription as IP Groups. This choice is permanent. It decides which permissions the provisioning command grants. To change it, delete the account, add the subscription again with the other level, and run the new provisioning command. The command updates the existing deployment stack, so confirm the update when the CLI asks. The new account's first discovery reads the subscription's resources again. If Connect Access shows a single level as a tag, ask FireMon Support to enable the other.
- Click Continue to Provisioning. On the Provision page, copy the Azure CLI command shown there and run it in Cloud Shell or a terminal signed in to your tenant. It downloads two Bicep files and creates a deployment stack named FireMonCloudDefenseStack in the subscription. The
--location westus2in the command is where the FireMonCloudDefense resource group and identity are created; change it if you prefer another region. - The command prints a Tenant ID and a Client ID. Back on the Provision page, enter both, and if you chose Read & Write, enter the Default Region for exported IP Groups (for example
eastus). Save. You see This account has been successfully updated. and the first discovery starts on its own. Saving again later, for example to correct an ID, takes effect at the next daily discovery.
What the command creates
| Resource | Purpose |
|---|---|
| Resource group FireMonCloudDefense | Holds the identity |
| User-assigned managed identity FireMonCloudDefenseIdentity, with a federated credential named CloudDefense | The identity Connect signs in as. Its federated credential trusts Connect's identity provider for your client only |
| A custom role, FireMon Cloud Defense Reader followed by a per-subscription suffix | The built-in Reader role's */read plus Microsoft.Web/sites/config/list/action |
| A role assignment of that role to the identity, scoped to the subscription | Lets Connect read the subscription |
A Read & Write account gets FireMon Cloud Defense Contributor, followed by the same kind of suffix, instead of Reader. It adds exactly Microsoft.Network/ipGroups/write and delete, plus Microsoft.Resources/subscriptions/resourceGroups/write, which is what managing IP Groups needs.
Verify it landed
| What to check | Where to look |
|---|---|
| The IDs are saved | The Provision page's Status card shows a Provisioned tag. The first discovery confirms the IDs work |
| Connect can sign in | After the first discovery, the Provision page shows no Resource Errors banner and the subscription's resources appear under Inventory |
| The account is healthy | Integrations: the Azure row's Status stays clear |
| The resources themselves | Inventory > Resources, filtered by Vendor > Azure. Supported resources lists what discovery covers |
| What was created in Azure | Portal: resource group FireMonCloudDefense containing the identity, and under Subscriptions > Access control (IAM) > Role assignments, the FireMon Cloud Defense Reader or Contributor role assigned to it |
Export a Group as an IP Group
The account must have been created with Read & Write, and its Default Region must be set. Connect lists an Azure account under Export To once both are true, and names any Azure account it left out beneath the field.
- In Connect, go to Groups > New Group (or edit an existing one).
- Set Update to Automatic so membership stays current on its own.
- Pick the Project.
- Under Export To, select your Azure account.
- Build the membership filters and confirm the preview under Group Candidates shows what you expect.
- Save. The warning that saving exports all current matches to the targets above is expected.
Update and Project are fixed once the Group exists; see Creating a Group. Membership caps at 10,000 items; see Group size limits. The 5,000-entry IP Group limit below is stricter.
The export runs shortly after each save and each membership update. Check the result in Azure.
What Connect creates in Azure
| Resource | Details |
|---|---|
| Resource group Connect-Groups | Created on the first export, in the account's Default Region at the time. All IP Groups go here |
| One IP Group per exported Group | Created in the account's Default Region. Named after your Group with unsupported characters replaced by hyphens, truncated to fit 80 characters, and the last 8 characters of the Group's ID appended, so Blocked Ranges becomes something like Blocked-Ranges-Q69G5FAV. Tagged managedBy: connect |
Each export replaces the IP Group's address list with the Group's current IPv4 members: addresses, CIDRs, and hyphenated ranges, the formats IP Groups accept. The export carries IPv4 only; IPv6 members stay in Connect.
Verify it landed
In the Azure portal, open IP Groups (or the Connect-Groups resource group) and select the group named after your Connect Group. Its IP addresses should match the Group's IPv4 members. To find everything Connect manages, filter resources on the tag managedBy : connect.
Use the IP Group in your policy
Reference the IP Group as a source or destination in a rule of your Azure Firewall policy (choose IP Group as the source or destination type). It starts affecting traffic once a rule references it. The IP Group keeps its identity across exports, so the reference survives membership changes.
How changes are handled
| Action | Result |
|---|---|
| Edit the Group's filters, or a resource gains or loses a matching tag | The IP Group's address list is replaced on the next export. |
| Rename the Group | A rename creates a new IP Group under the new name. The old one stays, so any rule still referencing it keeps working, but it stops receiving updates. Repoint those rules at the new IP Group, then delete the old one in Azure. |
| Remove the Azure account from Export To | The IP Group is deleted from Azure. |
| Delete the Group | The IP Group is deleted from Azure. |
| Change the account's Default Region | IP Groups created from then on go to the new region. Existing IP Groups stay where they were created, because Azure keeps a resource in its region. To move one, remove the account from the Group's Export To, save, add it back, and save again. Then repoint any rule that referenced it. |
| Clear the account's Default Region | First remove the account from each Group's Export To, which deletes those IP Groups. Once a region is set again, the account is offered under Export To as before. |
| The Group has no IPv4 members left | The IP Group is emptied. Azure skips any rule that references an empty IP Group. |
| Delete the Azure account in Connect | The account is removed from every Group's Export To. IP Groups already in Azure stay there. Remove them in Azure; the tag managedBy : connect finds them. |
| Edit the IP Group's addresses or tags in Azure | Overwritten on the next export. |
Azure keeps an IP Group that a firewall or policy rule still references. If a rule still uses the IP Group when its Group is deleted or un-targeted, remove the rule's reference, then delete the IP Group in Azure.
Details and edge cases
An IP Group holds up to 5,000 entries, counting each address, CIDR, or range as one. Connect exports a Group while it is under that limit. Past it, exports stop and the IP Group keeps its last contents. Keep each exported Group under the limit, splitting it into narrower Groups where needed, and after enlarging a Group confirm in Azure that its IP Group picked up the change.
A firewall policy can reference up to 600 IP Groups, and Azure recommends at most 50 per classic firewall.
Azure applies each write in the background. When firewalls reference the IP Group, Azure can take a few minutes. The IP Group's Provisioning state in the portal shows when the write has been applied. If it shows Failed, check the firewall's status, then save the Group again to resend the export.
Inventory and export use the same identity. A permissions problem shows up in both: as Resource Errors on the Provision page for discovery, and as a missing IP Group for export. Confirm the role assignment exists under the subscription's Access control (IAM).
For common issues, see Troubleshooting.
Azure documentation
- IP Groups in Azure Firewall: what an IP Group is, its limits, and how to reference one in a rule
- Deployment stacks: the
az stack sub createcommand the provisioning step uses - Federated identity credentials for a user-assigned managed identity: how Connect signs in without a secret
- Azure custom roles: the role the command creates