Endpoint protection policies are enforced in a specific order. When you design policies, consider the sequence number associated to rules and the domains that host the rules.

Scenario: Out of the many workloads that run in your organization, for the purposes of illustration we consider two kinds of workloads - VMs running Virtual Desktop Infrastructure (VDI), and VMs running Payments Cards Industry Data Security Standards (PCI-DSS) workloads. A section of employees in the organization requires remote desktop access, which makes up the virtual desktop infrastructure (VDI) workload. These VDI workloads might require a Gold protection policy level based on the compliance rules set up by the organization. Whereas a PCI-DSS workload needs the highest level of protection, Platinum level protection.

An example showing compliance policies configured to protect VDI workloads.

An example showing polices to protect PCI-DSS workloads.

As there are two workload types, create two policies one each for VDI workloads and server workloads. Within each policy or section, define a domain to reflect the workload type and within that section define rules for that workload. Publish the rules to start GI services on guest VMs. GI internally uses the two sequence numbers: Policy sequence number and rule sequence number to determine the complete sequence of rules to run. Each rule serves two purposes: determines which VMs to protect and the protection policy that must be applied to protect the VMs.

To change the sequence order, drag a rule in the NSX-T Data Center Policy Manager UI to change its sequence order. Alternatively, you can explicitly assign sequence number for rules using API.

Alternatively make an NSX-T Data Center API call to manually define a rule by associating a service profile with a VM group and declare the sequence number of the rules. The API and parameter details are detailed in the NSX-T Data Center API guide. Make Service configuration APIs calls to apply profiles to entities such as VM groups and so on.

Table 1. NSX-T Data Center APIs used to define rule that apply service profile to VM groups
API Details
Get all service configuration details. 
GET /api/v1/service-configs

The service configuration API returns details of the service profile applied to a VM group, the VM group protected, and the sequence or precedence number that decides priority of the rule.

Create a service configuration. 
POST /api/v1/service-configs

The service configuration API takes input parameters of a service profile, VM group to be protected, and sequence or precedence number that must be applied to the rule.

Delete a service configuration. 
DELETE /api/v1/service-configs/
<config-set-id>

The service configuration API deletes the configuration applied to the VM group.

Get details of a specific configuration. 
GET /api/v1/service-configs/
<config-set-id>

Get details of a specific configuration

Update a service configuration. 
PUT /api/v1/service-configs/
<config-set-id>

Update a service configuration.

Get effective profiles. 
GET /api/v1/service-configs/
effective-profiles?resource_id=<resource-id>
&resource_type=<resource-type>

The service configuration API returns only that profile which is applied to a particular VM group.

Efficiently manage rules by following these recommendations:

  • Set a higher sequence number for a policy for which rules must be ran first. From the UI, you can drag policies to change their priority.

  • Similarly, set a higher sequence number for rules within each policy.

  • Depending on how many rules you need, you can position rules apart in multiples of 2, 3, 4, or even 10. So, two consecutive rules that are 10 positions apart give you more flexibility to resequence rules without having to change the sequence order of all the rules. For example, if you do not plan to define many rules, you can select to position rules 10 positions apart. So, rule 1 gets a sequence number of 1, rule 2 gets a sequence number of 10, rule 3 gets a sequence number of 20, and so on. This recommendation provides flexibility to efficiently manage rules so that you do not need to resequence all the rules.

Internally, guest introspection sequences these policy rules in the following way. 

Policy 1 ↔ Sequence Number 1 (1000)

 - Rule 1 : Group 1↔ Service Profile ↔ Sequence Number 1 (1001)

 - Rule 2 : Group 1↔ Service Profile ↔ Sequence Number 10 (1010)

 - Rule 3 : Group 1↔ Service Profile ↔ Sequence Number 20 (1020)

 - Rule 4 : Group 1↔ Service Profile ↔ Sequence Number 30 (1030)



Policy 2  ↔ Sequence Number 2 (2000)

 - Rule 1 : Group 1↔ Service Profile ↔ Sequence Number 1 (2001)

 - Rule 2 : Group 1↔ Service Profile ↔ Sequence Number 10 (2010)

 - Rule 3 : Group 1↔ Service Profile ↔ Sequence Number 20 (2020)

 - Rule 4 : Group 1↔ Service Profile ↔ Sequence Number 30 (2030)

Based on the above sequence numbers, GI runs rules of Policy 1 before it runs rules of Policy 2.

But there are situations when the intended rules are not applied to a VM group or a VM. These conflicts need to be resolved to apply the desired policy protection levels.