Skip to main content

REST APIs for 24.2.20 and 24.2.10

VEN Operations

Overview of VEN Suspension

The VEN Update API (PUT [api-version][ven-href]) allows you to mark a VEN as either suspended or unsuspended in the PCE. It does not, however, actually suspend or unsuspend the VEN.

To suspend a VEN, use the illumio-ven-ctl command-line tool, which isolates a VEN on a workload so that you can troubleshoot issues and determine if the VEN is the cause of any anomalous behavior.

When you suspend a VEN, the VEN informs the PCE that it is in suspended mode.

However, if the PCE does not receive this notification, you must mark the VEN as "Suspended" in the PCE web console (select the VEN and click Edit ), or you can use this API to mark the VEN as suspended.

When you don't mark the VEN as suspended in the PCE, the PCE assumes that the workload is offline and removes it from the policy after one hour. When you mark the VEN as suspended, that VEN’s workload is still included in the policy of other workloads.

When a VEN is suspended:

  • The VEN still appears in the PCE on the VEN list page.

  • The VEN's host cannot be unpaired.

  • An organization event (server_suspended) is logged. This event is exportable to CEF/LEEF and has the severity of WARNING.

  • Heartbeats or other communications are not expected, but when received, all communications are logged by the PCE.

  • If the PCE is rebooted, the VEN remains suspended.

  • Any custom iptables rules are removed, and you need to reconfigure them manually.

When a VEN is unsuspended:

  • The PCE is informed that the VEN is no longer suspended and can receive policy from the PCE. If existing rules affect the unsuspended workload, the PCE reprograms those rules.

  • An organization event (server_unsuspended) is logged. This event is exportable to CEF/LEEF and has the severity of WARNING.

  • The workload reverts to the policy state it had before it was suspended.

  • Custom iptables rules are configured back into the iptables.

VEN upgrade APIs allow you to specify an array of VEN HREFs to upgrade to a specific version instead of a list of agent ID's.

Rules when validating with the VEN upgrade APIs are as follows:

  • No downgrades are allowed.

  • Users cannot upgrade to a VEN version higher than the PCE version.

  • No AIX, Solaris, or C-VEN are allowed.

  • Users can only upgrade VENs paired to the same region.

  • Only workload managers can upgrade VENs, and they can only upgrade VENs within their scope.

VEN API Methods

In addition to the page in the PCE web console that lists all VENs and shows the details of a single VEN, there is a Public Experimental API for getting VEN collections and VEN instances. Other new APIs support VEN filtering in the PCE web console and update and unpair VENs.

VEN Methods

HTTP

URI

Get the collection of all VENs (The href property in each interface in the ven interfaces array is dropped from the response.)

GET

[api_version][org_href]/vens/

Get details on a VEN instance (The href property in each interface in the ven interfaces array is dropped from the response)

GET

[api_version][org_href]/vens/ven_id

Use to get the default release without iterating through the whole collection.

GET

