To help you create and update policy, you can create policy objects in the PCE. Policy objects include Segmentation Templates, services, IP lists, labels, label groups, user groups, virtual services, and virtual servers.
Some policy objects must be provisioned before any changes to them take affect on your workloads. See 
Segmentation Templates
Segmentation Templates provide prepackaged, tested security policies that provide all the segmentation rules needed for common enterprise applications. They can include services, rulesets, rules, labels, and IP lists.
To use Segmentation Templates, log into your Support account and download them from the Illumio Tools Catalog. See
Services
When you add a service to the PCE, you can specify multiple ports and protocols for the service and you can use it in multiple rules. When you update that service, the update applies to every rule where the service is added.
For example, if you update a service in the PCE by modifying its ports, every rule that includes that service will automatically include the updated ports.
Adding services to the PCE is not required because you can specify them in your rules when you create policy. However, creating a list of common services that you can reuse in rules makes creating policy faster and more efficient.
When the PCE analyzes traffic flows, it might display a service as a service object in the maps. If a service object doesn't exist, the VEN might report the service that it detected when it captured the traffic flow or report the service as unknown.
See
Windows Processed-Based Services
You can add Windows services to the PCE for specific processes running on Windows workloads.
IP Lists
IP lists allow you to define allowlists of trusted IP address, IP address ranges, or CIDR blocks that you want to allow into your datacenter and to be able to access workloads and applications in your network. Illumio recommends including IP lists in your rulesets and rules to cover traffic flows from workloads that don't have installed VENs. For managed workloads (hosts with installed VENs), you should create policy by specifying the workloads' labels.
Creating policy using IP lists has the following limitations:
- Because IP lists consist of static IP addresses, policy created from them is not adaptive like policy you create by using labels. See
- You cannot use an IP list in policy when the global consumer in the extra-scope rule has an installed VEN. IP lists do not program the outbound side of rules for consumers.
Pairing Profiles
A pairing profile is a configuration that allows you to apply certain properties to workloads as they pair with the PCE, such as applying labels, setting workload policy state, and more. You can create pairing profiles for specific workload deployments. However, Illumio customers often use generic pairing profiles for most of their workload deployments and update the workload labels after VEN installation.
When using a generic pairing profile, be sure that it contains generic default labels. This way, you can easily identify newly managed workloads that need updated labels.
See
Generic Label Example
- R-ONBOARDING
- A-ONBOARDING,
- E–ONBOARDING
- L-ONBOARDING
Virtual Services
You add virtual services to the PCE to create policy for multi-tenant applications and containers. Using virtual services, you can label services on a workload and add rules for specific services (not the entire workload).
For example, you have two databases in your environment that each run the same service on ports 1433 TCP and 3306 TCP. The databases are used by different applications. A workload can have only one set of labels. To create separate policy for each database application, you can uniquely label the database services on each workload based on their application.
See
Virtual Servers
Virtual servers are imported from configured load balancers. You can label the virtual IPs (VIPs) imported from load balancers and include them in policy. In the Illumio Core, you can enforce policy on the load balancer itself to restrict inbound access to the VIP. See
Labels and Label Groups
At a high level, policies are configurable sets of rules that protect network assets from threats and disruptions. The Illumio Core relies on policy to secure communications between workloads. Illumio policy uses a multidimensional label system to sort and describe the function of workloads. By describing workload functionally, policy statements are clear and unambiguous. Illumio users assign four-dimensional labels to their workloads to identify their roles, applications, environments, and locations. Creating policy by using labels is preferable over creating policy based on IP lists because policy created from IP lists is not adaptive like policy created by using labels.
You can create labels in several places in the PCE web console and the Illumio Core REST API. For example, go to Policy Objects > Labels from the main menu, or you can create them on the Workloads page.
In addition to labels, Illumio Core includes label groups, which are useful groupings of labels of the same type.
When you use a label group in a ruleset scope or a rule, the label group is expanded into multiple scopes or rules, respectively. Therefore, be aware that using multiple label groups in a policy can cause that policy to contain a large number of rules.
See
How the Label Types Affect Policy
The combination of the four label types defines the boundary of your “firewall” when applying application segmentation to your environment. When applying labels to your workloads, the labels define the boundaries for your policy.
Understanding how these labels affect policy is important:
- Role: Defines the primary role of a workload based on the application label. In some cases, the role of a workload might be generic because the application has only one role.
- Application: Defines the primary application running on a workload. If a workload is running multiple applications, contact an Illumio Professional Services representative to discuss these scenarios.
- Environment: Defines the environment an application is operating in; such as, production, QA, test, development, or staging.
- Location: Defines where the workload is located; such as, in a specific datacenter or region.
When adding labels to rules, the PCE calculates policy in the following way: labels use an OR between the same label type and an AND between different label types.
Labeling Example
The following labeling example shows a three-tiered application that consists of four web servers, four intermediate servers, and four database servers in a production environment and a development environment:
| Create this policy... | To have this workload affect... |
|---|---|
| For A-APP in E-PROD assign the ALL label for location | The policy only affects the workloads with the labels A-APP and E-PROD and the A-APP workloads in the E-DEV environment are not affected. |
| For the R-WEB role in the A-APP application in the E-PROD environment on port 443 TCP | Allows inbound traffic to the R-WEB role for A-APP in the E-PROD environment, but does not allow traffic to access the R-DB or R-Processing tiers. |
Label Naming Recommendations
Illumio recommends you adopt a label design strategy and consistently follow it.
- Apply the same label naming convention for all object types in the PCE.
- Use a prefix of the label type in your label design strategy.
- Consistently use the same case (upper or lower) for all label names.
See
Label Naming Examples
This example shows how a prefix for label type and uppercase are used for label names:
- R-WEB
- A-HRM
- E-PROD
- L-NY
This example shows how the same naming strategy is applied for other objects in the PCE, such as IP lists, services, and label groups:
- S-SNMP (SNMP services)
- IPL-USER_SUBNETS (IP list for user subnets)
- LGE-ALL ("Label Group Environment" for all environments)