Configure Cloud Workloads Visibility for Azure

Taylor Colwell

Introduction

Elisity Cloud Control Center (CCC) supports connectivity to Microsoft Azure as a cloud workload connector. Azure virtual machines are discovered into IdentityGraph as workload identities, matched by Policy Groups, and enforced under the same policy framework that governs on-premises endpoints. This extends Elisity’s identity-based microsegmentation from the campus and data center network into Azure, so a single set of policies covers traditional endpoints and cloud workloads.

Discovery is the first stage of that workflow rather than the end of it. Each discovered virtual machine carries its instance attributes, Azure tags, network interfaces, and power state into IdentityGraph, where it becomes eligible for Policy Group membership. Policy is enforced on the Effective Enforcement IP of each network interface, and the Workload Distribution Zone assigned to the discovery endpoint determines where the policy mappings for that endpoint’s workloads are published for enforcement.

The Azure connector authenticates to a Microsoft Entra ID tenant using a service principal and discovers the virtual machines in every Azure subscription that the service principal can read, and it keeps those virtual machines synchronized with Azure. Azure is configured as its own connector with its own credential model, separate from the Amazon Web Services connector. For AWS workload discovery, see Configure Cloud Workloads Visibility for AWS.

This article covers the following configuration workflow:

Enabling the Workloads feature in Advanced Settings
Configuring the Azure connector with Entra ID service principal credentials
Assigning a Workload Distribution Zone to the Azure discovery endpoint
Viewing discovered workloads in IdentityGraph
Applying policy to the discovered Azure workloads

This article covers the discovery and policy enforcement of Azure virtual machines as workloads in IdentityGraph. For deploying an Elisity Virtual Edge as a virtual machine inside Azure, see Azure Cloud-Hosted Virtual Edge.

Prerequisites

Administrator access to Elisity Cloud Control Center
A Microsoft Entra ID application registration in the target Azure tenant, with a client secret. Record the Directory (tenant) ID, the Application (client) ID, and the client secret value, which is displayed only at the time the secret is created.
The Reader role assigned to that application’s service principal on each Azure subscription to be discovered. Reader is sufficient. Elisity does not require write or action permissions on any Azure resource.
At least one virtual machine in a target subscription for discovery validation
A Distribution Zone of type Workload. An Azure discovery endpoint cannot be saved until a Workload Distribution Zone is assigned to it. See Distribution Zones for how to create one.

Enable the Workloads Feature

The Workloads capability is an advanced feature that must be enabled before the Azure connector and Workloads navigation become available.

Step 1. Enable Workloads in Advanced Settings

Navigate to Settings > System > Advanced. Locate the Workloads tile and toggle Enable Workloads to the on position.

After enabling Workloads, the left navigation updates. The IdentityGraph menu displays a Workloads entry alongside Devices, Users, and Connectors, and the Add Connector dialog displays the Microsoft Azure connector option.

The Workloads feature must be enabled before any cloud connector configuration or workload visibility is available in Cloud Control Center.

Configure the Azure Connector

After enabling Workloads, configure the Azure connector to establish connectivity to your Azure tenant and begin discovering virtual machines.

Step 2. Select Microsoft Azure

Navigate to IdentityGraph > Connectors and click + Add Connector. In the Add Connector dialog, locate Microsoft Azure and click Configure.

The Add Microsoft Azure form opens.

Step 3. Enter the Service Principal Credentials

Prepare the Azure Tenant

The connector authenticates as a Microsoft Entra ID application registration, also called a service principal. Complete the following in the Azure portal before you fill in the connector form. Cloud Control Center presents the same guidance beside the form.

Register an Application in Microsoft Entra ID

In the Azure portal, go to Microsoft Entra ID > App registrations and click + New registration.

On the Register an application page, enter a name that identifies the integration, such as Elisity Cloud Control Center Workload Discovery. Leave Supported account types set to single-tenant — each connector authenticates to one Entra ID tenant — and leave Redirect URI empty, because Elisity authenticates as a service, not on behalf of a signed-in user. Click Register.

