How to Create Policy
Illumio users assign four-dimensional labels to their workloads to identify their roles, applications, environments, and locations. Users specify labels in ruleset scopes and in the Destination and Sources components of rules, allowing the workloads in their environments to communicate. Labeling workloads and creating the corresponding rulesets and rules define the security policies for workloads. The PCE converts these label-based security policies into the appropriate rules for the OS-level firewalls of the workloads.
About Rulesets
Every ruleset has three main components: the scope, intra-scope rules, and extra-scope rules.
The ruleset scope is defined by an Application label, Environment label, and a Location label. It defines which workloads are impacted by the rules within the ruleset. Any workloads that have the labels specified in the ruleset scope are covered by the policy.
See "Rulesets" in Security Policy Guide for more information.
All | All | All Scopes
Think carefully before creating a ruleset scope that includes all applications, all environments, and all locations (often referred to as an All | All | All scope). For example, if you created a ruleset with an All | All | All scope and added an intra-scope rule for All Workloads | All Services | All Workloads, you could inadvertently allow all traffic between all workloads on all ports on every Illumio-managed workload.
Typically, an All | All | All scope is mainly used for globally consumed outbound core services. Some core services, such as vulnerability scanners, Active Directory, and backup solutions, generate a lot of outbound connections to your workloads; therefore, creating their policy with an All | All | All scope is more efficient than creating it individually in each application's ruleset.
About Rules
Within a ruleset, you add rules. Rules define the communication allowed between applications or entities impacted by the ruleset scope or between different scopes. You create rules from the Destination perspective and the PCE automatically programs the outbound rules using the labels on the Destiunation side of the policy. Specifying IP lists in the Destination component of a rule creates inbound (Source side) only rules.
Intra-scope rules apply to the workloads inside the ruleset scope. They are bound by the scope on the Destination and Source side; therefore, all rules written apply only to the scope.
Extra-scope rules apply to workloads outside the ruleset scope. The Source side of an extra-scope rule is bound to the scope.
Note
IP Lists in rules do not affect labels and can be included in the same rule.
Important
Illumio recommends that you do not use more than one label type when including multiple labels in a rule. For example, customers often consider adding multiple Applications labels with an Environment label. However, be very cautious before creating this type of policy.
Global Destinations
Extra-scope rules include global Destination. In an extra-scope rule, global Destinations are not bound to the scope; therefore, you can use as many labels as you need in the Global Destinations section. If you do not specify a label in Global Destinations, the PCE uses “All” by default.
The Global Destinations section is the only part of the ruleset where the specified labels apply outside the ruleset scope.
Be very careful when using the All Workloads object in the Global Destination side of an extra-scope rule. The rule will impact every workload with an installed VEN in your environment.
Rule Writing Examples
The scope specifies A-DRUPAL, E-PROD, and All Locations in these examples.
Intra-scope Ringfence Rule
Intra-scope rule 1 specifies all workloads, all services, and all workloads for the Source, providing services, and Destination of the rule. This type of rule is called a ringfence rule. A ringfence rule allows all workloads within the scope to communicate with each other on all protocols. Creating an intra-scope ringfence rule eliminates the need to restrict access between workloads with the same labels.
Adding a ringfence rule is a quick way to create policy. A ringfence rule secures communication so you only have to track traffic to your application from Destinations outside the ruleset scope.
To visualize how an intra-scope ringfence rule works, see the example in the App Group Map.
In the App Group Map, the A-DRUPAL | E-PROD app group has a ring around it. The traffic inside the ring is the intra-scope traffic and the Consuming App Groups are the app groups connecting to the application from outside the scope.
Extra-scope Rules
The extra-scope rule below has one Application label (A-SYSTEMS) in the Global Destinations section. This rule allows inbound traffic for All Roles, Environments, and Locations for A-SYSTEMS to the A-DRUPAL | E-PROD environment in All Locations. This extra-scope rule does not prevent A-SYSTEMS | E-DEV from accessing the E-PROD application.
The following example shows a better way to write the extra-scope rule because it restricts inbound traffic from the R-SNAP role, the A-SYSTEMS application, and the E-PROD environment in all locations.
The following example shows an extra-scope rule with two Application, one Role, and one Environment labels. The PCE translates this Global Destination side rule as follows:
R-SNAP | A-HRM | E-PROD | All Locations
R-SNAP | A-SYSTEMS | E-PROD | All Locations
This rule is problematic because none of the A-HRM workloads have an R-SNAP label assigned to them; therefore, none of the A-HRM workloads are configured to access to R-WEB role for the defined ruleset scope.
If access to the R-WEB role by All Roles from either application is acceptable, simply remove the Role label. However, if you need Role-specific access, divide this rule into two rules, as shown in this example:
Custom iptables Rules
For Linux workloads only, you can add custom iptables rules to rulesets. In the Illumio Core, these rules provide the ability to program custom iptables rules needed for your applications. 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.
The following example shows an iptables rule that redirects incoming 2222 TCP requests to 22 TCP for the workloads defined in the Receivers section of the rule.
After provisioning, these rules operate on your workloads in all modes except idle mode. Your workloads do not have to be in enforcement mode for iptables rules to operate.
See "Custom iptables Rules" in REST API Developer Guide for more information.
Rule Search
By default, Rule Search shows you all the draft rules in the PCE.
You can use Rule Search to find rules assigned to any object type. From the Filter by Labels and Rule attributes drop-down list, select the object types that you want to restrict your search to. To download your search query, click the Download button.
The following example shows how to search for rules that include port 22 TCP. The search returns results for all draft rules.
To add columns so that you can view more rule details, click the Columns button:
See "Rules Search" in Security Policy Guide for more information.