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
), 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 |
|
|
Get details on a VEN instance (The |
|
|
Use to get the default release without iterating through the whole collection. |
|
|
Support VEN filtering in the PCE web console. |
|
|
To set the |
|
|
Update a VEN |
|
|
Upgrade a VEN. This API accepts a list of |
|
|
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. |
|
|
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. |
|
|
Unpair a VEN: trigger the unpairing of one or more VENs. NOTE: This endpoint replaces |
|
|
Provided so that users can set the default version for VEN pairing. |
|
|
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), theven_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 |
---|---|---|
| YES | NO |
| YES | NO |
| YES | NO |
| YES | "Global Policy Object Provisioner" and " Ruleset Provisioner" |
| YES | "Global Policy Object Provisioner" and " Ruleset Provisioner" |
| YES | "Global Policy Object Provisioner", "Global Read Only", "Limited Ruleset Manager", "Ruleset Provisioner", "Ruleset Viewer", "Workload Manager" |
| YES | "Global Policy Object Provisioner" and " Ruleset Provisioner" |
| YES | "Global Policy Object Provisioner" and " Ruleset Provisioner" |
| YES | NO |
| YES | "Workload Manager" |
| YES | "Workload Manager" |
| YES | "Workload Manager" |
| YES | NO |
| YES | NO |
| YES | "Full Ruleset Manager", "Global Policy Object Provisioner", "Global Read Only", "Limited Ruleset Manager", "Ruleset Provisioner", "Ruleset Viewer", "Workload Manager" |
| YES | "Workload Manager" |
| YES | NO |