Workloads

A workload is a cloud virtual machine that Elisity Cloud Control Center (CCC) discovers through a cloud connector: an Amazon EC2 instance or a Microsoft Azure virtual machine. Workloads are an asset type in IdentityGraph™, listed under IdentityGraph > Workloads beside devices and users. They are classified into Workload Policy Groups and governed by the Policy Matrix in the same way as devices.

A workload differs from a device in how it is identified and how policy reaches it. A device is discovered on a switch and identified by its MAC address. A workload is read from the cloud provider's API and identified by its instance ID, and it can have several network interfaces, each with its own addresses, tags and Enforcement IP. Policy between campus devices and workloads is enforced by campus Virtual Edge Nodes, matched on each workload interface's Enforcement IP.

This article covers enabling workloads, the Workloads page and workload details, editing and classifying workloads, writing policy for them, and how the Enforcement IP is set, resolved and distributed. Connecting a cloud account is covered in the connector articles listed below.

How Workloads Are Discovered

Workloads are discovered by IdentityGraph connectors. Each connector reads the cloud account it is configured for and keeps the inventory in step with the provider: new instances are added, attribute and tag changes are applied, and an instance that is no longer found is removed together with its interfaces and any settings made in CCC.

Cloud Provider Discovered as a Workload Configuration
Amazon Web Services EC2 instances in the AWS account and regions the connector covers Connect AWS for Workload Discovery and Enforcement
Microsoft Azure Virtual machines in the subscriptions and resource groups the connector can read Connect Azure for Workload Discovery and Enforcement

Each connector is assigned a Workload Distribution Zone, which every workload it discovers inherits. The zone carries the workloads' Enforcement IPs to the enforcement points that need them. See Distribute Enforcement IPs.

Enable Workloads

Workloads must be enabled before the cloud connectors and the Workloads page are available.

Step 1. Navigate to Settings > System > Advanced.

Step 2. On the Workloads tile, turn on Enable Workloads.

Workloads then appears in the IdentityGraph menu between Devices and Users, the Amazon Web Services and Microsoft Azure connectors become available under IdentityGraph > Connectors, and Workloads can be selected as a Policy Group type and as a side of the Policy Matrix.

The Workloads Page

Navigate to IdentityGraph > Workloads. The page lists the workloads discovered by every connector in the tenant.

Workload Summary

The summary at the top reports Total Workloads, a count By State, and the distribution By Region, By Virtual Network (an AWS VPC or an Azure virtual network) and By Instance Type. Select a slice of a chart to filter the table to the workloads it represents.

Workload Table

Each row is a workload. The table shows the following columns by default. Use the column control in the table toolbar to show or hide further columns, such as Instance Type, Region, Platform, Virtual Network, Virtual Network Name, Subnet, Subnet Name, MAC Address, Tags and Last Update.

Column Description
Hostname/Instance ID The workload's name, or its instance ID when the provider reports no name. Select it to open the workload's details.
Provider The cloud provider the workload was discovered from.
Account The AWS account alias or Azure subscription name, or the connector's endpoint name when no alias is available.
Endpoint Name The connector endpoint that discovered the workload.
Status The power state reported by the provider, for example Running or Stopped. Azure reports both stopped and deallocated virtual machines as Stopped.
IP Addresses The workload's primary address. +N indicates additional addresses; select it to list them all.
Enforcement IP Address The addresses policy is enforced on. -- means no interface has a usable Enforcement IP, because none is set or because a duplicate address conflict removed it. See Enforcement IP.
Account ID and Account Name The AWS account ID and alias, or the Azure subscription ID and name.

Use Search and the filter control to narrow the table, for example by provider, region, virtual network, status or Enforcement IP address. When any workload is in a duplicate address conflict, a Duplicate IP Conflict alert appears above the table. Select View Details to list the affected workloads and interfaces. See Duplicate Addresses.

Workload Details

Select a workload's Hostname/Instance ID to open Workload Details. The Workload Information card at the top shows the cloud provider, the primary IP address, the workload's Distribution Zone, and its state.