On the application’s Overview page, record the Directory (tenant) ID and the Application (client) ID. These are the values entered as Tenant ID and Client ID on the connector form.

Create a Client Secret

On the application registration, go to Certificates & secrets and open the Client secrets tab, then click + New client secret.

In the Add a client secret panel, enter a description and select an expiry period, then click Add.

Record the secret Value as soon as it is created, and record the expiry date alongside it.

Important: Azure displays the client secret value only once, at the moment it is created. If the value is not recorded before you leave the page, the secret cannot be retrieved and a new one must be generated.

Assign the Reader Role

The application’s service principal must hold the built-in Reader role on every Azure subscription to be discovered. In the Azure portal, go to Subscriptions, select the subscription, then go to Access control (IAM) and select Add > Add role assignment.

On the Role tab, search for reader and select the built-in Reader role, which grants the ability to view all resources without permitting any change.

On the Members tab, click Select members, search for the application registration you created, and select it.

On the Review + assign tab, confirm that the role is Reader, that the scope is the intended subscription, and that the selected application is listed as the assigned member, then complete the assignment.

The equivalent Azure CLI command is az role assignment create --assignee <client-id> --role Reader --scope /subscriptions/<subscription-id>.

To limit discovery to part of a subscription, assign the Reader role at the resource group scope instead of the subscription scope. The connector then discovers only the virtual machines in those resource groups. The service principal can hold Reader on several subscriptions within the same tenant, which allows one connector to span them.

Why Reader is sufficient

Reader is both the minimum and the only role the connector requires. It grants the read-only operations Elisity uses to discover and synchronize workloads. Unlike AWS, Azure requires no custom policy document, because the built-in role already covers every permission needed:

Azure Resource Manager operation	Purpose
`Microsoft.Compute/virtualMachines/read`	Lists virtual machines and reads their configuration
`Microsoft.Compute/virtualMachines/instanceView/read`	Reads power state and agent status
`Microsoft.Network/networkInterfaces/read`	Reads network interface and IP configuration detail
`Microsoft.Network/publicIPAddresses/read`	Resolves public IP allocation and assignment
`Microsoft.Network/virtualNetworks/read`	Enumerates virtual networks and subnets
`Microsoft.Network/networkSecurityGroups/read`	Reads the network security groups associated with interfaces and subnets
`Microsoft.Resources/subscriptions/read`	Enumerates subscriptions in the tenant
`Microsoft.Resources/subscriptions/resourceGroups/read`	Enumerates resource groups in a subscription
`Microsoft.Compute/locations/read`	Enumerates the available Azure regions

Important: Elisity never requires write or action permissions on any Azure resource. Do not assign Contributor, Owner, Virtual Machine Contributor, or any other role that grants write access.

Complete the connector form with the identifiers and secret from the Entra ID application registration.

The form contains the following fields:

Field	Description
Connector Name	Required. A name that identifies this Azure discovery endpoint in Cloud Control Center.
Tenant ID	Required. The Directory (tenant) ID of the Microsoft Entra ID tenant, entered as a GUID.
Client ID	Required. The Application (client) ID of the Entra ID application registration, entered as a GUID.
Client Secret	Required. The client secret value generated for the application registration. The field is masked; use the visibility control to reveal the entered value or the clear control to remove it.
Workload Distribution Zone	Required. The Distribution Zone that the workloads discovered by this endpoint are published under. See Step 4.
Secret Expiry Date	Optional, but strongly recommended. The expiration date of the client secret, exactly as recorded in Azure. Cloud Control Center uses this date to raise health warnings as the secret approaches expiry. Always set it: without it Cloud Control Center cannot warn you, and discovery stops with no notice on the day the secret lapses.

The connector authenticates with a client secret, and every client secret expires. Always record the Secret Expiry Date when you create the connector. It is the only thing that lets Cloud Control Center warn you before the secret lapses; without it the connector stops synchronizing without warning and discovery goes stale.

