Policy and Workload Enhancements

This topic lists the features and enhancements for the PCE web console in Illumio Core 20.2.0. It only provides a high-level summary. For more information, see the guides in this documentation portal.

Selective Enforcement

Selective enforcement represents an important improvement to enable you to protect only a subset of applications or processes on a workload. While the selected applications or processes are protected, the other services or ports behave as if the whole workload is "in visibility" (formerly known as the "build" mode). When using selective enforcement, you can also temporarily enforce specific ports in cases when a vulnerability is detected and swift action is needed.

Selective enforcement, therefore, helps overcome the limitations of the allow-list security model that requires a complete list of what's allowed in order to enforce any security. It enables security enforcement before the customer can build a complete allow-list.

The important use cases for selective enforcement are:

Emergency risk reduction: If you detect a vulnerability that you cannot easily patch, use selective enforcement, and quickly lock the affected ports without changing the behavior of other ports or applications.
Selective enforcement of a broader set of ports: Start by enforcing only the most critical ports (such as port 22) and gradually add more ports until you reach full enforcement.

Policy Management with Selective Enforcement

Selective enforcement brings the following changes to the policy management:

Users have an option to set the enforcement policy on a per-workload basis
The enforcement state and visibility/logging state are separated
Users can create, edit, and delete selective enforcement policies
The VEN shall enforce policies accordingly
RBAC considerations: various RBAC roles (such as Workload Manager, Ruleset Manager, Ruleset Viewer, Ruleset Provisioner, Global Read-Only user, or Global Object Provisioner) have their specific privileges regarding selective enforcement policies, while only the Global Org Owner or Global Admin can manage enforcement policy with no restrictions.
The enforcement policies follow the allow-list model. The enforcement policies are additive and, therefore, will never contradict themselves.

Selective Enforcement Limitations

The following limitations that exist when using this feature:

Virtual services are enforced at the workload level, which means that selective enforcement does not affect them directly; selective enforcement affects the workloads from which the services are comprised.
Selective enforcement applies only to managed workloads; it does not apply to NEN-controlled or other unmanaged workloads.
Selective enforcement applies only to inbound connections.
The enforcement policies control which ports or services are enforced on workloads. They do not affect and are completely independent of access rules, Secure Connect, Machine Authentication, whether they are stateless, and so on.

Selective Enforcement in the PCE Web Console

With the new Selective Enforcement state available in the UI, the previous Enforced state is now mapped to Full, and Idle is retained as is.

From the main menu, you can reach the new Selective Enforcement Rules page.

The Selective Enforcement Rules page contains a list of previously created Selective Enforcement rules, which are provisionable objects.

Workload Clone Alerts

Summary:

Workloads can now be filtered according to whether a clone has been detected.

Details:

Workloads can now be filtered according to whether a clone has been detected. In the API, this is done using the clone_detected state. In the UI, customers can filter the Workloads list by clone detected. If the are any workloads that are in the clone detected state, a red banner (similar to workloads in suspension) is displayed at the top of the workload list page.

The VEN communicates with the PCE using HTTPS over Transport Layer Security (TLS). Additionally, a clone token is generated. When an agent token is mistakenly or maliciously reused on another workload , the clone token is used to detect the condition and disambiguate the hosts. The clone token is periodically rotated. The agent token is never rotated.

To try this feature:

Pair one or more VENs and then clone the VEN(s). Wait for 30 minutes.
In the PCE web console, display the Workloads List page.
Look for an alert banner indicating some workloads are in "clone detected" state.
Click the filter link on the banner. The list now shows only the "clone detected" workloads.
Click on one of the "clone detected" workloads. An alert is displayed on the detail page for that workload.
If you stop, unpair, or repair the cloned VEN, you can come back and see that the messages and alerts are removed from the Workloads List page.

Show Amount of Data Transfer (Preview)

