Skip to main content

Illumio Security Policy Guide 26.x (SaaS)

Linux Process-Based Flow Visibility and Outbound Policy Enforcement

Linux Process-Based Flow Visibility and Outbound Policy Enforcement lets you observe and control outbound network connections from Linux workloads by adding the process identity as additional context to port and protocol rules. This helps security teams enforce least-privilege outbound access by specifying which processes are authorized to use allowed network paths.

In this solution, eBPF supplies process and connection context that drives outbound enforcement.

Note

This feature is Illumio’s Linux equivalent of its Windows process‑based outbound policy enforcement feature. (Windows additionally offers service‑based outbound policy enforcement.)

Use cases

  • Enforce least-privilege outbound access by allowing only approved processes to communicate with external systems.

  • Enable more effective investigation and incident response through process-aware outbound traffic visibility.

Supported platforms and scope

Linux process-based outbound policy enforcement is supported on specific Linux platforms and applies only to outbound traffic initiated by the workload. Enforcement occurs at the source host through the Linux VEN, with visibility provided through PCE flow records and logs.

  • Supported platforms: RHEL 9 and later, Rocky Linux 9 (RHEL 7 and RHEL 8 are not supported).

  • Enforcement location: Source host (Linux VEN)

  • This feature works with Allow rules in Full enforcement or Visibility modes. Deny rules and Selective enforcement are not supported.

  • Linux process-based rules complement existing IP-based rules; both must be satisfied for traffic to be allowed.

  • Only outbound traffic is supported in this release; process-based rules for inbound connections are not supported.

  • Performance impact is minimal because enforcement decisions are made at connection time.

Requirements

  • VEN release 26.2 or later

  • BTF-enabled kernel (standard on RHEL 9 and later)

  • cgroup v2 mounted (default on RHEL 9 and later)

Process identification details

Processes are identified by their full process path on disk. The path must match exactly as it appears on the workload’s filesystem. Symlinks are resolved automatically, and Unicode characters in paths are supported.

Note

Process identity refers to the process that the Linux operating system associates with a network connection when the connection is first established.

When a process is launched from a script (for example, python3 myscript.py), the process identity corresponds to the interpreter path (/usr/bin/python3), not the script.

Binary updates and policy behavior

When a binary is updated, it may be replaced with a new file on disk. The VEN detects the new binary on the next policy push and updates enforcement accordingly. Until that policy push occurs, the new binary is treated as unmanaged.

Configure Linux Process-Based Outbound Policy Enforcement

  1. Review outbound flow records to identify which processes initiate network connections and assess whether the current behavior matches your expectations or needs to be changed.

  2. In the PCE UI, go to Segmentation > Policy Objects > Services and add a process:

    1. Enter a name.

    2. (Optional). Enter a description.

    3. In Operating System, select Linux Outbound: Process-Based.

    4. In Service Definitions > Process Path, click Add, and then enter the full path(s) of the process(s) you want to manage. For example:

      /usr/bin/curl
  3. In the PCE UI, go to Segmentation > All Policies > Add from scratch and add an Allow policy.

  4. Add an allow rule to the policy and specify the Linux process(es) you defined in a previous step.

    Example configuration:

    To allow only curl and wget to reach an external API:

    • Process set: /usr/bin/curl, /usr/bin/wget

    • Rule: Allow TCP port 443 to 10.0.0.0/8

    Result:

    • curl https://api.example.com is allowed

    • wget https://api.example.com is allowed

    • python3 -c "import urllib..." to the same destination, blocked (enforced mode) or logged (Visibility mode)

  5. Save and provision the policy.

  6. Confirm the expected behavior by reviewing flow visibility data and testing the application.

Troubleshooting

Outbound traffic is blocked unexpectedly. Review flow logs to identify denied connections, confirm the recorded process identity, and verify that an appropriate allow rule exists for the process and destination.

Policy changes do not take effect. Confirm policy deployment status in the PCE and verify the workload is in scope. If the executable path changed (for example, was updated by package manager or the symlink target changed), update the rule to match the new path.