Illumio

---
name: illumio
description: "Expert agent for Illumio micro-segmentation platform. Covers Policy Compute Engine (PCE), Virtual Enforcement Node (VEN) agents, label-based policy model (role/app/environment/location), application dependency mapping, enforcement boundaries, ring-fencing, Illumio CloudSecure, and workload segmentation. WHEN: \"Illumio\", \"Illumio PCE\", \"VEN agent\", \"micro-segmentation\", \"Illumio policy\", \"workload segmentation\", \"enforcement boundary\", \"application dependency map\", \"Illumio CloudSecure\", \"zero trust segmentation\"."
license: MIT
---

# Illumio

This skill covers Illumio, the enterprise micro-segmentation platform. It has deep knowledge of Illumio's Policy Compute Engine (PCE), Virtual Enforcement Node (VEN) agents, label-based policy model, application dependency mapping, enforcement modes, and cloud workload segmentation with Illumio CloudSecure.

## How to Approach Tasks

When you receive a request:

1. **Classify** the request:
   - **Policy design** -- Label strategy, rule writing, enforcement boundaries; load `references/architecture.md`
   - **Deployment** -- VEN agent deployment, PCE configuration
   - **Visibility/mapping** -- Application dependency mapping, Explorer queries
   - **Cloud** -- Illumio CloudSecure for cloud workloads
   - **Troubleshooting** -- Apply diagnostic methodology below

2. **Identify phase** -- Illumio deployments have distinct phases: Visibility > Test > Enforce. Ask which phase the workload is in.

3. **Gather context** -- Operating systems (Windows/Linux/container), cloud providers, number of workloads, existing network segmentation, application tiers.

4. **Recommend** -- Provide specific policy rules, label strategies, and enforcement guidance.

## Core Expertise

### Label-Based Policy Model

Illumio uses a four-dimensional label model to describe workloads. Policy rules are written in terms of labels, not IP addresses.

**Label dimensions:**

| Dimension | Purpose | Examples |
|---|---|---|
| **Role** | What the workload does | Web, App, DB, AD-DC, Kafka, Load-Balancer |
| **Application** | Which application it belongs to | OrdersApp, PaymentAPI, HRSystem, Splunk |
| **Environment** | Deployment tier | Production, Staging, Development, QA |
| **Location** | Where it runs | AWS-us-east-1, OnPrem-NYC, Azure-West |

**Why label-based policy matters:**
- Rules like "allow App:OrdersApp|Role:Web -> App:OrdersApp|Role:App on TCP/8080" are instantly human-readable
- When new servers are added and labeled correctly, they automatically inherit all applicable policies
- IP addresses never appear in policy rules -- policy doesn't break when IPs change
- Same policy rule works across cloud and on-premises without modification

**Label assignment:**
```
Workload: web-server-01.corp.local
  Role: Web
  Application: OrdersApp
  Environment: Production
  Location: OnPrem-NYC
```

### Rule Writing

Illumio rules define which labeled workloads can communicate with each other and on which ports.

**Rule anatomy:**
```
Rule: Allow Web tier to App tier
  Consumer: App:OrdersApp | Role:Web
  Provider: App:OrdersApp | Role:App
  Service: TCP/8080 (custom service or named service)
  Direction: Inbound (to Provider)
```

**Rule types:**
- **Intra-scope** -- Both consumer and provider in the same label scope (e.g., same app+env)
- **Extra-scope** -- Consumer outside provider's label scope (cross-application communication)
- **IP List** -- Rules for external IPs (internet, on-premise subnets not managed by Illumio)

**Common rule patterns:**

```
# Allow web tier to accept internet traffic
Rule: Internet -> Web
  Consumer: IP List: [All Networks 0.0.0.0/0]
  Provider: Role:Web | Environment:Production
  Service: TCP/443, TCP/80

# Allow three-tier application communication
Rule: Web -> App
  Consumer: Role:Web | Application:OrdersApp
  Provider: Role:App | Application:OrdersApp
  Service: TCP/8080

Rule: App -> DB
  Consumer: Role:App | Application:OrdersApp
  Provider: Role:DB | Application:OrdersApp
  Service: TCP/5432

# Allow all production to AD (example of cross-application rule)
Rule: All Production to AD
  Consumer: Environment:Production
  Provider: Application:ActiveDirectory | Role:AD-DC
  Service: [AD Services set: TCP/389,636,3268,3269,88,53,135,445]

# Block rule (deny)
# Illumio is deny-by-default; simply don't create an allow rule
# For explicit deny before another allow: use deny rules in rulesets
```

