What's New and Changed in Release 21.2

Illumio Core 21.2.0, introduces the following new features and enhancements.

VEN Version Requirements

The following minimum VEN versions are applicable to the features and changes in this release.

Feature or Enhancement	Minimum VEN Version
Enforcement Boundaries	21.2.0
Asynchronous Queries (Explorer)	Any supported version
Label Groups for RBAC	Any supported version
Loopback Interface Support	Any supported version
FQDN Enhancements in Data Visualization	Any supported version
Uninterrupted Traffic between the VEN and the PCE	21.2.0
Linux Pairing Script Activation for Proxy Servers	21.2.0
PREVIEW: Network-Specific Policy	21.2.0
Global Explorer	Any supported version
Supercluster Replication Enhancements	Any supported version
LDAP Improvements	Any supported version
Enhanced Security for PCE TLS Configuration	Any supported version
Supercluster Rolling Upgrade	Any supported version
PREVIEW: Reports Preview in 21.2.0	Any supported version
PREVIEW: RHEL 8.3 Support for PCE	Any supported version

New Features in This Release

Containerized VEN in 21.2.0

In this release, the Containerize VEN supports deploying a local policy convergence controller.

The local policy convergence controller provides a deterministic way of setting the readiness state of pods in your cluster after local policy has converged. By controlling the readiness state of pods, you can prevent them from receiving and sending traffic through Kubernetes until they are ready. Using a controller ensures that the network and security infrastructure is ready for a multi-microservice application.

In this release, the Kubernetes Custom Pod Conditions feature introduced in v1.14 is available for containerized VENs.

For more information, see Local Policy Convergence Controller in the Illumio Core for Kubernetes and OpenShift Guide.

Enforcement Boundaries

In the Illumio Core 21.2.0 release, Illumio introduces Enforcement Boundaries, a new feature to speed your journey toward Zero Trust.

The Illumio security policy model is based on the principle of Zero Trust. Achieving Zero Trust security is possible with Illumio Core because it bases security policy on an allowlist model. From a security perspective, creating policy based on allowlists is the preferred method and has the advantage of specifying what you trust explicitly. However, you can encounter situations when you need more flexibility in segmenting your data centers. The solution is to introduce a new set of rules that determine where segmentation rules apply. These rules are referred to as Enforcement Boundaries in Illumio Core. Enforcement Boundaries can block traffic from communicating with workloads you specify, while still allowing you to progress toward a Zero Trust environment.

With the introduction of Enforcement Boundaries, the PCE web console and Illumio Core REST API changed to support the new feature.

For information about this new feature, see Policy Enforcement in the Security Policy Guide and Enforcement Boundaries in REST API Developer Guide.

Changes to Selective Enforcement

Illumio Core 20.2.0 introduced Selective Enforcement as a new feature. In Illumio Core 21.2.0, Selective Enforcement changed from being delivered as a type of Illumio Core rule to being strictly a workload enforcement state. In 21.2.0, Enforcement Boundaries appear as a type of rule in lieu of Selective Enforcement.

PCE web console menu in 20.2.0        

PCE web console menu in 21.2.0

In addition to the menu changes, other functional changes occurred. In Illumio Core 20.2.0, creating a Selective Enforcement rule allowed you to define only provider-centric enforcement by allowing traffic from a subset of applications or processes on a workload.

In Illumio Core 21.2.0, you can use Enforcement Boundaries to block traffic for both provider-centric and consumer-centric flows. An Enforcement Boundary can block traffic from communicating with workloads you specify, while still allowing you to progress toward a Zero Trust environment.

Global Explorer

This release provides support for asynchronous queries for every region in a Supercluster. If you initiate a query from the Supercluster leader, the results from all its members will be presented in Explorer. In the context of Supercluster, Explorer is referred to as Global Explorer.

For more information about this new feature, see Work with Explorer in the Visualization Guide.

Asynchronous Queries

Search queries can take time to display results depending on the size of the query. The current software allows you to initiate multiple queries when you need to, and then view the results of these queries at your convenience. This release overcomes a prior limitation with Explorer. Previously, going offline during a query resulted in lost query results. With this feature, results are preserved for 24 hours.

