Policy Global Ordering and Conflict Resolution

Conflicts can arise between different policies defined under different scopes. More specifically, conflicts arise for workloads (inventory items) that belong to multiple scopes, such as parent/child, when those scopes have contradictory policies).

It is not feasible to resolve such conflicts manually due to the dynamic nature of scope membership; workloads can enter and leave scopes as their properties change. Therefore, the system imposes a global order, as described below, for all policies according to the scope under which they are defined. For each workload, the list of relevant policies (according to consumer/provider/scope) is identified and sorted by the global order. The decision to permit or drop a flow is made based on the first matching policy in the sorted list.

By understanding the global ordering scheme of security policies, network admins can define the correct scopes and their priorities to apply the overall desired policies on workloads. Within each scope, application owners maintain their ability to enforce fine-grained policies on their respective workloads.

A global network policy has the following characteristics:

• A set of scopes ordered by priority (highest priority first).

• Each scope's primary workspace has absolute policies, default policies and a catch-all action.

• Each group of absolute or default policies within each workspace is sorted according to their local priorities (highest first).

The global order of policies is defined as follows:

• Groups of absolute policies from the primary workspaces of all scopes (arranged from highest to lowest priority).

• Groups of default policies from the primary workspaces all scopes (arranged from lowest to highest priority).

• Catch-all policies from all scopes (arranged from lowest to highest priority).

Note that the scope order applies to groups of policies in category 1 and 2, rather than individual policies. Within each group, individual policies with lower policy priority numbers taking precedence.

For a specific workload, first the subset of scopes it belongs to is determined, then the above order is applied. The catch-all policy from the lowest priority (enforced) workspace to which this workload belongs is the applicable catch- all (but an absolute or default policy may override). For a given flow on that workload, the action of the highest matching policy is applied.

If a workspace has neither Absolute nor Default policies defined, the workspace is ignored. The workspace’s catch-all policy will not be included in the global order. The order of Default policies in the global order is the reverse of the scope priorities. This lets you define broad policies for all scopes to secure the perimeter of all workspaces including those that do not have policy enforcement enabled. At the same time application owners who have enabled enforcement on their scopes have the ability to override these default policies. Overlapping scopes are not recommended; see Scope Overlap for details. However, if a workload has two or more interfaces, in overlapping or disjoint scopes, the catch-all policy of the lowest priority workspace with enforcement enabled will apply (among all the applicable catch-all policies). We expand our previous three-scope example to illustrate this ordering scheme. Assume that the three scopes are assigned the following priorities (See Application Workspaces for instruction on how to change scope priorities):

1. Apps

2. Apps:HR

3. Apps:Commerce

The primary workspace of each of these scopes has absolute policies, default policies and a catch-all action. Each group of absolute or default policies within each workspace is sorted according their local priorities.

The global ordering of the policies are as follows:

1. Apps Absolute policies

2. Apps:HR Absolute policies

3. Apps:Commerce Absolute policies

4. Apps:Commerce Default policies

5. Apps:HR Default policies

6. Apps Default policies

7. Apps:Commerce Catch-all

8. Apps:HR Catch-all

9. Apps Catch-all

A workload that belongs to the Apps scope will receive only the following policies in the given order:

1. Apps Absolute policies that match the workload

2. Apps Default policies

3. Apps Catch-all

A workload that belongs to the Apps and Apps:Commerce scopes receive only the following policies in the given order:

1. Apps Absolute policies

2. Apps:Commerce Absolute policies

3. Apps:Commerce Default policies

4. Apps Default policies

5. Apps:Commerce Catch-all

A workload that belongs to the Apps and Apps:HR scopes will receive only the following policies in the given order:

1. Apps Absolute policies

2. Apps:HR Absolute policies

3. Apps:HR Default policies

4. Apps Default policies

5. Apps:HR Catch-all

Policy Order and Overlapping Scopes

The following scenario involves overlapping scopes. You should avoid having overlapping sibling scopes – workloads should not be members of multiple branches of the scope tree. For more information, see Scope Overlap.

A workload that belongs to all three Apps, Apps:HR and Apps:Commerce scopes will receive the following policies in the given order:

1. Apps Absolute policies

2. Apps:HR Absolute policies

3. Apps:Commerce Absolute policies

4. Apps:Commerce Default policies

5. Apps:HR Default policies

6. Apps Default policies

7. Apps:Commerce Catch-all

Note that the relative ordering of the Apps:HR and Apps:Commerce scopes only matters if the two scopes overlap (that is, there are workloads that belong to both sibling scopes.) This is because policies are always defined under a scope. A workload belonging to one scope only will not be affected by policies from the other scope, thus the order does not matter.