Policies
You can write policies that enable the workloads in your application to communicate effectively.
A policy consists of rules and scopes:
Rules define which workloads are allowed to communicate.
Scopes define to which workloads the rules are applied.
Basic versus Scoped Policies
You can create a basic policy or a scoped policy. Choose whether you want to include scopes when you create new policies.
When the PCE is configured to create scopeless policies, you can create simple rules that do not apply to specific environments, locations, applications, or other categories you may have defined using flexible label types. Such rules are scopeless because they do not belong to a policy that uses scopes.
When you are new to using and creating your first security policy rules, consider creating basic rules, such as a simple rule to control SSH traffic for all your workloads. As you become more familiar with Illumio Core or need to create more complex rules, you can create scoped rules: intra-scope, extra-scope, and custom iptables rules.
Creating scoped rules enables you to define policies and rules tailored to specific environments, locations, applications (typically larger systems), or other categories you specify using flexible label types.
When the PCE is configured to create scopeless policies, you can add a scope to a policy after saving the policy.
Go to the Policies page, select a specific policy, and click on Add Scope.
Scopeless policies in the PCE web console
The following details apply to scopeless policies in the PCE web console.
An option in the Policy Settings page determines whether new policies are created with or without scopes. However, the permission every Illumio Core user has to create policies is always based on the scopes they can access, even when the PCE is configured to create scopeless policies.
Disabling scopes in policies does not invalidate the Policy Manager or Policy Provisioner roles used for user authentication or Role-Based Access Control (RBAC). For more information about these roles, see PCE Organization and Users.
When the PCE is configured to create scopeless rules, the Policy details page for a policy displays a single Rules tab where you add basic rules, including container hosts as the Destination.
When you add a scope to a scopeless policy after creating the policy, the page refreshes and displays and tabs. If any rules include container hosts for Destinations, those rules are moved to the tab.
Adding custom iptables rules is not available for scopeless policies. To create custom iptables rules, you must add a scope to the policy.
When you remove all scopes from a policy, the PCE merges the rules in the and tabs into a single Rules tab. However, any custom iptables rules created in the policy remain in the tab.
Policy Scope
The scope of a policy determines which workloads receive the policy's rules and enables the rules in a policy to apply to workloads in a group (one scope).
When workloads share the same set of labels defined in a policy's scope, those workloads receive all the rules from the policy. When you add a second scope, all the workloads within both scopes receive the rules from the policy.
A single scope is defined by using labels that identify the workload:
Application: To which 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 physically located (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.
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 create complex security policies.
Single policy scopes
Using a single scope in a policy narrows the list of workloads to which the rules apply, enabling 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 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 policy:
Multiple policy scopes
Using multiple scopes in a policy applies the rules to each scope in isolation, preventing workload cross-communication.
Labels in scopes and rules
When the same label is used multiple times in a rule, it is expanded to multiple rules with one label for each rule.
The following examples further demonstrate how scopes work with rules.
Note
When the service in a rule is DNS, the Destination must be in IP Lists.
Manage Policies
In this section, you will learn how to enable or disable scopes for policies, view policy status, and create policies.
Create a Policy
You can create a policy to write rules that define the allowed communication between workloads in a single group or multiple groups.
When you write a rule for a Windows workload, you can add a Windows service name without specifying a port or protocol. The rule will allow communication for that service over any port and protocol.
Note
Illumio recommends creating no more than 500 rules per policy; otherwise, the PCE web console will not be able to display all the rules.
If you want to create a policy with more than 500 rules, split the rules across multiple policies or use the REST API, where there is no limit on the number of rules you can create per policy.
The following task creates a single scope, which means the rules in the policy apply to a single group. Add a second scope indicated by the group's labels to apply the rules to another group.
You can use a template or create a policy from scratch.
Create a Policy from Scratch
Choose Policies > Add.
In the Add Policy dropdown list, choose Add from Scratch.
In the Add Policy dialog, type in the new policy's name and description
In the Scope dropdown menu, select:
Labels and Label groups: Select labels and label groups one by one from the list, or
Labels and Label Groups Except: For this option, you only need to remove the labels you want excluded.
These labels define the scope of the policy, which is its range or boundary. The scope defines the workloads affected by this policy or all workloads that share the same labels in the scope.
Note
The Scope field only appears when the PCE is configured to display it.
Add a Policy from a Template
Choose Policies > Add.
To create a policy from a template, you have the following choices:
Ransomware: This creates a set of deny rules for services and ports frequently used by Ransomware to spread across the environment.
Inbound Admin Access: This creates a set of rules for inbound traffic using SSH and RDP services and ports (including Jump boxes).
Outbound Admin Access: This creates a set of rules for outbound traffic using SSH and RDP services and ports.
Block Internet Access: This creates a deny rule that restricts all outbound traffic to the internet.
Active Directory: This creates a set of rules for default services and ports for domain controllers in your environment.
ICMP: Internet. Control Message Protocol is used for network maintenance and troubleshooting.
Select one of the templates and click Next.
Add a Policy for Ransomware
When you select the Ransomware template, a list of the existing deny rules is displayed.
You can confirm the selection and save or edit the Sources, Destinations, or Destination Services for any Deny rules.
To edit the Source, click on the specific Source link, and the next page will show whether the source can be edited. For example, a default IP List cannot be edited or removed.
To edit a Destination, click on the specific Destination link.
Click Add to add new members to the label group.
Select as many new members from the dropdown list as you wish.
Click Ok.
The Label Groups page now includes the newly added members.
Click Provision to get this provisioned.
You can use this same page to remove any existing label groups.
To edit the Destination Service, click on the specific link in that group.
On the Services page, you can edit the service by clicking Edit.
Change the Description, Protection Severity, or Attributes.
RANSOMWARE PROTECTION: Choose one of the severity levels: None, Low, Medium, High, or Critical
ATTRIBUTES: Use the option Service Definitions to add or remove ports and/or protocols
Add a Policy for Inbound Admin Access
When you select the Inbound Admin Access template, a list of the existing policies and deny rules is displayed.
Policy 1
You can edit the name or scope for each policy on the policy page.
Scope displays whether the policy contains extra-scope or intra-scope rules.
Edit Sources, Destinations, and/or Destination Services for any existing extra- or intra-scope rules (when allowed).
DENY RULES
Names of the Deny rules are not editable.
Sources and Destinations of the Deny rules are not editable as well.
The Destination Services page shows general information and attributes. To edit the service, click Edit.
GENERAL: You can edit both the name and the description
RANSOMWARE PROTECTION: Choose one of the severity levels: None, Low, Medium, High, or Critical
ATTRIBUTES: Use the option Service Definitions to add or remove ports and/or protocols.
Add a Policy for Outbound Admin Access
For the outbound admin access, there are only Deny rules.
DENY RULES
Names of the Deny rules are not editable.
Sources are editable, and you can add new members to the label groups using the dropdown list.
You can also remove any of the existing members of the label group.
Add a Policy that Blocks Internet Access
You can add a deny rule restricting all outbound traffic to the internet.
DENY RULES
Names of the Deny rules are not editable.
Sources (applications) can be edited by adding new label group members from the dropdown list.
Destinations (list of IP addresses) can be edited by removing any existing IKP addresses using a trash icon that appears after you double-click on the address. To add FQDN, type or paste a fully qualified name or FQDN inside the FQDN window.
Once the changes are in, click Confirm and Save.
Add a Policy for Active Directory
You can add a policy for default services and ports for domain controllers.
In the Rules for Active Directory page:
The Name of the policy is editable.
The scope of the policy is editable: add any existing label groups using the dropdown list.
Intra-scope rules in the policy
Sources:
If denoted by
(all), rules are not editable.If denoted by
(any), rules Destinations and Destination Services are editable.Once the changes are in, click Confirm and Save.
Add a Policy for ICMP
You can add a policy for ICMP (Internet Control Message Protocol).
POLICY 1
The Name of the policy is editable.
The scope of the policy is editable in the following instances:
If denoted by
(all), the rule is not editable.If denoted by
(any), the Destination Services rules are editable.Once the changes are in, click Confirm and Save.