The operation of 'show amount of data transfer' capability on the PCE is a preview feature available with the 20.2.0 release. The PCE now reports amount of data transferred in to and out of workloads and applications in a datacenter. The number of bytes sent by and received by the provider of an application are provided separately. These values can be seen in traffic flow summaries streamed out of the PCE. This capability can be enabled on a per-workload basis in the Workload page. It can also be enabled in the pairing profile so that workloads are directly paired into this mode.

After the feature is enabled, the VEN starts reporting the number of bytes transferred over the connections. The PCE collects this data, adds relevant information, such as, labels and sends the traffic flow summaries out of the PCE.

The direction reported in flow summary is from the viewpoint of the provider of the flow.

Destination Total Bytes Out (dst_tbo): Number of bytes transferred out of provider (Connection Responder)
Destination Total Bytes In (dst_tbi): Number of bytes transferred in to provider (Connection Responder)

The number of bytes includes:

L3 and L4 header sizes of each packet (IP Header and TCP Header)
Sizes of multiple headers that may be included in communication (when SecureConnect is enabled)
Retransmitted packets.

The bytes transferred in the packets of a connection are included in measurement. This is similar to various networking products such as firewalls, span-port measurement tools, and other network traffic measurement tools that measure network traffic.

Term	Description
dst_tbi	Destination Total Bytes In Total bytes received till now by the destination over the flows included in this flow-summary in the latest sampled interval. This is the same as bytes sent by the source. Present in 'A', 'C', and 'T' flow-summaries. source = client = connection initiator, destination = server = connection responder.
dst_tbo	Destination Total Bytes Out Total bytes sent till now by the destination over the flows included in this flow-summary in the latest sampled interval. This is the same as bytes received by the source. Present in 'A', 'C', and 'T' flow-summaries. source = client = connection initiator, destination = server = connection responder.
dst_dbi	Destination Delta Bytes In Number of bytes received by the destination in the latest sampled interval, over the flows included in this flow-summary. This is the same as bytes sent by the source. Present in 'A', 'C', and 'T' flow-summaries. source = client = connection initiator, destination = server = connection responder.
dst_dbo	Destination Delta Bytes Out Number of bytes sent by the destination in the latest sampled interval, over the flows included in this flow-summary. This is the same as bytes received by the source. Present in 'A', 'C', and 'T' flow-summaries. source = client = connection initiator, destination = server = connection responder.
interval_sec T	Time Interval in Seconds Duration of latest sampled interval over which the above metrics are valid.

Connection State	Description
A	Active: The connection is still active at the time the record was posted. Typically observed with long-lived flows on source and destination side of communication.
T	Timed Out: Flow does not exist any more. It has timed out. Typically observed on destination side of communication.
C	Closed: Flow does not exist any more. It has been closed. Typically observed on source side of communication.
S	Snapshot: Connection was active at the time VEN sampled the flow. Typically observed when the VEN is in Idle state.

Container Support Enhancements

Containers Available in Supercluster Member Regions

In previous releases, container clusters could only be paired with the leader PCE region in a Supercluster. In 20.2.0, you can now pair workloads part of a container cluster on Supercluster member regions. Container clusters can now be managed in a member region as well as all the resources attached to this container cluster: container workloads (pods), virtual services (services), and workloads (nodes).

Support for IKS VPC Cluster

This release supports running Illumio Core for Containers (C-VEN 20.2.0 and Kubelink 2.0) in IBM Cloud Kubernetes Service (IKS) VPC cluster. This has been tested and qualified in a VPC Gen 1 and Gen 2 environments.

Kubernetes Container Runtime Detection with Kubelink

Prior to the 20.2.0 release, Illumio supported Docker, Containerd, and Cri-o container runtimes and the detection was done with a static priority list. To force Illumio's solution to listen to events on the right container runtime, Illumio had to statically configure the socket path for the given container runtime, for example for Containerd. From the 20.2.0 release onwards, the container runtime used in Kubernetes clusters will be automatically detected and reported to the PCE without modification of the socket path in the C-VEN yaml file. The new container runtime will be displayed in the container cluster summary page.