Step 4. Assign a Workload Distribution Zone

Create the Workload Distribution Zone before you begin. A Workload Distribution Zone is a prerequisite for onboarding Azure, not a step within it. The connector form only selects an existing zone — it cannot create one, and the endpoint cannot be saved until a zone is assigned. Create the zone first, then return to this form. See Distribution Zones for how Workload Distribution Zones work and how to create one.

Open the Workload Distribution Zone list and select the Distribution Zone for this endpoint.

The following rules apply to the assignment:

The Distribution Zone must be of type Workload. Distribution Zones of other types are not listed.
The endpoint cannot be saved until a Workload Distribution Zone is assigned. No Workload Distribution Zone is created automatically, and there is no default selection.
Several discovery endpoints can reference the same Workload Distribution Zone.
If no Workload Distribution Zone exists yet, create one under Edge Management > Distribution Zones. It becomes selectable as soon as it is available.

To create one, navigate to Edge Management > Distribution Zones, click Create Distribution Zone, select the Workload Distribution Zone type, and name the zone.

Every workload the endpoint discovers inherits the endpoint’s Workload Distribution Zone. Changing the assignment on an endpoint reassigns every workload that endpoint discovered and republishes those workloads under the new Distribution Zone.

A Workload Distribution Zone is not bound to a site, and it has no Intelligent Tag Distribution setting of its own. The prefixes it contributes are still distributed to Access Distribution Zones that have Intelligent Tag Distribution enabled, unless Suppress Tag Distribution is turned on for the Workload Distribution Zone. For creating and managing Distribution Zones, see Distribution Zones.

Step 5. Test the Connection and Add the Connector

Click Test. Cloud Control Center authenticates to Microsoft Entra ID with the supplied credentials and confirms that the service principal can read subscriptions in the tenant. While the check runs, the button reads Testing connection.... On success, Cloud Control Center reports Connected successfully and confirms that the credentials were verified. The button then reads Re-Test, so you can revalidate after editing any field.

Add becomes available only after the connection test succeeds. Click Add to create the connector, or Cancel to discard the form.

Important: If the connection test fails, Cloud Control Center reports the reason. Confirm the Tenant ID and Client ID against the application registration in Azure, confirm the client secret is current, and confirm that the Reader role is assigned to the service principal on at least one subscription. See the Troubleshooting table for the individual test results and their resolutions.

Discovery Scope

Each Azure connector authenticates to a single Entra ID tenant, and it discovers virtual machines in every subscription in that tenant where the service principal holds the Reader role. Role assignment in Azure therefore defines the discovery scope: assign Reader on the subscriptions you want represented in IdentityGraph, and withhold it on the subscriptions you do not.

A single connector can span multiple subscriptions within one tenant. To discover virtual machines in more than one Entra ID tenant, add a separate connector for each tenant.

Cloud Control Center polls Azure at a five-minute interval by default and updates the attributes, network interfaces, and power state of the discovered virtual machines on each cycle. Virtual machines that are deleted in Azure are removed from IdentityGraph on the sync cycle that no longer returns them.

View Discovered Workloads

After the Azure connector completes its initial discovery cycle, discovered virtual machines appear in the Workloads section of IdentityGraph.

Step 6. Navigate to the Workloads Page

Navigate to IdentityGraph > Workloads. The Workloads page displays a summary dashboard and a searchable table of all discovered cloud workloads. Azure virtual machines appear alongside workloads discovered by other cloud connectors, with the cloud provider identified on each row. Filter or search the table to isolate the Azure workloads.

The summary dashboard groups the discovered workloads By Region, By Virtual Network, and By Instance Type. The table below it reports the hostname or instance identifier, provider, status, IP addresses, enforcement IP address, instance type, region, and platform of each workload.

The workload status reflects the power state reported by Azure. Azure reports both a stopped and a deallocated power state, and Cloud Control Center displays both as Stopped while preserving the Azure power state on the workload record.

Workload Details