[api_version[org_href] /software/vens/default

Support VEN filtering in the PCE web console.

GET

[api_version][org_href]/ vens/autocomplete

[api_version][org_href]/vens/facets

To set the target_pce_fqdn on a VEN

PUT

[api_version][org_href]/vens/ven_id

Update a VEN

PUT

[api_version][org_href]/vens/update

Upgrade a VEN. This API accepts a list of hrefs instead of agent_ids. The upgrade endpoint falls under /vens/resource instead of the /software/resource.

PUT

[api_version][org_href]vens/upgrade

Lists the VEN releases available to the org, one per VEN version, along with metadata such as whether it is the default version, whether that release supports servers and/or endpoints, and so on. The list of images is longer than the list of releases; multiple images belong to the same release version.

GET

[api_version]/software/ven/releases

Shows the complete list of VEN images. There is one image for each Linux distribution we support (such as RHEL and Ubuntu), plus images for Windows and macOS.

GET

[api_version] /software/ ven/releases-images

Unpair a VEN: trigger the unpairing of one or more VENs.

NOTE: This endpoint replaces/workloads/unpair, which is deprecated.

PUT

[api_version][org_href]/vens/unpair

Provided so that users can set the default version for VEN pairing.

PUT

[api_version][org_href]/software/vens/default

Software VEN Releases

release_ven_types

{
	"$schema": "hp://json-schema.org/draft-04/schema#",
	"description": "Supported ven types in this release",
	"type": "array",
	"items": {
		"type": "string",
			"enum": ["server", "endpoint"]
		}
}

The new common schema release_ven_types is introduced to show ven_types for each release and to filter releases by ven_type.

Previously, the ven_type was not stored for the release, and database records looked as follows:

Release

Distribution

22.5.1

CentOS

22.5.1

MacOS

22.5.1

Windows

With the property ven_type added, the database records are expanded with an additional ven_types column:

Release

Distribution

ven_types

22.5.1

CentOS

server + endpoint

22.5.1

MacOS

server + endpoint

22.5.1

Windows

server + endpoint

Note that in release 22.5.1, the code supports the type "server+endpont". However, Centos (Linux) supports a server-only VEN image, MasOS supports an endpoint-only image, and Windows supports both server and endpoint:

Release

Distribution

ven_types

22.5.1

CentOS

server

22.5.1

MacOS

endpoint

22.5.1

Windows

server + endpoint

When a user opens the list of release images via UI and looks for the type server + endpoint, only the Windows image will appear as a complete match.

To fix this issue, the ven_type is now based on release and distribution:

  • All releases before 21.2.2 were just server (there was no endpoint)

  • Any release with 22.3.x was endpoint (there was no server)

  • Any other releases were server + endpoint , but instead of setting it to all the images (database records), the ven_types are set in a specific way for the Os.

GET VENs

To get a collection of VENs with a specific label applied, take a label string that was returned when you got a collection of VENs, and then add a query parameter to GET all VENs with that specific label.

Network Enforcement Nodes (NEN) APIs

Network Enforcement Node Reassignment

network_enforcement_nodes_put

This API is used to change an agent's target PCE FQDN.

It updates the target_pce_fqdn property so that a different PCE can manage the NEN in a Supercluster.

Change Target PCE

When you have the NEN HREF, you can update the target PCE with the PCE FQDN the NEN will use. In your JSON request body, pass the following data:

	"target_pce_fqdn": "new-pce-fqdn.example.com"
}

The URI for this operation is:

PUT [api_version][nen_href]/update

This curl example shows how you can pass the target_pce_fqdn property containing the FQDN of the new PCE:

curl -u api_xxxxxxx64fcee809:'xxxxxxx5048a6a85ce846a706e134ef1d4bf2ac1f253b84c1bf8df6b83c70d95' -H "Accept: application/json" -H "Content-Type:application/json" -X PUT -d '{"target_pce_fqdn":"new-pce-fqdn.example.com"}' https://my.pce.supercluster:443/api/v1/orgs/3/network_enforcement_nodes/f67d35d5-ea71-42da-b40d-8dcc3b1420c2/update
Authorization and Exposure Changes

Some of the existing experimental APIs have been changed in release 23.5.0 to facilitate the creation of fully scripted endpoint management system integrations with the PCE using the Network Enforcement Nodes (NEN) Switch integration capabilities.

Exposure Changes

Exposure of the listed NEN APIs was changed in release 23.5.0 from Public Experimental to Public Stable.

Authorization Changes

Authorization of some NEN APIs was changed in release 23.5.0 from the default ( "Global Administrator" and "Global Organization Owner") to authorize additional users as listed in the table.

API

Exposure Change

New Authorization Change

network_device_config

YES

NO

network_device_get

YES

NO

network_device_network_ endpoint_get

YES

NO

network_devices_enforcement_ instructions _ applied_post

YES

"Global Policy Object Provisioner" and " Ruleset Provisioner"

network_devices_enforcement_ instructions_request_post

YES

"Global Policy Object Provisioner" and " Ruleset Provisioner"

network_devices_get

YES

"Global Policy Object Provisioner", "Global Read Only", "Limited Ruleset Manager", "Ruleset Provisioner", "Ruleset Viewer", "Workload Manager"

network_devices_multi_enforcement_ instructions_applied_post

YES

"Global Policy Object Provisioner" and " Ruleset Provisioner"

network_devices_multi_enforcement_ instructions_request_post

YES

"Global Policy Object Provisioner" and " Ruleset Provisioner"

network_devices_network_ endpoints_get

YES

NO

network_devices_network_ endpoints_post

YES

"Workload Manager"

network_devices_network_endpoints_put

YES

"Workload Manager"

network_devices_put

YES

"Workload Manager"

network_endpoint_config

YES

NO

network_enforcement_node_get

YES

NO

network_enforcement_nodes_get

YES

"Full Ruleset Manager", "Global Policy Object Provisioner", "Global Read Only", "Limited Ruleset Manager", "Ruleset Provisioner", "Ruleset Viewer", "Workload Manager"

network_enforcement_nodes_ network_devices_post

YES

"Workload Manager"

network_enforcement_nodes_put

YES

NO