What's New in 26.40
Here's a summary of the new and enhanced features in this release.
Explorer Remembers Your Last Results
The Explorer page now automatically loads your most recent results.
Instead of starting with a blank page, Explorer checks for your latest saved query and displays the most recent results when available, helping you get back to work faster.
Policy Provisioning Status
View whether Illumio policy rules were successfully applied to cloud security controls after provisioning. Receive clear feedback indicating whether the rules applied. This feedback helps you detect implementation failures, identify potential security gaps, and reduce troubleshooting time.
Changed APIs in 26.40.0 (Schemas)
Here's a summary of the new and enhanced features in this release.
Changed Common Schemas
In this release, three common schemas have been changed:
common-container_policy_convergence_errors
This schema transitions the data model from a singular error-reporting structure to a bulk/batch processing model.
}, "pod_names": { "description": "Names of the k8s Pods", "type": "array", "items": { "type": "string" } }, "workloads": { "description": "Host Workloads that represent the k8s Nodes where the Pods are running", "type": "array", "items": { "type": "object", "additionalProperties": false, "required": [ "href", "name" ], "properties": { "href": { "type": "string" }, "name": { "description": "Workload name", "type": "string" } }Instead of processing single string and object fields (pod_name and workload), the schema now uses arrays (pod_names and workloads). This allows the system to group and handle multiple affected Kubernetes Pods and Nodes simultaneously in a single event payload.
For newly added workloads, the schema increases data visibility by making the human-readable name a required field alongside the API href.
common-pairing_profile_ven_type
This schema update modifies the allowed enum values for the pairing profile VEN type (common-pairing_profile_ven_type) by adding support for Data Processing Units (DPUs) to the allowed enumeration list.
[ "+", "dpu" ]common-ven_type
While common-pairing_profile_ven_type added "dpu" specifically to the pairing profiles configuration, this change updates the underlying VEN type classification.
[ "+", "dpu" ]
Changed Schemas
Several schemas have been changed to add properties:
network_device_config
This schema update introduces a new property, configure, to the network device configuration schema, adding a native mechanism for toggling configuration permissions.
{
"properties": {
"configure": {
"description": "Boolean flag to indicate if the device can be configured",
"type": "boolean"
}
}
}This addition introduces granular control over device management. It allows for flagging certain network devices as "read-only" or unconfigurable by toggling this boolean.
optional_features_put
This update modifies the schema definition used to update optional system features (optional_features_put). It introduces four new feature flags to the allowed options configuration under the name enum property, while leaving all existing options unchanged.
{
"items": {
"oneOf": [
[
"~",
{
"properties": {
"name": {
"enum": [
---------------------------------
[
"+",
"linux_outbound_process_enforcement"
],
----------------------------------
[
"+",
"mtwl"
],
----------------------------------
[
"+",
"pce_nla"
],
[
"+",
"policy_generator"
-----------------------------------linux_outbound_process_enforcement: Extends outbound process-level firewall enforcement to Linux environments (complementing the existing windows_outbound_process_enforcement).
mtwl: Introduces a new feature toggle
pce_nla: Adds support for PCE Network Location Awareness configurations.
policy_generator: Introduces a toggle for automated security policy generation utility features.
By expanding this enum, the PUT request can now accept, configure, and toggle these four new distinct functionalities.
It allows infrastructure operators to selectively enable advanced platform capabilities, such as Linux process firewalls, automated policy generators, or location-awareness features, during a system settings update.
traffic_flows_workload
This change introduces a hierarchical, multi-tiered labeling architecture for workloads in traffic flow logs.
{
"properties": {
"sub_labels": {
"description": "List of sub-label sets associated with the workload",
"type": "array",
"items": {
"$ref": "traffic_flows_endpoint_labels.schema.json"
}
}
}
}By supporting arrays of traffic_flows_endpoint_labels, the system can now track and filter traffic using more granular sub-labels.
users_login_get
This schema update enhances the user login retrieval data model by adding an explicit property, a new field named domain_name, for tracking corporate or network domain boundaries during a GET request.
{
"properties": {
"domain_name": {
"type": "string",
"description": "User's domain name (e.g. illumio.com)"
}
}
}This field captures the specific corporate or organizational domain name associated with the logging-in user account.
Changed for APIs in 26.40 (Sub Labels)
These are the changes related to the property sub_labels.
Property sub_labels
The addition of sub_labels introduces multi-dimensional, nested metadata sets into workloads.
Instead of a flat list of tags, workloads can now support groups of nested label collections.
vens_get
This schema update aligns the VEN retrieval API with multi-dimensional metadata tracking by introducing a sub_labels property for workloads associated with a VEN.
{
"properties": {
"workloads": {
"items": {
"properties": {
"sub_labels": {
"description": "List of sub-label sets associated with this workload",
"type": [
"array",
"null"
],
"items": {
"description": "A sub-label set associated with this workload",
"type": "array",
"items": {
"type": "object",
"required": [
"href",
"key",
"value"
],
"properties": {
"href": {
"description": "The URI of the label.",
"type": "string"
},
"key": {
"description": "Key of the label",
"type": "string"
},
"value": {
"description": "Value of the label",
"type": "string"
}
}
}
}
}
}
}
}
}
}Nullable Array of Arrays Structure: The sub_labels property is typed as ["array", "null"], making it optional or nullable.
Inline Key-Value Pair Definition: Each item within the nested array is an object representing an individual label instance. The schema enforces a strict object structure requiring three fields:
href: The unique URI/API path of the label (string).
key: The dimension or category of the label (string).
value: The specific assignment name of the label (string).
workloads_get
This update refines the workload retrieval data model (workloads_get) by standardizing label metadata and officially supporting nested sub-labels.
It introduces a new sub-labels array and fixes a documentation bug in the existing core labels object.
{
"properties": {
"sub_labels": {
"description": "List of sub-label sets associated with this workload",
"type": "array",
"items": {
"description": "A sub-label set associated with this workload",
"type": "array",
"items": {
"type": "object",
"required": [
"href",
"key",
"value"
],
"properties": {
"href": {
"description": "The URI of the label.",
"type": "string"
},
"key": {
"description": "Key of the label",
"type": "string"
},
"value": {
"description": "Value of the label",
"type": "string"
}
}
}
}
},
"labels": {
"items": {
"properties": {
"href": {
"description": {
"__old": "The URI of the VEN that manages this workload. This replaces the 'agent' field of this object.",
"__new": "The URI of the label."
}
}
}
}
}
}
}The schema fixes an incorrect legacy description.
The href inside the core labels block was erroneously documented as pointing to a VEN/Agent management URI, but it actually references the label's own URI. Correcting the documentation block prevents confusion for developers when integrating with the core labels object array.
workloads_post
This update introduces support for nested metadata during workload creation (workloads_post) by adding a new property, sub_labels, to the request payload configuration.
{
"properties": {
"sub_labels": {
"description": "List of sub-label sets associated with the workload",
"type": "array",
"items": {
"$ref": "labels.schema.json"
}
}
}
}Addition of a Sub-Label Array: The schema introduces a new property named sub_labels
Structural Reference ($ref): The creation payload defines this field as an "array" whose items reference an existing core schema file: labels.schema.json.
This allows API clients to assign a structured collection or list of nested sub-label sets directly when a new workload is provisioned.
workloads_with_ven_interface_put
This update introduces support for updating nested metadata on workloads paired with VEN network interfaces (workloads_with_ven_interfaces_put) by adding the sub_labels property to the update payload.
{
"properties": {
"sub_labels": {
"description": "List of sub-label sets associated with the workload",
"type": "array",
"items": {
"$ref": "labels.schema.json"
}
}
}
}workloads_with_ven_put
This update introduces support for modifying nested metadata on standard VEN-managed workloads (workloads_with_ven_put) by adding the sub_labels property to the update payload.
Consistent with the other write/update endpoints (workloads_post and workloads_with_ven_interfaces_put), this array leverages a reference to the core external schema file: labels.schema.json.
{
"properties": {
"sub_labels": {
"description": "List of sub-label sets associated with the workload",
"type": "array",
"items": {
"$ref": "labels.schema.json"
}
}
}
}workloads_without_ven_put
This update introduces support for modifying nested metadata on unmanaged or agentless workloads (workloads_without_ven_put) by adding the sub_labels property to the update payload.
This allows API clients to update, append to, or overwrite a structured collection of sub-label sets on workloads without a Virtual Enforcement Node installed (e.g., third-party appliances, legacy systems, or static network targets).
{
"properties": {
"sub_labels": {
"description": "List of sub-label sets associated with the workload",
"type": "array",
"items": {
"$ref": "labels.schema.json"
}
}
}
}