Enforcement Boundaries

In the Illumio Core 21.2.0 release, Illumio introduced Enforcement Boundaries, a new feature to speed your journey toward Zero Trust.

The Illumio security policy model is based on the principle of Zero Trust. Achieving Zero Trust security is possible with Illumio Core because it bases security policy on an allowlist model. From a security perspective, creating policy based on allowlists is the preferred method and has the advantage of specifying what you trust explicitly. However, you can encounter situations when you need more flexibility in segmenting your data centers. The solution is to introduce a new set of rules that determine where segmentation rules apply. These rules are referred to as Enforcement Boundaries in Illumio Core.

Enforcement Boundaries can block traffic from communicating with workloads you specify, while still allowing you to progress toward a Zero Trust environment.

For more information about deploying Enforcement Boundaries in your data center, see Policy Enforcement in the Security Policy Guide.

Selective Enforcement vs. Enforcement Boundaries

The introduction of Enforcement Boundaries resulted in changes to the REST API. This topic describes the major changes. For a description of all changes due to Enforcement Boundaries, see Enforcement Boundaries in the “Illumio Core REST API in 21.2” chapter of What's New in This Release.

Documentation Update: In Illumio Core 21.2, this topic for Enforcement Boundaries replaces the Illumio Core 20.2.0 topic for Selective Enforcement.

The APIs with the endpoints enforcement_boundaries replace the APIs with the endpoints selective_enforcement_rules. Specifically, the APIs for Enforcement Boundaries replace the APIs used for Selective Enforcement as follows:

sec_policy_selective_enforcement_rules_get.schema.json has been replaced with sec_policy_enforcement_boundaries_get.schema.json
sec_policy_selective_enforcement_rules_post.schema.json has been replaced with sec_policy_enforcement_boundaries_post.schema.json
sec_policy_selective_enforcement_rules_put.schema.json has been replaced with sec_policy_enforcement_boundaries_put.schema.json

Changes to the Policy Modes

In addition to the changes for Enforcement Boundaries, the policy modes changed in Illumio Core 20.2.0 and later releases in the following ways.

The existing common schema workload_modes.schema.json is DEPRECATED:

{
    "$schema": "http://json-schema.org/draft-04/schema#",
    "description": "DEPRECATED AND REPLACED (Use enforcement_mode instead)",
    "type": "string",
    "enum": ["idle", "illuminated", "enforced"]
}

The common workload_enforcement_mode.schema.json is added.

{
    "$schema": "http://json-schema.org/draft-04/schema#",
    "description": "Workload enforcement mode",
    "type": "string",
    "enum": ["idle", "visibility_only", "full", "selective"]
}

The following list compares the policy modes in Illumio Core 20.2.0 to 21.2.0:

idle is the same
illuminated (build, test) = visibility_only
enforced = full
selective: Added by workload_enforcement_mode.schema.json

Enforcement Boundaries in the REST API

The RBAC roles Global Org Owner and Global Admin can manage Enforcement Boundaries without restrictions.

You can only use Enforcement Boundaries with managed workloads. You cannot apply Enforcement Boundaries to NEN-controlled or other unmanaged workloads.

One or more ports on a workload are enforced ("port enforcement") while leaving the remaining ports unenforced. Instead of configuring workloads directly, enforcement is controlled using policies.

Workloads have to be placed in selective mode when using Enforcement Boundaries for them. Therefore, to use an Enforcement Boundary, you need to perform two separate configurations:

Set the workload policy state to selective.
Create security policy with a scope that includes the workload.

Enforcement Boundaries Methods

Functionality	HTTP	URI
View the configured enforcement boundaries	`GET`	`[api_version][org_href]/sec_policy/:version/enforcement_boundaries:/id`
Edit the specified enforcement boundary	`PUT`	`[api_version][org_href]/sec_policy/:version/enforcement_boundaries/:id`
Create a new enforcement boundary	`POST`	`[api_version][org_href]/sec_policy/:version/enforcement_boundaries`
Delete the specified enforcement boundary	`DELETE`	`[api_version][org_href]/sec_policy/:version/enforcement_boundaries/:id`

Enforcement Boundaries Parameters