Select a workload to open its details. The details view presents the instance attributes that Cloud Control Center imports from Azure, the tags applied to the virtual machine in Azure, and the fields that administrators maintain in Cloud Control Center. Azure resource identifiers are long; Cloud Control Center shortens them for display and shows the full identifier in a tooltip.

A Workload Information summary at the top of the view reports the cloud provider, the primary IP address, and the Workload Distribution Zone assigned to the workload, with the current power state shown as a status badge. Below the summary, the IdentityGraph tab groups the imported attributes into Instance Details, Labels and Tags, and Manually Configured.

Network Interfaces

The Network Interfaces tab lists every network interface attached to the virtual machine. Azure virtual machines can carry more than one interface, and each interface is modeled separately with its own IP addresses, subnet, and the network security group applied to that interface.

Each interface lists its addresses in a searchable IP Addresses table that reports the address, the address type, the DNS name, and the associated public IP address where one is assigned. The address that Azure designates as primary for the interface is marked Primary.

Cloud Control Center displays the network security group applied at the interface level. Network security groups applied at the subnet level in Azure are not displayed.

Apply Policy to Azure Workloads

A discovered Azure virtual machine is a policy subject, not an inventory record. Once a workload is present in IdentityGraph, it is matched by Policy Groups and governed by the policies written against those Policy Groups, in the same way as an endpoint discovered on the on-premises network.

Policy Group Membership

Azure workloads participate in Policy Groups on the same terms as every other identity in IdentityGraph. A workload that satisfies the match criteria of a Policy Group joins that Policy Group, and each policy that references the Policy Group then governs the workload. The instance attributes, Azure tags, and Cloud Control Center labels that a workload carries are listed on the IdentityGraph tab of its details view, so a workload can be placed in a Policy Group by its role, environment, or application tier rather than by its address.

Enforcement IP Resolution

Policy is enforced on the Effective Enforcement IP of each network interface. Cloud Control Center derives that value from the interface Enforcement IP after resolving the address against every network device and every other workload interface. The Enforcement IP Address column on the Workloads page reports each workload’s enforcement address. An interface whose address cannot be resolved uniquely shows -- in this column.

Resolution follows these rules:

Network devices take absolute priority over workloads. If a workload interface holds the same Enforcement IP as a device in any Distribution Zone, that interface has no Effective Enforcement IP.
If two workload interfaces hold the same Enforcement IP, neither takes precedence and neither receives an Effective Enforcement IP. Removing one interface restores the Effective Enforcement IP of the other.
If an interface already holds an Effective Enforcement IP and a device carrying that address is discovered afterward, the interface is detached and loses its Effective Enforcement IP.
Where an address resolves in both the static and the cloud-sourced layer, the static value takes priority.

Important: An interface with no Effective Enforcement IP is not matched by policy. Correct the duplicate address on the workload or on the device, then confirm on the Workloads page that the workload reports an Enforcement IP Address again.

Policy Distribution

The Workload Distribution Zone assigned to the discovery endpoint determines where the policy mappings for that endpoint’s workloads are published. Every workload the endpoint discovers inherits that zone, and the prefixes the zone contributes are distributed to the Access and Core Distribution Zones that have Intelligent Tag Distribution enabled, unless Suppress Tag Distribution is turned on for the Workload Distribution Zone. Reassigning the zone on an endpoint republishes every workload that endpoint discovered under the new Distribution Zone.

Operationalization

Connector Status

After adding the Azure connector, verify its status by navigating to IdentityGraph > Connectors. The Microsoft Azure connector displays an Active status when Cloud Control Center is authenticating to Azure and discovering virtual machines at the configured interval. Expand the Azure connector row to display the discovery endpoint beneath it with its own status. Use the row actions menu on the connector endpoint to edit, sync, or delete it.

Client Secret Rotation

Azure client secrets expire. Cloud Control Center tracks the Secret Expiry Date recorded on the connector and raises connector health warnings at 30 days, 7 days, and 1 day before the secret expires. If the secret expires, the connector moves to an Inactive status and discovery stops until a valid secret is supplied.