### Enforcement Modes

Individual workloads can be in different enforcement modes, enabling gradual rollout:

| Mode | Description | Use When |
|---|---|---|
| **Idle** | VEN installed but not enforcing; only reporting | Just deployed VEN; visibility only |
| **Visibility Only** | Monitoring all traffic, generating flow data | Building application dependency map |
| **Selective** | Enforcing only rules in the workload's rulesets; allow everything else | Initial enforcement with known rules |
| **Full** | Enforce allow rules; block everything not explicitly permitted | Final state; zero trust enforcement |
| **Test** | Evaluates policy but doesn't block; logs what would be blocked | Validating policy before Full mode |

**Recommended rollout sequence:**
```
1. Deploy VEN in Idle mode        -- Verify agent health
2. Move to Visibility Only        -- Build dependency map (2-4 weeks)
3. Draft policy rules             -- Based on observed traffic
4. Move to Test mode              -- Validate policy; identify gaps
5. Move to Selective mode         -- Enforce known rules; allow rest
6. Refine policy                  -- Add missing rules discovered in Selective
7. Move to Full mode              -- Full zero trust enforcement
```

### Application Dependency Mapping

Before writing policy, Illumio maps what actually communicates:

**Explorer (traffic analysis tool):**
```
PCE UI: Investigate > Explorer

Query example:
  Source: Environment:Production
  Destination: Any
  Time Range: Last 30 days
  Result: All observed flows from production workloads

Output:
  src_workload | src_labels | dst_workload | dst_labels | port | protocol | bytes | first_seen | last_seen
  web-01 | Web|OrdersApp|Prod|NYC | app-01 | App|OrdersApp|Prod|NYC | 8080 | TCP | 45234 | 2024-01-01 | 2024-01-15
```

**Finding policy gaps in Test mode:**
- All blocked flows appear in Explorer with `blocked_by_policy = true`
- Review blocked flows before moving to Full enforcement
- Add rules for any legitimate traffic appearing as blocked

**Illumio Map (visual dependency map):**
- PCE UI displays workloads as nodes, traffic as edges
- Color-coded by label (role, application, environment)
- Zoom in to application tier to view connections
- Policy coverage overlay shows which flows have rules and which don't

### Enforcement Boundaries

An Enforcement Boundary is a coarser-grained control -- a ring fence around a group of workloads. Traffic within the boundary defaults to blocked; traffic to/from outside the boundary follows normal policy.

**When to use enforcement boundaries:**
- Quickly ring-fence a sensitive application without writing all granular rules
- Segment an entire environment (all Production workloads) from Development
- Incident response: quickly isolate a compromised application

**Enforcement boundary example:**
```
Enforcement Boundary: Isolate PCI Applications
  Scope: Application:PaymentAPI | Environment:Production
  
  Effect: Block all traffic INTO the scope except what's explicitly allowed
  
  Allowed exceptions (rules still apply):
    - PaymentAPI Web -> PaymentAPI App (existing rule)
    - PaymentAPI App -> PaymentAPI DB (existing rule)
    - All traffic from outside PaymentAPI scope is BLOCKED
      even if there is no explicit deny rule
```

**Enforcement boundary vs. full enforcement:**
- Enforcement boundary is additive -- restricts traffic INTO a labeled group
- Works even for workloads in Selective or lower enforcement mode
- Useful for immediate isolation without requiring Full mode on all workloads

### VEN Agent Management

The Virtual Enforcement Node (VEN) is a lightweight agent installed on each workload.

**Platform support:**
- Windows: Server 2012 R2 through 2022, Windows 10/11
- Linux: RHEL/CentOS 6-9, Ubuntu 14-22, Debian, SLES, Amazon Linux
- Containers: Illumio C-VEN for container environments
- Cloud: Works in any cloud with supported OS

**VEN installation:**
```bash
# Linux (RPM-based)
rpm -ivh illumio-ven-21.5.0-1.x86_64.rpm

# Pair VEN to PCE after installation
/opt/illumio_ven/illumio-ven-ctl activate \
  --management-server https://pce.corp.local:8443 \
  --activation-code <code-from-PCE>

# Verify pairing
/opt/illumio_ven/illumio-ven-ctl status
```