IdentityGraph Tab

  • Instance Details: the attributes read from the provider, including Instance ID, Endpoint Name, Account ID and Name, MAC Address, Status, Region, virtual network and subnet IDs and names, Availability Zone, Hostname, Instance Type, Sync Status and Last Update. These values are refreshed from the provider and cannot be edited.
  • Labels and Tags: CSP Tags are the tags applied to the instance in AWS or Azure. They are read-only in CCC and are available as Policy Group match criteria. Manually Configured Labels are labels applied in CCC.
  • Manually Configured: the hostname, risk level and risk score set in CCC.

Network Interfaces Tab

The Network Interfaces tab lists each network interface on the workload. The header of each interface shows its Enforcement IP and how the address was set: Auto-discovered or Locked Override. Expand an interface to see:

  • Network Context: the MAC address, virtual network, subnet and subnet CIDR, and for AWS, the source/destination check and route table.
  • Policy Details: the Workload Policy Group and Policy Set that apply to this interface. Classification is per interface, so interfaces on one workload can belong to different Policy Groups.
  • Security Groups: the AWS security groups on the interface. For Azure, the network security group applied to the network interface is shown; network security groups applied at the subnet are not.
  • CSP Interface Tags: the tags on the network interface in AWS or Azure, read-only. The elisity tag that sets the Enforcement IP appears here.
  • Elisity Interface Tags: key and value tags applied to the interface in CCC, available as Policy Group match criteria. Select Edit to add or change them.
  • IP Addresses: every address on the interface, with its type, DNS name and associated public IP. The provider's primary address is marked Primary.

Edit Workloads

Attributes and tags read from the provider cannot be edited in CCC. The fields maintained in CCC can be edited for one workload or for several at once.

To edit one workload, open its details and select Edit. You can set the Hostname, Label, Risk Level, Risk Score (0 to 100) and Description (up to 255 characters).

To edit several workloads, select them in the Workloads table, then select Bulk Actions > Edit Workloads. You can set the Label, Risk Level, Risk Score and Description for every selected workload. Only the fields you change are written, and a label set you apply replaces the labels already on the selected workloads.

Hostname is edited one workload at a time. Elisity interface tags and the Enforcement IP are edited per interface on the Network Interfaces tab. Workloads cannot be deleted in CCC; a workload is removed when its connector no longer finds it.

Classify Workloads

Workloads are classified into Workload Policy Groups under Policy > Policy Groups > Workload Policy Groups. Match criteria can use the workload attributes and CSP tags read from the provider, the interface attributes and CSP interface tags, Manually Configured Labels, and Elisity interface tags.

Workload Policy Groups are evaluated in order, and each interface joins one group. An interface that matches no group is listed under Unassigned Workload. Because membership follows attributes and tags, an instance that is retagged in AWS or Azure moves to the matching Policy Group on the next synchronization, and the policy that applies to it moves with it. An interface that is locked to its Policy Group stays in that group. For creating groups, match criteria and ordering, see Policy Groups. Workload Policy Groups can be nested; see Nested Policy Groups.

Write Policy for Workloads

Policy between campus devices and workloads is written in the Policy Matrix. In Policy > Matrix, set Side A to Devices and Side B to Workloads. Each cell is the intersection of a device Policy Group and a Workload Policy Group, and it holds the Security Profile and the final policy action for traffic between them. See Policy Matrix.

The policy is enforced by campus Virtual Edge Nodes that hold the workload's mappings, matched on the workload interface's Enforcement IP. See Distribute Enforcement IPs. No rules are written in AWS or Azure.

Enforcement IP

The Enforcement IP is the address, or addresses, that policy is enforced on for a workload interface. It identifies which traffic belongs to the workload; what that traffic is allowed to do is decided by the interface's Workload Policy Group. An interface without an Enforcement IP is not enforced. CCC never selects an address on its own: the address comes from a tag you place on the interface in the cloud provider, or from an override you set in CCC.

The Enforcement IP can differ from the interface's own addresses. For example, a workload reached through network address translation is enforced on the translated address that campus traffic uses.

Set the Enforcement IP with an Interface Tag

Add a tag with the key elisity to the network interface in the cloud provider. The value is the address to enforce on, or several addresses separated by commas. The tag goes on the network interface, not on the instance or virtual machine.

  • AWS: add the tag to the elastic network interface (ENI) attached to the EC2 instance.
  • Azure: add the tag to the network interface resource attached to the virtual machine.