To rotate the secret, generate a new client secret on the Entra ID application registration, then edit the Azure connector and replace the Client Secret value and the Secret Expiry Date. Run Test to confirm the new secret, then save. The connector does not need to be deleted and recreated, and the workloads it discovered are retained.

Verification

To confirm that the Azure cloud workloads integration is functioning correctly:

Navigate to IdentityGraph > Connectors and confirm the Microsoft Azure connector reports an Active status.
Navigate to IdentityGraph > Workloads and confirm that virtual machines from the target subscriptions appear in the workload list.
Select an individual Azure workload and confirm that its instance attributes and Azure tags are populated.
Open the Network Interfaces tab on the workload and confirm that each interface reports its IP addresses, subnet, and network security group.
Navigate to IdentityGraph > Workloads and review the Enforcement IP Address column. A workload that shows -- has no Effective Enforcement IP and is not matched by policy; resolve the duplicate address as described in Enforcement IP Resolution.
Confirm that the Azure workloads are matched by the Policy Groups intended to govern them.
Change a tag or the power state on a virtual machine in Azure and confirm that the change is reflected in Cloud Control Center after the next sync cycle.

Troubleshooting

Issue	Resolution
Workloads navigation item does not appear	Verify that the Workloads feature is enabled under Settings > System > Advanced. The toggle must be in the on position.
Microsoft Azure is not offered in the Add Connector dialog	The Microsoft Azure connector is available only after the Workloads feature is enabled. Enable it under Settings > System > Advanced, then reopen the Add Connector dialog.
Connection test reports that the app was not found	The Client ID does not match an application registration in the specified tenant. Confirm the Application (client) ID and confirm that it belongs to the tenant identified by the Tenant ID.
Connection test reports an invalid secret	The client secret is incorrect or has expired. Generate a new client secret on the application registration in Azure, enter the new secret value, update the Secret Expiry Date, and test again.
Connection test reports that the tenant was not found	The Tenant ID is incorrect. Enter the Directory (tenant) ID of the Entra ID tenant that contains the application registration.
Connection test reports valid credentials but no subscription access	The service principal authenticated, but it holds no role on any subscription in the tenant. Assign the Reader role to the service principal on each subscription to be discovered, then test again.
Connection test reports that Azure could not be reached	Cloud Control Center could not complete the request to Azure. Confirm that no outbound restriction is blocking access to the Microsoft Entra ID and Azure Resource Manager endpoints, then test again.
Add is unavailable on the connector form	The connector can be added only after a successful connection test. Complete every required field, click Test, and add the connector once the test succeeds.
The Workload Distribution Zone list is empty	Only Distribution Zones of type Workload are listed. Create one under Edge Management > Distribution Zones, then reopen the list.
No workloads appear after the connector is added	Allow one sync cycle to complete. Confirm that virtual machines exist in a subscription where the service principal holds the Reader role, and confirm the connector status is Active.
Virtual machines in one subscription are missing	Discovery covers only the subscriptions where the service principal holds a role. Assign the Reader role on the missing subscription, then run a sync from the connector row actions menu.
The connector moved to Inactive	The client secret has expired. Generate a new secret in Azure, edit the connector to enter the new secret value and Secret Expiry Date, and test the connection.
A deallocated virtual machine displays as Stopped	This is expected. Azure stopped and deallocated power states both display as Stopped, and the Azure power state is preserved on the workload record.
A workload is not matched by policy	The interface has no Effective Enforcement IP because its Enforcement IP conflicts with a network device or with another workload interface. Devices take priority over workloads, and two conflicting workload interfaces both lose their Effective Enforcement IP. Correct the duplicate address, then recheck the Network Interfaces tab.
A Distribution Zone cannot be deleted	A Distribution Zone referenced by a discovery endpoint cannot be deleted. Reassign every endpoint that references it, then delete the Distribution Zone.