Parameter	Description	Type	Required
`name`	Name of the enforcement boundary	String	No
`enabled`	Enabled flag	Boolean	No
`providers`	Enforcement boundary actor		No
`consumers`	Enforcement boundary actor		No
`ingress_service`	Ingress service		No

Enforcement Boundaries Properties

Property	Description	Type	Required
`href`	The job URI	String	Yes
`name`	Name of the enforcement boundary	String	Yes
`providers`	Reference to `enforcement_boundary_actor.schema.json`		Yes
`consumers`	Reference to `enforcement_boundary_actor.schema.json`		Yes
`ingress_services`	Collection of services that are enforced. Reference to `sec_rule_ingress_services.schema.json`		Yes
`enabled`	Enabled flag	Boolean	No
`created_at`	Timestamp when this Enforcement Boundary was first created. Format `date-time`	String date/time	No
`updated_at`	Timestamp when this Enforcement Boundary was last updated. Format `date-time`	String date/time	No
`deleted_at`	Timestamp when this Enforcement Boundary was deleted	String, Null	No
`created_by`	User who originally created this Enforcement Boundary Required parameter `href`.	Object, Null	No
`updated_by`	User who last updated this Enforcement Boundary Required parameter `href`.	Object, Null	No
`deleted_by`	User who deleted this Enforcement Boundary Required parameter `href`.	Object, Njull	No
`update_type`	Type of update	String	No

Get Enforcement Boundaries

curl -i -X GET https://pce.my-company.com:8443/api/v2/orgs/1/sec_policy/draft/enforcement_boundaries -H "Accept: application/json" -u $KEY:$TOKEN

Response

In this response, the former scope property is replaced with providers, and another property consumers was added. The required properties are: name, providers, consumers, and ingress_services(formerly enforced_service).

{
	"href":"/orgs/1/sec_policy/draft/enforcement_boundaries/1",
	"created_at":"2021-09-21T21:48:40.228Z",
	"updated_at":"2021-09-21T21:48:40.241Z",
	"deleted_at":null,
	"created_by":{
		"href":"/users/1"
	},
	"updated_by":{
		"href":"/users/1"
				},
	"deleted_by":null,
	"update_type":"create",
	"name":"Dev to Prod separation",
	"providers":[
		{
			"label":{
				"href":"/orgs/1/labels/7",
				"key":"env",
				"value":"Production"
			}
		}
	],
	"consumers":[
		{
			"label":{
				"href":"/orgs/1/labels/9",
				"key":"env",
				"value":"Development"
			}
		}
	],
	"ingress_services":[
		{
			"href":"/orgs/1/sec_policy/draft/services/1",
			"created_at":"2021-09-21T16:31:16.266Z",
			"updated_at":"2021-09-21T16:31:16.292Z",
			"deleted_at":null,
			"created_by":{
				"href":"/users/0"
			},
			"updated_by":{
				"href":"/users/0"
			},
			"deleted_by":null,
			"update_type":null,
			"name":"All Services",
			"service_ports":[
				{
					"proto":-1
				}
			]
		}
	],
	"caps":[
		"write",
		"provision"
	],
	"workload_counts":{
      
	}
}

Create Enforcement Boundaries

curl -i -X POST https://pce.my-company.com:8443/api/v2/orgs/1/sec_policy/draft/enforcement_boundaries -H "Content-Type: application/json" -u $KEY:$TOKEN -d '{"name": "eb1", "providers": [{"actors": "ams"}], "consumers": [{"actors": "ams"}], "ingress_services": [{"port": 1, "proto": 6}]}'

Update Enforcement Boundaries

curl -i -X PUT https://pce.my-company.com:8443/api/v2/orgs/1/sec_policy/draft/enforcement_boundaries/1 -H "Content-Type: application/json" -u $KEY:$TOKEN -d '{"name": "a4"}'

{
	"name": "a name here",
	"providers": [
		{"label": "/orgs/1/labels/13"},
		{"label": "/orgs/1/labels/15"},
		{"ip_list": "/orgs/1/sec_policy/draft/ip_lists/22"}
	],
	"consumers": [
		{"actors": "ams"}
		],
	"ingress_services": [
		{"href": "/orgs/1/sec_policy/draft/services/20"},
		{"port": 22, "proto": 6},
		{"port": 8080, "to_port": 8088, "proto": 6}
	]
}

REST API Developer Guide 22.5