The connector reads the tag on its next synchronization. The address appears as the interface's Enforcement IP marked Auto-discovered, and the tag is listed under CSP Interface Tags. If the tag value changes, the Enforcement IP follows it. A tag that is missing, empty, or contains no valid address leaves the interface without an Enforcement IP. The elisity key is reserved for this purpose and cannot be used for an Elisity interface tag in CCC.

Set the Enforcement IP with a Locked Override

Use a Locked Override when you cannot tag the interface in the cloud provider, or to pin an address regardless of the tag.

Step 1. Open the workload's details and select the Network Interfaces tab.

Step 2. Select Edit beside the interface's Enforcement IP. The Edit IP Discovery panel opens.

Step 3. Select Locked Override, select an address from the list or enter one, and select Save Changes.

A Locked Override replaces the tag value and persists across synchronizations, even if the interface's addresses change. To follow the elisity tag again, open Edit IP Discovery and select Auto-discovered. Otherwise, a Locked Override stays in place until you change it or the workload is removed.

Duplicate Addresses

Before policy uses an Enforcement IP, IdentityGraph checks it against every device and every other workload interface in the tenant. Three rules decide which asset keeps an address:

  • A device always takes precedence over a workload, in any Distribution Zone. A workload interface is not enforced on an address that a device holds.
  • Between two workload interfaces, the one that already holds the address keeps it. The other interface is not enforced on that address until the holder releases it, for example when it is re-addressed or removed.
  • A device discovered later takes the address from the workload. The workload interface is detached from the address and is no longer enforced on it.

An interface that loses an address shows a Duplicate IP Conflict banner naming the device or workload that holds the address, with a link to its details. Decide which of the two should use the address and correct the tag, the override or the addressing. A device and a workload cannot share an address.

Distribute Enforcement IPs

Policy for workload traffic is enforced on campus Virtual Edge Nodes, so each Enforcement IP must reach the Virtual Edge Nodes that enforce policy for the campus devices. CCC publishes each Enforcement IP as a host (/32) mapping, tagged with the interface's Workload Policy Group, into the Workload Distribution Zone of the connector that discovered it. A workload interface with several Enforcement IPs is enforced on all of them.

Virtual Edges and Virtual Edge Nodes cannot be assigned to a Workload Distribution Zone. Its mappings reach enforcement points in either or both of two ways:

  • Core Distribution Zone import: add the Workload Distribution Zone to a Core Distribution Zone's imported zones. The core-layer Virtual Edge Nodes receive the workload mappings and enforce policy on the traffic that passes through them.
  • Intelligent Tag Distribution: an Access or Core Distribution Zone with Intelligent Tag Distribution enabled receives the mappings for the workloads its devices communicate with. Enable Suppress Tag Distribution on the Workload Distribution Zone to exclude its mappings from this path; a Core import is not affected.

For Workload Distribution Zone settings and limits, see Distribution Zones.

Troubleshooting

When policy between a campus device and a workload is not enforced, check the following in order.

  • The interface has an Enforcement IP. On the Network Interfaces tab, confirm the interface shows an address. If it shows --, confirm the elisity tag is on the network interface (not the instance) and that its value is a valid address, or set a Locked Override.
  • No other asset holds the address. Look for a Duplicate IP Conflict banner on the interface or above the Workloads table.
  • The interface is in the expected Policy Group. Check Policy Details on the interface. An interface in Unassigned Workload matches no Workload Policy Group.
  • The mappings reach an enforcement point. Confirm the connector's Workload Distribution Zone is imported into a Core Distribution Zone, or reaches the device's Distribution Zone through Intelligent Tag Distribution, and that Suppress Tag Distribution is not excluding it.
  • A matrix cell covers the traffic. In the Policy Matrix, check the cell between the device's Policy Group and the workload's Policy Group.

Limitations

  • Policy for workloads applies to traffic between campus devices and workloads and is enforced by campus Virtual Edge Nodes. CCC does not write rules in AWS or Azure.
  • Access Policy cannot be created for Workload Policy Groups.
  • Only IPv4 Enforcement IPs are enforced.
  • A workload that its connector no longer finds is removed with all of its interfaces, labels, Elisity interface tags and Locked Overrides.
  • Workloads cannot be added or deleted manually.
Was this article helpful?
0 out of 0 found this helpful