Rules for Application Policies
Illumio allows or denies traffic between applications using policies that you write. To write application policies, you must create rules for the policy.
You can define and manage rules to control and secure communication within and between application groups.
Illumio has the following types of rules for application policies:
Application Policy Rule Types
There are three types of Application Policy rules:
Note
From the release 25.2.10, all rule types (Allow, Deny, and Override Deny rules) support label exclusion.
The ability to use an "all labels except. . ." approach when selecting labels for your rules was previously available only for Allow rules.
Override Deny Rules
Note
Override Deny rules require VEN release 22.3.0 or later.
These rules block all traffic, regardless of any other rules listed below them in the policy.
Because they have the highest precedence, they can't be overridden by another rule, such as any implemented Allow rules. If an administrator creates an Allow rule by mistake, the Override Deny Rule, which denies such communication, acts as a safeguard.
They are used to stop traffic completely, especially during a security breach.
Create an Override Deny rule:
Go to Policies and click Add.
Select Override Deny Rule and then click Add Rule.
In Sources, select one or more sources.
In Destinations, select one or more destinations.
In Destination Services, select one or more services.
Click Save.
Override Deny rule implementation.
There are various implementations for Override Deny rules, such as:
Blocking all traffic between your Production and Development environments except over
splunk-data (007 TCP)Additionally, blocking all traffic between all workloads over SSH with no possible exceptions (highest precedence)
To satisfy these requirements, proceed as follows:
Add a Deny rule specifying 'Production' as the source and 'Development' as the destination, blocking all services.
Add an Allow rule specifying the same source and destination, permitting traffic over
splunk-data (9997TCP).Add an Override Deny rule blocking all traffic between all workloads over SSH. Because this rule has the highest precedence, it cannot be overridden by an Allow rule.
Allow Rules
Allow rules have the second highest priority, after Override Deny rules.
They allow traffic to and from specific workloads. They act like security guards, permitting only registered or authorized traffic, and are used to define explicitly permitted traffic.
Deny Rules
Deny rules temporarily block specific traffic, often during initial setup. They are useful for blocking known problematic traffic while determining what should be allowed.
In the Allow List model transition, Deny rules are gradually replaced with Allow rules, which specify precisely which traffic is permitted.
Implementing Deny Rules During the Transition to Allow Rules
Start with deny rules to block risky traffic.
Monitor traffic patterns to understand what needs to be allowed.
Create the Allow rules for essential, trusted traffic.
Gradually remove deny rules as the Allow rules are established.
Once the Allow rules are fully enforced, all traffic is denied by default unless explicitly allowed by an Allow rule. Full enforcement of Allow rules ensures a secure and controlled network environment.
Conflicted Rules panel
You are now alerted when rules in the same or another policy in your organization conflict with one or more other rules.
Click the yellow icon to display a panel with the conflict details. Use the information to perform housekeeping on your policy or troubleshoot unexpected policy behavior.
Rules conflict when:
Traffic allowed by an Allow rule in your policy is overridden by an Override Deny rule in the same or another policy in your organization.
Result: Traffic is denied, which you may or may not have intended.
Traffic denied by a Deny rule in your policy is overridden by an Allow rule in the same or another policy in your organization.
Result: Traffic is allowed, which you may or may not have intended.