More importantly, after you start a query, you can work on something else in the product, while the query processing will continue until it finishes. Whether you remain online or offline, are temporarily away from your device, or come back within the day, your search results will still be available for 24 hours. The search results can either be exported to comma-separated-values (CSV) format files that capture information on traffic flows or be displayed in the Explorer PCE web console.

For more information about this new feature, see Work with Explorer in the Visualization Guide.

Enhancements for Explorer Results

Release 21.2.0 introduces the following capabilities:

• Queries can be initiated and processed asynchronously. If you initiate a time-consuming query, you can start and run another query (or navigate away from the query page to other parts of the product) while the first query results continue to be processed. Previously, you had to wait for the first query to finish before initiating another. Now, you have the ability to run multiple queries simultaneously.
• The Load Filter drop-down will display both Recent and Saved queries. Prior to release 21.2.0, there were two separate drop-down menus for each type of query. Existing filters continue to function as they did before this release.
• A previous limitation allowed only 100,000 results from the database to be returned. This value has increased; for information, see General Advisories.

Label Groups for Role-based Access Control

You can now use label groups to grant RBAC privileges. The user who has the correct RBAC privileges (having label groups in the user's scope) can create and modify rulesets and rules that are within the scope defined in the label group. The result is simpler, cleaner, and more understandable policies, and better ease of defining the permissions for scoped user roles. See Add a Scoped Role.

Loopback Interface Support

The PCE web console and the REST API include support for the loopback interface in this release. In the PCE web console, go to Settings > Security >

Workloads that match the scope will apply policy on loopback interfaces and the loopback interface's IP address will be distributed to peers.

What's Changed in this Release

Supercluster Replication Enhancements

The commands to restore a Supercluster have changed. For the new step by step instructions, see Restore a PCE or Entire Supercluster.

• In the supercluster-restore command, the options --supercluster-data-replication-timeout and --supercluster-config-replication-timeout are removed and no longer needed.
• In the supercluster-data-dump command, the --restore-type option is no longer needed.
• A restoring PCE restores data from all live PCEs on the fly, as part of supercluster-restore. Previously, the data was restored from a file.
• Some parameter names have changed in the supercluster-data-restore command.
• A new --retry-count option has been added to all Supercluster commands. This controls how many times the command will attempt to run if an error occurs. The default is 5, and typically there is no reason to change this value.

The time required to run certain commands has changed:

• supercluster-join is faster, especially for customers with many regions.
• supercluster-drop is slower, because the command was made more robust. Many checks and retries were added to the command, so it fails less often.
• supercluster-data-restore is faster when restoring a single PCE, because data is no longer restored from a file.
• supercluster-restore might be slower when restoring a single PCE, because it restores data from all live PCEs on the fly, instead of from a file. The time required for this command depends on network latency and packet loss. Since both supercluster-data-restore and supercluster-restore commands are needed to perform a single PCE restore, the total time should be similar to the Supercluster replication process in earlier PCE versions.

LDAP Improvements

Earlier versions of the PCE had a restriction that required all LDAP users to be in the same branch of an LDAP tree structure. The new implementation does not require that all LDAP users be in the same branch of the directory.

As a result, the configuration of anonymous bind in the LDAP Server Create Screen has changed. The Bind DN field is now optional, not required as in previous versions. When configuring an LDAP server, choose Allow if you want to use anonymous bind; in this case, Bind DN is not needed. On the other hand, when using Active Directory, the use of Anonymous Bind is not recommended. Choose Do not Allow and specify values for Bind DN and Bind Password. In both cases, the User DN Pattern is no longer used. See Configure LDAP Authentication.

PCE behavior has also changed when multiple LDAP servers are configured. If the PCE successfully connects to an LDAP server but the user is not found, the PCE attempts to connect to the next server in the configured order, and searches for the user again. In earlier versions, if the user is not found on the first server, the search stops. See How the PCE Works with Multiple LDAP Servers.

Enhanced Security for PCE TLS Configuration

For increased security, the PCE default minimum version is now TLS 1.2. Illumio recommends that you use TLS 1.2, the most secure version. However, some older operating systems might not support TLS 1.2. In these circumstances, you can change the default TLS version on the PCE. For information about changig the default TLS version, see TLS Versions for Communications.

The use of weak TLS ciphers, such as cipher block chaining (CBC) ciphers, is enabled on the PCE by default. Stronger ciphers are recommended. However, certain clients or operating systems might only be able negotiate TLS using CBC ciphers. If your managed environment if free from this limitation, Illumio recommends that you disable the use of weak TLS ciphers. See Reference: PCE Runtime Parameters in the PCE Installation and Upgrade Guide for more information about setting the insecure_tls_weak_ciphers_enabled PCE runtime parameter.

Supercluster Rolling Upgrade

Rolling upgrade is supported for PCEs in a Supercluster.

Rolling upgrade keeps the Supercluster operational while individual PCEs are upgraded one at a time. With a rolling upgrade, the Supercluster continues to operate.

Use the --upgrade-type rolling option on the migrate command:

illumio-pce-db-management migrate --upgrade-type simple|rolling

For more information, see Upgrade Supercluster in the PCE Supercluster Deployment Guide.

FQDN Enhancements in Data Visualization

Prior to Release 21.2.0, Explorer used to display certain packets as Blocked before an FQDN policy rule was decided. After the FQDN policy rule was decided, these flows were Allowed:

In Release 21.2.0, the VEN behavior for reporting of such dropped packets before an FQDN policy decision is made, are flagged uniquely as an Unknown state. This change is visible in Explorer and Illumination. Explorer now displays these initial packets as Unknown:

The PCE interprets these flows as an unknown policy decision. When the firewall has been programmed with the FQDN rule, a subsequent reported flow displays the policy decision as Approved.

Unknown packets are stored and can be queried from the Reported Policy Decision drop-down in Explorer. This allows you to filter packets that are in an Unknown state:

Illumination displays Unknown states in Gray. Once these flows are allowed, their color changes from Gray to Green.

Uninterrupted Traffic between the VEN and the PCE

The current VEN implementation in Release 21.2.0 provides an extra layer of self-protection that prevents any erroneous policy from being applied to the VEN. The VEN employs a defensive approach that reviews policies before applying them. In case the VEN detects that the new policy may disrupt communications between the VEN and the PCE, the VEN automatically isolates that policy and logs an error in the event log. The VEN then continues to communicate with the PCE using the existing functional policy.

Prior to Release 21.2.0, if an erroneous policy was inadvertently propagated from the PCE to the VENs, it caused a permanent disruption in communications. All VENs and all workloads were impacted and would remain in an undesirable state until the correct policies were reapplied. Manual intervention was required to reload the correct policy to resume communications between the VEN and the PCE. This is no longer required.

Linux Pairing Script Activation for Proxy Servers

Typically, VENs are paired with the PCE directly. However, if a workload is behind a Web Proxy, you must follow these steps to enable your Linux/Unix VEN to successfully pair to your PCE:

1. From the PCE web console menu, choose Pairing Profile.

2. Copy the pairing line from the Linux/Unix OS Pairing Script window.

3. Paste this pairing line into a text file so that you can edit it.

4. Edit the pairing line to make the following two changes (displayed in bold):

   1. Add –x <proxy-string> to the curl command to indicate the proxy string.

   2. Add --proxy-server <proxy-string> to the switch to pass the proxy string to the pairing script.

      rm -fr /opt/illumio_ven_data/tmp && umask 026 && mkdir -p /opt/illumio_ven_data/tmp && curl –x <proxy-string> --tlsv1 "https://test23.io:8443/api/v18/software/ven/image?pair_script=pair.sh&profile_id=1" -o /opt/illumio_ven_data/tmp/pair.sh && chmod +x /opt/illumio_ven_data/tmp/pair.sh && /opt/illumio_ven_data/tmp/pair.sh --management-server <server fqdn> --proxy-server <proxy-string>

5. Paste the revised script into the Linux/Unix terminal and press Enter.

The workload starts the pairing process. As the pairing script runs, you will see success messages appear. Wait until you see the message “Workload has been SUCCESSFULLY paired with Illumio,” which means your VEN (behind a proxy server) and the PCE are paired.

Updated SNC Capacity Requirements

The minimal and recommended sizes for CPU and memory for a single-node PCE cluster (SNC) have been updated.

For physical hardware:

• Cores: 3 (previously 2)

• RAM per node: 16GB (previously 8 GB)

For virtual machines:

• Virtual cores: 6 (previously 4)

• RAM per node: 16GB (previously 8 GB)

See Capacity Planning.