Illumio Segmentation: Policy and Enforcement
What this domain tests
Policy construction and enforcement mechanics: how Illumio rules are written, scoped, and rolled out without breaking production.
Core rules
- A rule is directional: a consumer label set reaches a provider label set on a defined service (port/protocol). Return traffic is allowed automatically.
- Rules live in rulesets, which can be scoped to an application or environment.
- The model is allowlist / default deny for traffic inside the enforced scope; anything without a matching rule is dropped once enforcement is on.
- Workload enforcement states: visibility only (log), selective (only explicitly enforced rules block), full (all active rules block).
- Use IP lists and unmanaged workloads to represent external systems such as load balancers, DNS, or mainframes that cannot run a VEN.
- Policy must be provisioned - draft changes do nothing until pushed to the VENs.
Worked example
A three-tier payments app: Role:web, Role:app, Role:db, all App:payments, Env:prod. Observed flows show web→app on 8443 and app→db on 5432, plus every host to DNS on 53. Draft three rules (consumer Role:web → provider Role:app, service TCP 8443; and so on). Run visibility for two weeks, compare with Illumination, fix missing backup and monitoring flows, then move to full enforcement tier by tier - web first. If you enforce full on day one without the DNS rule, the app breaks and you have manufactured an outage.
Traps
- Reversing consumer and provider.
- Enforcing full before the flow baseline is complete.
- Writing "all workloads → all workloads" rules that technically pass but destroy least privilege.
- Assuming a rule applies across environments when the ruleset scope excludes them.