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.

Basic versus Scoped Rulesets

You have the option to create basic or scoped rulesets. You can choose whether you want to include scopes when creating new rulesets. The Scope field appears in the Add Ruleset dialog box only when the PCE is configured to display scopes in rulesets. When the PCE is configured to create scopeless rulesets, you create simple rules that do not apply to specific environments, locations, applications, or other categories you may have defined using flexible label types. These rules are scopeless rules because they do not belong to a ruleset that uses scopes.

You might want to create these basic rules when you are new to using Illumio Core and you are creating your first security policy rules. For example, you might want to create a simple rule to control SSH traffic for all your workloads. As you become more familiar with Illumio Core or you need to create more complicated rules, you can choose to create scoped rules; namely intra-scope, extra-scope, and custom iptables rules. Creating scoped rules allows you to create rulesets and rules that are defined for specific environments, locations, applications (typically larger environments), or other categories you define in flexible label types.

When the PCE is configured to create scopeless rulesets, you can still add a scope to a ruleset after saving the ruleset. From the Ruleset Actions menu at the top right corner of the Ruleset page, select Add Scope.

For more information about rulesets, see also Rule Writing in this guide.

Behavior of Scopeless Rulesets in PCE Web Console

The following details apply to scopeless rulesets in the PCE web console:

• A option in the Policy Settings page determines whether new rulesets are created with or without scopes. However, the permission every Illumio Core user has to create rulesets is always based on the scopes they have access to even when the PCE is configured to create scopeless rulesets. Stated another way, disabling scopes in rulesets does not invalidate the Ruleset Manager or Ruleset Provisioner roles used for user authentication (also known as role-based access control). For more information about these roles, see Role-Based Access Control in thePCE Administration Guide.
• When the PCE is configured to create scopeless rules, the Ruleset details page for a ruleset displays a single Rules tab where you add basic rules, including container hosts as consumers.
• When you add a scope to a scopeless ruleset after creating the ruleset, the page refreshes and displays Intra-scope Rules and Extra-scope Rules tabs. If any rules include container hosts for consumers, those rules are moved to the Extra-scope Rules tab.
• Adding custom iptables rules is not available for scopeless rulesets. To create custom iptables rules, you must add a scope to the ruleset.
• When you remove all scopes from a ruleset, the PCE merges the rules in the Intra-scope Rules and Extra-scope Rules tabs into a single Rules tab. However, any custom iptables rules created in the ruleset remain in the Custom iptable Rules tab.

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 by using 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)?
• Flexible labels: If you have defined custom label types, you can use them to define a scope.

For example, a scope (or collection of workloads that 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, Location, or a flexible label type that you have defined). 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 

Enable or Disable Scopes for Rulesets

In Illumio Core 22.2.0 and later releases, you can control whether rulesets use a scope.

The Scope field appears in the Add Ruleset dialog box only when the PCE is configured to display scopes in rulesets.

To globally enable or disable scopes in the PCE:

1. From the PCE web console main menu, choose Settings > Policy Settings.

2. Click Edit.

3. In the Scopes in Rulesets section, toggle between Yes and No for the Display Scopes in Rulesets value depending on whether you want to enable scoped rulesets in the PCE.
4. Click Save.

Ruleset Status

You can view the ruleset status on the Rulesets page. The current status of each ruleset (enabled or disabled) is displayed in the Status column. When you change a ruleset but have not yet provisioned the change, the type of change (addition, deletion, or modification) appears in the Provision Status column 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.

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 labels.

To create a ruleset: 

1. From the PCE web console menu, choose Policy > Rulesets & Rules.

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

4. In Scope, select the labels for the ruleset: Application, Environment, Location, or any custom label types you have defined using Flexible Labels.

   These 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.

   NOTE:

   The Scope field only appears when the PCE is configured to display it. See Enable or Disable Scopes in Rulesets for information.

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.

Add a Scope to a Scopeless Ruleset

When the PCE is configured to create scopeless rulesets, you can still add a scope to an existing ruleset.

1. Click the name of a ruleset to display the Ruleset details page.

2. Select Add Scope from the Ruleset Actions menu at the top right corner of the page.

   The page refreshes and displays a dropdown list to select an existing scope.

3. Open the Select Scope list and select the labels you want to include for the ruleset scope.

4. When done selecting labels, exit the dropdown list and click the Save icon.

   The page refreshes and the new scope appears at the top of the page.

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.

To create a multi-scope ruleset: 

1. From the PCE web console menu, choose Policy > Rulesets & Rules.

   The Rulesets list page appears.

2. Click Add.
3. Enter a name for the ruleset.
4. In the Scope section, set the labels that define the scope by selecting the them from the drop-down lists. You can use Application, Environment, Location, or any custom label types you have defined using flexible labels.

5. After you select the labels, click Save.

   The page refreshes and the Scopes and Rules tab appears.

   NOTE:

   To edit the Scope, click the Edit icon .

6. To add another scope, click the Add Scope icon (+).

   A new field with a dropdown list appears in the Scopes section.

7. Set the labels for the new scope and click the Save icon at the end of the row.

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.

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 Policy > Rulesets & Rules.

   The Ruleset list page appears.

2. Click the ruleset, then Ruleset Actions > Duplicate Ruleset.

   The Duplicate Ruleset dialog 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.