Rulesets

You can use rulesets to write policy so the workloads in your application can communicate with each other. A ruleset consists of rules and scopes:

  • Rules define which workloads are allowed to communicate.
  • Scopes define which workloads the rules are applied to.

Ruleset Scope

The scope of a ruleset determines which workloads receive the ruleset's rules and enables the rules in a ruleset to apply to workloads in a group (one scope).

When workloads share the same set of labels defined in a ruleset's scope, those workloads receive all the rules from the ruleset. When you add a second scope, all the workloads within both scopes receive the rules from the ruleset.

A single scope is defined using three labels that identify the workload: 

  • Application: To what application (for example, ERP or HRM) do these workloads belong?
  • Environment: Which type of environment (for example, development, production, or testing) describes these workloads? 
  • Location: Where are these workloads located—either physically (for example, rack server or AWS) or geographically (for example, US, EU, or CA)?
NOTE:

The Role label should not be used in the scope.

For example, a scope (or collection of workloads the rules are applied to) is defined as ERP | Prod | US, which means that the rules apply to any workload that meets the following three requirements: 

  • Workloads in the ERP application
  • Workloads in the Prod (Production) environment
  • Workloads in the US location

That example is relatively simple, but combining rules and scopes can be used to create complex security policies.

For example, the following ruleset (scope + rules): 

Scope
App Env Loc
HRM Prod  US
Rules
Providers Services Consumers
DB MySQL App
App Tomcat Web
Web Apache Corp-HQ

Allows the following communication:

  • HRM | Prod | US | DB ← HRM | Prod | US | App
  • HRM | Prod | US | App ← HRM | Prod | US | Web
  • HRM | Prod | US | Web ← HRM | Prod | US | Corp-HQ

Single Ruleset Scopes

Using a single scope in a ruleset narrows the list of workloads that the rules apply to and allows workload cross-communication.

When you are defining rules, you have the option of using the “All” label in the scope. The “All” label applies to all instances of that label type (Application, Environment, or Location). For example, creating a rule with a scope of “All | All | All” means that the rule applies to all workloads.

When you create a rule with a scope of “HRM | All | US,” this rule applies only to workloads using the HRM and US labels, regardless of Environment (“All”). For example, the following ruleset: 

Scope
App Env Loc
HRM All US
Rule
Providers Services Consumers
DB MySQL App

Means “The HRM application in the US can initiate communications between the DB and the App in any environment” and allows the following communication: 

  • HRM | Anything | US | DB ← HRM | Anything | US | App

    Or

  • HRM | Dev | US | DB ← HRM | Dev | US | App
  • HRM | Dev | US | DB ← HRM | Prod | US | App
  • HRM | Prod | US | DB ← HRM | Dev | US | App

  • HRM | Prod | US | DB ← HRM | Prod | US | App

    (Assuming that “Dev” and “Prod” are types of Environment labels.)

Multiple Ruleset Scopes

Using multiple scopes in a ruleset applies the rules to each scope in isolation and does not allow workload cross-communication.

For example, consider the following ruleset: 

Scopes
App Env Loc
HRM Prod US
HRM Dev US
Rule
Providers Services Consumers
DB MySQL App

This rule and scope states: “Workloads using the HRM application in the Prod environment in the US can initiate communications between the DB and the App and workloads using the HRM application in the Dev environment in the US can initiate communications between the DB and the App,”

The rule and scope do not state: “Workloads using the HRM application in the Prod and Dev environment in the US can initiate communications between the DB and the App” 

This example allows the following communication: 

  • HRM | Prod | US | DB ← HRM | Prod | US | App

    And

  • HRM  | Dev | US | DB ← HRM | Dev | US | App

    But not

  • HRM | Prod | US | DB ← HRM | Dev | US | App

Combine Labels in Scopes and Rules

When the same type of label is used multiple times in a rule, they are expanded as multiple rules with one label for each rule.

