Enable redundant policy removal
This option is only available when generating policies for a branch of the scope tree.
This option enables/disables removal of redundant granular policies.
Example:
-
Let Root, A, B, C, A1 and A2 be scopes part of a scope tree. Let the following be the policies:
-
“Root” → “Root”
-
“B” → “Root”
-
“C” → “Root”
4. “A1” → “Root”
Figure 1: Before removal of redundant policies
-
-
The policies “B” →“Root”, “C” →“Root” and “A1”→ “Root” are redundant as the policy “Root” “Root” covers these policies. The remove redundant policies feature will check and remove such policies resulting in only one policy “Root” → “Root” as follows.
Redundant policy removal can be very useful in maintaining a succinct set of interpretable policies. The reduced policy set contains the minimal number of policies at the chosen compression level to cover all the workload traffic. However, you should always audit the policy through policy analysis and examine the corresponding conversations to evaluate the tightness of the resulting policies. This is especially important when there exists traffic to or from endpoints that are not categorized into finer scopes or inventory filters. Such endpoints may trigger the generation of coarser policies than intended, such as policies involving the root scope. If at the same time, redundant policy removal is enabled, more granular policies will be removed and will not be presented to you. To diagnose the source of (compressed) policies and to view finer level policies, turn off policy compression and redundant policy removal. Also note that currently, the automatic policy discovery conversations page may fail to show the conversations that lead to a compressed/generalized policy; so to get around this, you can turn off compression and redundant policy removal, so it is easier to find the conversations that lead to the generated policies.
|
Since discovering policies for a branch of the scope tree discovers all policies for the scope subtree rooted at the workspace scope, these policies will cover all the legal traffic seen by automatic policy discovery for all the workloads under the subtree. When analyzing these policies using tools such as Policy Analysis. See Policies), you should turn off Policy Analysis in all the workspaces associated with the subscopes. This way, the policies that are residing in the subscope workspaces (usually receive a high priority due to more specific scope definition) will not take priority and interfere with the results. However, exceptions apply when the policies in the subscope workspaces are configured to cover different sets of traffic that usually involve finer inventory filters or clusters specific to the subscopes. |