Rules
Rules can allow communication between multiple applications or entities in different scopes or the same scope. To write a rule, you need to define three things: A service, a provider of the service, and a consumer of the service. You also need to select the type of rule:
- Intra-scope rule: Allow communication within a group. The segmentation ruleset scope applies to both providers The Illumio model is provider-centric. You need to declare which consumers can access ports on providers. Providers cannot initiate connections to Consumers. and consumers A group of Workloads, Unmanaged Workloads, Virtual Services, or IP addresses that can initiate a connection to a Provider or consume a service. Use the Consumers section of a Rule to define who or what is allowed to communicate with a Workload..
- Extra-scope rules: Allow communication between groups. The segmentation ruleset scope applies only to the providers.
- Custom iptables rules: Allows custom iptables configurations in a segmentation ruleset. These rules are managed by the PCE and applied on each managed Linux workload VEN that matches the labels for the scope and receivers.
About Rules
Illumio supports the delegation of rule writing using role-based access control (RBAC). Application administrators can only edit rules where the scope of the segmentation ruleset matches the scopes where they have administrator privileges. They cannot create or manage segmentation rulesets if the scope includes “All.”
Rule types allow the application administrator to write rules that allow other applications to communicate with the applications that they manage without requiring global administrator privileges. This feature allows users to group rules required for inter-application and intra-application communication for a specific application into one segmentation ruleset.
You can combine multiple types of rules (intra-scope, extra-scope, and custom iptables) in a single segmentation ruleset. They can be used to either Create a Segmentation Ruleset or Create a Ruleset with Multiple Scopes.
From 18.2.0 version on, you can use multiple services or ports and protocols in a rule. This approach helps reduce the number of rules in your PCEs, which helps improve the PCE performance.
You cannot provision drop actions from the PCE in a NAT table for custom IP tables. Doing so results in a firewall generation failure.
Intra-scope Rules
Intra-scope rules allow authorized users to write rules that allow communication between providers and consumers 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 provider and the consumer. If you don't specify a Label, “All” is used by default.
Example:
In this example, all Database workloads with the labels HRM | US | Dev can accept MySQL connections from all Web workloads with the labels HRM | US | Dev.
Extra-scope Rules
Extra-scope rules allow authorized users to write rules that allow communication between applications. Specifically, you can write rules that allow providers within a scope to be accessed by consumers that can be in or outside the specified scope. For extra-scope rules, the labels used in the scope must match the labels used by the provider. If you don't specify a label, “All” is used by default.
Example:
In this example, all Database workloads with the labels HRM | US | Dev can accept connections on MySQL from all workloads with the label Web, irrespective of other labels.
The MySQL might not belong to the application HRM (for example, the consumers are “Global” and are not restricted by the labels in the scope).
If the RBAC user's scope coverage type is “Providers and Consumers,” the user cannot select an IP list as the consumer. To select an IP list as a consumer in a rule, the scope coverage type must be “Providers Only.” For more information, see IP Lists and Role-based Access Control in the PCE Administration Guide.
Custom iptables Rules
You might have configured iptables directly on your Linux workloads as needed 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 provide the ability for 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.
To clarify:
- iptables refer to a Linux host configuration before the VEN is installed
- Rules refer to statements written by the PCE to determine permitted traffic, typically by assuming control of iptables and programming the new rules
- iptables rules refer to iptables that are 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 that receive the rules. 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 prior to the last default rule.
Before they is sent to the VEN, the custom iptables rules are checked for any unsupported tokens (such as names of firewall chains already in use by Illumio, matches against IP sets, and semicolons). If an unsupported token is included, the rule cannot be saved or provisioned.
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 is logged in the organization events
- The error is displayed in the VEN policy sync status
- The new policy is not used and the last known 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 |
---|---|---|
raw
|
prerouting, output | No |
mangle
|
prerouting, input, output, forward, postrouting | Yes |
nat
|
prerouting, output, postrouting | Yes |
filter
|
input, output, forward | Yes |
security
|
input, output, forward | No |
If the RBAC user's scope coverage type is “Providers and Consumers,” the user cannot manage custom iptables rules. To allow access to custom iptables rules, the scope coverage type must be “Providers Only.” For more information, see Role-based Access Control in the PCE Administration Guide
Permitted Rule Writing Combinations
The following table explains the valid rule combinations between providers and consumers.
If Provider is | And Service is | Consumer can be |
---|---|---|
Workload, All workloads, label, label group | Any service | Workload , IP list (including Any (0.0.0.0/0 and ::/0), label, label group, user groups, All workloads |
IP list | Any service | Workload, label, label group, user groups, All workloads |
Uses virtual services |
Not applicable (the service is derived from the virtual service) | Workload, label, label group, IP lists, All workloads, uses virtual service, uses virtual services and workloads |
Uses virtual services and workloads | Any service |
Workload, label, label group, IP lists, All workloads, uses virtual service, uses virtual services and workloads |
Workload, All workloads, label, or label groups | Any service |
User groups and one or more of the following: workload, All workloads, label, label groups |
Stateless Rules
By default, all rules you write in the PCE are stateful, which means that the host's firewall keeps track of a connection for the entire duration of the session.
For Linux workloads, you can specify stateless packet filtering for a rule (“stateless”: true). This means that the VEN instructs the host's firewall to not maintain persistent connections for all sessions. You can create this type of a stateless rule for datacenter core services, such as DNS and NTP.
If you add a stateless rule to a policy that has both Windows and Linux workloads in its scope, then that rule is configured as a stateful rule on the Windows workload.
Caveats
In a stateless rule, you can add the following policy objects as consumers:
- An individual workload
- A label (one each of a specific type, up to four total)
- Any IP list plus All workloads
If you attempt to add any other consumers, you receive an error.
The Illumio Core limits the number of stateless rules to 100, to ensure that both stateful and stateless rules coexist on the host in a way that optimizes system and network performance. If you need more than 100 stateless rules in your Illumio policy, contact your Illumio Professional Services Representative for more information.
Existing active connections on workloads allowed by a stateless rule (for example, an SSH session) are terminated when workloads receive new rules from the PCE. Those connections need to be reestablished by the clients. For this reason, Illumio recommends that you use stateless rules for services that use high-frequency short-lived connections, such as DNS and SNMP.
Segmentation Rule Search
When you have a large number of rules organized in segmentation rulesets, you can't easily search for rules across rulesets. Segmentation rule search solves this issue by making it simple to search for specific rules.
For example, when you want to know how many rules there are for SNMP (UDP 161) and you have around 200,000 rules organized across 700 segmentation rulesets, it is time-consuming to narrow down that search without using this feature.
You can search for and analyze rules that allow communication over a specific port and protocol.
- Segmentation Rule Search allows you to quickly find rules that apply to a set of providers and consumers.
- Providers and consumers can be represented by a workload, an IP address, or a set of labels.
- Using this feature helps you identify rules that are getting applied to your workloads due to unnecessarily broadly applicable rulesets or human errors.
To search for rules:
-
From the PCE web console menu, choose Rulesets and Rules > Segmentation Rule Search.
The Segmentation Rule Search page appears.
- Search for Active or Draft rules.
- Perform a Basic or Advanced search of your rules:
- Basic: Searches all attributes
Advanced: Searches by provider, consumer, or both.
NOTE:When you perform an advanced search by workload name, the search results do not display the IP list rules when the iplist contains workload IP addresses because the Illumio Core does not resolve CIDRs and ranges within an IP list.
- From the Results drop-down list, choose to either have the exact match of the selected search filters to be displayed or a match to any of the selected filters (All Results).
- Click the Column drop-down list to select the attributes you want to be displayed in the search results.
- Filter options to further narrow your search.
- Under the Ruleset column, select a ruleset and make changes to the rules.
-
Click Download to download the results of your search.
You can download up to 500 rules in the CSV format.
Policy Check
The Policy Check feature allows you to determine if a rule allowing communication between workloads or a workload and another IP address already exists. On the Policy Check page, you select two workloads or IP addresses to determine if a rule exists to allow communication between them.
You can do a policy check between two workloads, or a single workload and single IP address.
For example, you have created several segmentation rulesets for your workloads and applications and you want to know whether your organization has an existing rule for that traffic before you start writing new rules that duplicate those existing rules.
To perform a policy check:
- From the PCE web console menu, choose Troubleshooting > Policy Check.
- In the Consumer field, type or select a workload or IP address.
- In the Provider field, type or select a workload or IP address.
- In the Provider Port and Protocol field, enter a port and protocol when the connection is running over TCP or UDP, or just a protocol when the connection is running over GRE or IPIP.
-
Click Check Rules.
If a connection is allowed between the selected two workloads or IP addresses, the page will display at least one rule that allows the connection.
-
NOTE:
The status column does not display any values. For more information, you can do a detailed search using the Segmentation Rule Search feature.
When a rule does not exists, the page displays “No Rules exist to allow that connection.”