About Rules
Rules enable communication between multiple applications or entities across different scopes or within the same scope.
Illumio supports the delegation of rule writing using role-based access control (RBAC). Application administrators can only edit rules where the policy's scope matches the scopes for which they have administrator privileges. They cannot create or manage policies if the scope includes “All.”
Rule types enable the application administrator to create rules that allow other applications to communicate with the managed applications without requiring global administrator privileges. This feature enables users to group rules required for inter-application and intra-application communication within a specific application into a single policy.
You can combine multiple types of rules (intra-scope, extra-scope, and custom iptables) in a single policy.
You can use multiple services, ports, and protocols in a rule. This approach helps reduce the number of rules in your PCEs, thereby improving PCE performance.
Note
You cannot provision drop actions from the PCE in a NAT table for custom IP tables. Doing so results in a firewall generation failure.
Types of Rules
Rules are created based on application groups, which define the scope of the rules.
To write a rule, you need to define three things: A service, a source of the service, and a destination of the service. You also need to select the type of rule:
Intra-scope rule: Allow communication within a group.
Extra-scope rules: Allow communication between groups.
Custom iptables rules: Allows custom iptables configurations in a policy. These rules are managed by the PCE and applied on each managed Linux workload VEN that matches the labels for the scope and receivers.
Intra-scope Rules
Note
The ability to create intra-scope rules is only enabled when the PCE is configured to display it.
Intra-scope rules enable authorized users to create rules that facilitate communication between sources and destinations within a specific scope. This rule type is typically used to allow communication between workloads that belong to the same application. For intra-scope rules, the labels used in the scope must match the labels used for both the source and the destination. If you don't specify a Label, “All” is used by default.
For example, you can create a rule allowing all Database workloads with the labels HRM | US | Dev to accept MySQL connections from all Web workloads with the same labels.
For intra-scope rules, both source and destination labels must match the labels defined in the scope.
Extra-scope Rules
Note
The ability to create extra-scope rules is only enabled when the PCE is configured to display it.
Extra-scope rules are created for communications coming from outside the scope.
Extra-scope rules enable authorized users to create rules that facilitate communication between the scoped application and external entities. Specifically, you can write rules that enable Sources within a scope to be accessed by Destinations in or outside the specified scope. For extra-scope rules, the labels used in the scope must match the labels used by the source. If you don't specify a label, “All” is used by default.
Label Matching: Destination labels must match those used in the scope, while source labels can be outside. For example, use "All Workloads" and "All Services" between application groups to learn about the roles and services that must be allowed without prematurely restricting communications.
Once you know the exact services and workload roles, switch to "Specific Workloads" and "Specific Services" to tighten security and allow only necessary communications.
In extra-scope rules, destination labels must match those used in the scope, while source labels can be outside the scope.
MySQL may not be part of the HRM application (for example, the destinations are “Global” and are not restricted by the labels in the scope).
Note
If the RBAC user's scope coverage type is “Sources and Destinations,” the user cannot select an IP list as the Destination. To select an IP list as a Destination in a rule, the scope coverage type must be “Sources Only.” For more information, see "Role-Based Access Control" in PCE Administration Guide.
Note
Understanding and correctly applying Intra-Scope and Extra-Scope rules in Illumio is crucial for effective application microsegmentation and security.•
Begin with broad rules and refine them over time to strike a balance between security and operational efficiency.
Custom iptables Rules
Note
The ability to create iptables rules is only enabled when the PCE is configured to display it.
Illumio supports custom iptables rules to keep configurations from native Linux host setups. This allows users to include custom iptables rules within the policy, ensuring new rules do not override existing Linux configurations.
Suppose you can configure iptables directly on your Linux workloads for your application workloads as part of your host configuration. However, when you pair a workload and put a policy into the Visibility Only or Full enforcement mode, the VEN assumes control of the iptables to enact the policy and does not apply any pre-programmed iptables to the policy.
Custom iptables rules in Illumio Core enable you to program the custom iptables rules needed for your applications as part of the rules managed by the PCE. Custom iptables rules help preserve any configured iptables from native Linux host configurations by allowing you to include them with the rules for your policy.
iptables refer to a Linux host configuration before the VEN is installed.
Rules refer to statements the PCE writes to determine permitted traffic, typically by assuming control of iptables and programming the new rules.
iptables rules refer to iptables inserted as rules onto the VENs and managed by the PCE.
Custom rules follow the iptables -A (append) command pattern:
-t<table>-A<chain> <rule>
Example:
-t filter -A INPUT -p tcp -s 10.10.10.10 --sport 8888 -j ACCEPT
Custom iptables rules consist of a list of iptables statements and the entities to which the rules are applied. Each rule can consist of a list of iptables rules, which allows users to group a sequence of rules for a specific function. The custom iptables rules are programmed after the Illumio PCE generates the iptables rules, but before the last default rule.
Before they are sent to the VEN, the custom iptables rules are checked for unsupported tokens (such as names of firewall chains already in use by Illumio, matches against IP sets, and semicolons). The rule cannot be saved or provisioned if an unsupported token is included.
If the VEN fails to apply a custom iptables rule because of a missing package or an incorrectly formatted rule:
The error is reported to the PCE and logged in the organization's event logs.
The error is displayed in the VEN policy sync status.
The new policy is not used, and the last successful policy is used instead.
For policy distribution and enforcement, the VEN creates a custom chain that contains the rules for each table or chain in the iptables. Each custom chain is appended to the end of its corresponding chain in the correct table. When the VEN requests the policy, the iptables command is sent, including the chain where it should be placed.
For security reasons, custom iptables rules only support rules in the mangle, nat, and filter tables.
The following table describes the permitted actions for each iptables type:
Table Name | Chain Names | Custom Rules Support |
|---|---|---|
| prerouting, output | No |
| prerouting, input, output, forward, post routing | Yes |
| prerouting, output, post-routing | Yes |
| input, output, forward | Yes |
| input, output, forward | No |
Note
If the RBAC user's scope coverage type is “Sources and Destinations,” the user cannot manage custom iptables rules. To allow access to custom iptables rules, the scope coverage type must be “Sources Only.” For more information, see "Role-Based Access Control" in PCE Administration Guide.
For more information about APIs, see "Custom IP Tables Rules Reference" in REST API Developer Guide.