```powershell
# Windows (MSI)
msiexec /i illumio-ven-21.5.0.msi /qn \
  MANAGEMENT_SERVER="https://pce.corp.local:8443" \
  ACTIVATION_CODE="<code-from-PCE>"

# Verify
Get-Service IllumioVEN
```

**VEN enforcement mechanism:**
- **Linux** -- Manages iptables (or nftables on newer kernels)
- **Windows** -- Manages Windows Filtering Platform (WFP) / Windows Firewall

VEN never modifies policies directly. The PCE computes the rules and pushes them to the VEN. The VEN translates PCE rules into native OS firewall rules.

**Policy computation flow:**
```
1. Admin writes labels + rules in PCE
2. PCE resolves labels to workload IP addresses
3. PCE computes per-workload firewall rules (iptables/WFP format)
4. PCE pushes computed rules to VEN agents via HTTPS
5. VEN applies rules to OS firewall
6. VEN reports back traffic flows to PCE
```

### Illumio CloudSecure

CloudSecure extends Illumio micro-segmentation to cloud workloads and cloud-native resources:

**Coverage:**
- AWS: EC2 instances, Security Groups, Lambda
- Azure: Virtual Machines, NSGs
- GCP: Compute Engine
- Kubernetes: Pod-to-pod segmentation via network policies

**CloudSecure approach:**
- Reads existing cloud resource tags (AWS Tags, Azure Tags) and maps to Illumio labels
- Manages cloud security groups/NSGs directly (no agent required for basic enforcement)
- VEN option for deeper visibility and workload-level enforcement

**Unified policy:**
Write one policy rule; Illumio automatically translates to:
- iptables rules (on-premises Linux)
- Windows Firewall rules (on-premises Windows)
- AWS Security Group rules (AWS)
- Azure NSG rules (Azure)

## Troubleshooting

### VEN Status and Health

```bash
# Linux VEN status
/opt/illumio_ven/illumio-ven-ctl status

# Show current iptables rules managed by Illumio
iptables -L -n -v | grep -A 5 "illumio"

# VEN logs
journalctl -u illumio-ven
tail -f /opt/illumio_ven/log/ven.log
```

```powershell
# Windows VEN status
Get-Service IllumioVEN
Get-EventLog -LogName Application -Source "Illumio*" -Newest 50
```

### Policy Not Blocking Expected Traffic

1. **Check workload enforcement mode** -- Workload must be in Selective or Full mode to enforce
2. **Verify labels** -- Workload must be labeled for label-based rules to apply
3. **Check rule scope** -- Is the rule in the correct Ruleset that applies to this workload?
4. **Explorer query** -- Query traffic flow in Explorer; look for `allowed_by_policy` or `potentially_blocked`
5. **Test mode** -- If not blocking in Test mode, policy is correct but mode is wrong; check enforcement mode

### Traffic Being Incorrectly Blocked

1. **Explorer query** -- Filter for `blocked` traffic from the affected workload
2. **Add rule** -- If legitimate traffic is blocked, add the appropriate allow rule
3. **Temporary relief** -- Move workload to Selective mode while investigating (enforces only explicit rules, allows rest)
4. **PCE events** -- Check PCE Admin Events for policy push errors

## Common Pitfalls

1. **Skipping the visibility phase** -- Moving directly to enforcement without 2-4 weeks of dependency mapping causes legitimate traffic to be blocked. Always build the dependency map first.

2. **Under-labeling workloads** -- Workloads without all four labels (Role, Application, Environment, Location) cannot be fully targeted by label-based rules. Establish a labeling taxonomy before deployment.

3. **Missing management traffic rules** -- Don't forget to allow traffic needed for workload management: monitoring agents (Splunk/Elastic), patching (WSUS, yum), backup agents, SNMP. These are often forgotten until enforcement blocks them.

4. **Moving to Full mode without Test mode validation** -- Always run in Test mode for at least a week before Full mode. Explorer blocked traffic view in Test mode reveals gaps.

5. **Applying Illumio to legacy systems without testing** -- Legacy Windows or old Linux kernels may have issues with Illumio managing their native firewalls. Test on non-production first.

## Reference Files

Load these when you need deep knowledge for a specific area:

- `references/architecture.md` -- PCE internals, VEN architecture, label resolution and policy computation engine, PCE HA deployment, API, Illumio Endpoint (user device segmentation). Read for architecture, PCE deployment, and advanced policy questions.