The following examples further demonstrate how scopes work with rules. 

The following ruleset: 

Scope
App Env Loc
HRM All US
Rules
Providers Services Consumers
Prod MySQL Dev
DB MySQL DB

Means “Allow the database used by the HRM application in the Dev environment to communicate with the database used by the HRM application in the Prod environment” and allows the following communication: 

  • HRM | Prod | US | DB ← HRM | Dev | US | DB 

The following ruleset: 

Scope
App Env Loc
All All US
Rules
Providers Services Consumers
HRM MySQL ERP
Prod MySQL Dev
DB MySQL DB

Means “Allow the database used by the ERP application in the Dev environment located in the US to communicate with the database used by the HRM application in the Dev environment located in the US” and allows the following communication: 

  • DB | HRM |Prod |US ← DB| ERP |Dev |US 

The following ruleset: 

Scopes
App Env Loc
All Dev US
All Prod EU
Rules
Providers Services Consumers
HRM MySQL ERP
DB MySQL DB

Allows the following communication: 

  • All | HRM | Dev | US ← All | ERP | Dev | US 
  • All | HRM | Prod | EU ← All | ERP | Prod | EU
  • All | Dev | US | DB ← All | Dev | US | DB 
  • All | Prod | EU | DB  ← All | Prod | EU | DB 
NOTE:

When the service in a rule is DNS, the consumer must be an IP List.

Ruleset Status

You can view the ruleset status on the Ruleset page. The current status of the ruleset (enabled or disabled) is displayed in the Status column, as well as whether the ruleset was added, deleted, or modified. When you change the ruleset but haven't provisioned them yet, the type of change (added, deleted, or modified) is appended with the word “Pending” to indicate that these changes must be provisioned to be applied.

Filter the Rulesets List

You can filter the rulesets list using the label and property filter at the top of the list. You can filter the list by entering a label type to show only those rulesets that use the selected labels. You can further filter the list by selecting specific properties of the rulesets. For example, you can filter the list by provision status, such as rulesets that are in draft state and have not yet been provisioned.

Create a Ruleset

You can create a ruleset to write rules that define the allowed communication between workloads in a single group or multiple groups. See Groups in Illumination in the Visualization Guide for information.

When you write a rule for a Windows workload, you can add a Windows service name without specifying a port or protocol and the rule will allow communication for that service over any port and protocol.

NOTE:

Illumio recommends creating no more than 500 rules per ruleset, or the PCE web console will not be able to display all of the rules. If you want to create a ruleset with more than 500 rules, Illumio recommends splitting the rules across multiple rulesets, or use the Illumio Illumio Core REST API, where there is no limit on the number of rules you can create per ruleset.

The following task creates a single scope, which means the rules in the ruleset apply to a single group. To apply the rules to another group, add a second scope, which is indicated by the group's Application, Environment, and Location labels.

To create a ruleset: 

  1. From the PCE web console menu, choose Rulesets and Rules.

    The Rulesets page appears.

  2. Click Add.
  3. Enter a name for the ruleset.

  4. Select Application, Environment, and Location labels for the ruleset.

    These three labels define the scope for your ruleset, which is the range or boundary of your ruleset. The scope defines the workloads affected by this ruleset, which is all workloads that share the same labels in the scope.

  5. Click Save.

Now that the ruleset is created, you can add rules to define your security policy. See Rules for information about the types of rules you can add.

Create a Ruleset with Multiple Scopes

You can create rulesets with multiple scopes to define the allowed communication between workloads in one or more groups. See Groups in Illumination in the Visualization Guide for information.

How you define the scope in a ruleset enables you to write rules for workloads in multiple groups (two or more scopes). Each scope corresponds to one group. The scope defines the boundaries of the rules in the ruleset.

When you want workloads across groups to be able to communicate with each other, but don't want the rules of your ruleset to apply to all workloads in both groups, you can define your ruleset scope for All Applications, All Environments, and All Locations. You can then write rules that apply to individual workloads inside the two groups.

