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.