Example 1

For example, you have an ERP application that runs in the development environment in both the US and Asia and you want the databases of both ERP application instances to be able to communicate. Configure the ruleset as follows:

Scope

All Applications, All Environments, All Locations

Rule

Database, ERP, Development, US provides  MySQL service  to Database, ERP, Development, Asia

To create the ruleset: 

  1. From the PCE web console menu, choose Rulesets and Rules.

    The Rulesets list page appears.

  2. Click Add.
  3. Enter a name for the ruleset.
  4. In the Scope section, set the Application, Environment, and Location label to All.

  5. After you select the three labels, click Save.

    On the Scopes and Rules tab, you can see in the Scopes section that the Application, Environment, and Location label are set to All.

    NOTE:

    To edit the Scope, click the Edit button .

  6. In the Rules section, click +, then select Add Intra-Scope Rule to configure the rule that enables the databases of the ERP application in the production environment in the US to communicate with the databases of the ERP application in the production environment in Asia.
  7. From the Providers list, select the Database, ERP, Production, and US labels.
  8. From the Providing Service list, select the database service for the rule (for example, MySQL).

  9. From the Consumers list, select the Database, ERP, Production and Asia labels, and then click the Save button. The rule is added to the ruleset.

    The green Addition Pending icon in the rule indicates that this addition is pending, so you need to provision the new ruleset in order for the rule to take effect. See Provisioning for more information.

NOTE:

Example 1 includes steps for creating the rules contained within a scope. For information about rules, see Rules.

Example 2

You need to enable SecureConnect Enables users to encrypt communication between Workload services dynamically using IPsec. for all of your workloads to meet PCI compliance standards. Instead of writing a rule for each workload in your organization, you can create an advanced ruleset that enables SecureConnect for all services running on all workloads across all applications. For information about SecureConnect, see SecureConnect.

Scope

Application: All, Environment: PCI, Location: All

Rule

All workloads provide all services to all workloads using SecureConnect.

NOTE:

These instructions assume you have created an Environment label named PCI.

To create this ruleset: 

  1. From the PCE web console menu, choose Rulesets and Rules.

    The Ruleset list page appears.

  2. Click Add.
  3. Enter a name for the ruleset.
  4. Under Scopes, set the Application label to All, the Environment label to PCI, and Location label to All.

  5. After you select the three labels, click Save.

    On the Scopes and Rules tab, you can see in the Scopes section that the Application, Environment, and Location labels are set.

    NOTE:

    To edit the scope, click the Edit button.

  6. In the Rules section, click +, then select Add Intra-Scope Rule to configure a rule that enables all workloads to provide all services on all workloads to communicate using SecureConnect.
  7. From the Providers list, select All Workloads.
  8. From the Providing Service list, select All Services.
  9. Select the checkbox next to the SecureConnect option.
  10. From the Consumers list, select All Workloads.

  11. Click Save.

    The green Addition Pending icon in the rule indicates that this addition is pending, which means you need to provision the new ruleset in order for the rule to take effect. See Provisioning for more information.

NOTE:

Example 2 includes steps for creating the rules contained within a scope. For information about rules, see Rules.

Duplicate a Ruleset

When you have a ruleset that you want to use to create other new rulesets, you can duplicate an existing ruleset.

  1. From the PCE web console menu, choose Rulesets and Rules.

    The Ruleset list page appears.

  2. Click the Scopes and Rules tab, and then click Duplicate Ruleset.

    The Duplicate Ruleset page appears.

  3. Rename the copy of the ruleset.

    NOTE:

    The default name is “Copy of [Ruleset Name]” (where [Ruleset Name] is the name of the original Ruleset).

  4. Click Save.

After saving the new duplicate ruleset, make any needed scope or rule changes and then provision to apply them. See Provisioning for more information.