Policy Filtering Solution Scoping - FINAL 8/19/2020
- Pamela Dragosh
- Gervais-Martial Ngueko
This page captures scoping effort for designing the solution for Policy Filtering.
Solution #1 - Add new Filter Guard Policy Type and use in conjunction with existing Blacklist
Goal: support controlled introduction of VNF's having operations performed upon them
Flow will be the same as current guard policy type implementation. Guard policies are created via CLAMP and deployed using PAP API. The XACML PDP returns decisions on guard decisions. The Drools PDP "frankfurt" (to be renamed "usecases") controller has the "guard" actor which makes the guard call to XACML PDP Decision API.
Pros:
Quick and easy to build and test with - goal is to simply re-use what is currently built in Policy/CLAMP
Could solve the majority of the DevOps needs
Cons:
DCAE will generate a lot of Control Loop events that will simply be ignored/retracted
Guard actor calls from Drools/Apex may need to be enhanced to pass properties to XACML PDP to render a decision. TBD - estimated to be a small amount of work.
Do we support compound fields? AND, OR
at this time, due to complexity we will not support compound fields.
Policy
Policy Type
Guard Filter Policy Type and Sample Policies
tosca_definitions_version: tosca_simple_yaml_1_1_0
policy_types:
onap.policies.controlloop.guard.common.Filter:
derived_from: onap.policies.controlloop.guard.Common
type_version: 1.0.0
version: 1.0.0
name: onap.policies.controlloop.guard.common.Filter
description: Supports filtering of A&AI entities such as vnf-id, type, service, geographic region, etc.
properties:
algorithm:
type: string
description: Designates the algorithm of blacklist-overrides vs whitelist-overrides
required: true
default: blacklist-overrides
constraints:
- valid_values: ["blacklist-overrides", "whitelist-overrides"]
filters:
type: list
description: List of filters to be applied.
required: true
entry_schema:
type: onap.datatypes.guard.filter
data_types:
onap.datatypes.guard.filter:
derived_from: tosca.nodes.Root
properties:
field:
type: string
description: Name of the field to perform the filter on using the A&AI <node>.<property> syntax.
required: true
constraints:
- valid_values:
- generic-vnf.vnf-name
- generic-vnf.vnf-id
- generic-vnf.vnf-type
- generic-vnf.nf-naming-code
- vserver.vserver-id
- cloud-region.cloud-region-id
filter:
type: string
description: The filter value itself. For example, "RegionOne" "vFWCL*"
required: true
function:
type: string
description: The function applied to the filter.
required: true
constraints:
- valid_values:
- string-equal
- string-equal-ignore-case
- string-regexp-match
- string-contains
- string-greater-than
- string-greater-than-or-equal
- string-less-than
- string-less-than-or-equal
- string-starts-with
- string-ends-with
blacklist:
type: boolean
description: |
Indicates if the filter should be treated as a blacklist (true)
or whitelist (false).
required: true
default: true
policies:
- filter.block.region.allow.one.vnf:
description: Block this region from Control Loop actions, but allow a specific vnf.
type: onap.policies.controlloop.guard.common.Filter
type_version: 1.0.0
version: 1.0.0
properties:
actor: SO
operation: VF Module Create
algorithm: whitelist-overrides
filters:
- field: cloud-region.cloud-region-id
filter: RegionOne
function: string-equal
blacklist: true
- field: generic-vnf.vnf-id
filter: e6130d03-56f1-4b0a-9a1d-e1b2ebc30e0e
function: string-equal
blacklist: false
- filter.allow.region.block.one.vnf:
description: allow this region to do Control Loop actions, but block a specific vnf.
type: onap.policies.controlloop.guard.common.Filter
type_version: 1.0.0
version: 1.0.0
properties:
actor: SO
operation: VF Module Create
algorithm: blacklist-overrides
filters:
- field: cloud-region.cloud-region-id
filter: RegionTwo
function: string-equal
blacklist: false
- field: generic-vnf.vnf-id
filter: f17face5-69cb-4c88-9e0b-7426db7edddd
function: string-equal
blacklist: true
Because of the difficulty for the application to determine "intent", the field "algorithm" is provided to allow the user to specify whether blacklist or whitelist overrides should be applied. The intent being to provide filter(s) that
whitelist-overrides
Thus, if a policy designer writes a filter that "whitelists" a specific VNF, then that filter overrides any additional "blacklist" filter policy that is more generalized in nature (eg for a vnf-type or region).
blacklist-overrides
If a policy designer writes a filter that "whitelists" a more generalized set of vnf (eg by vnf-type or region), then any additional "blacklist" filter policies will override.
This will be the initial implementation of the filter guard. More complex scenarios will have to be explored and policy translation can be changed in the future if warranted.
Since the Policy Framework is open to multiple policies being submitted, it is a recommended best practice that the policy designer should combine all filters into a single policy for a given actor/operation combination.
Runtime Flow
guard calls from drools/apex PDP will need to be extended to add new properties
CLAMP
Use of the existing yaml decoder to automatically render the UI in CLAMP should be able to handle this.
So for CLAMP, the work for this scenario will be TEST only!.
Future Solution #2 - Build a common Monitoring Policy Type for DCAE components to inherit from that captures filtering.
Each analytic would add common SDK to their analytic that enforces the filtering in each analytic.
Pros:
Ultimate flexibility by DevOps team to place filtering wherever they wish in the Control Loop
Simple control loops with only a one collector and analytic can be manageable
Cons:
Must build the SDK and re-factor existing DCAE components to integrate the SDK and ensure it is operating.
May become difficult to manage if we start adding multiple analytics into the flow. Highly unlikely but possible long term.
Future Solution #3 - Policy PDPs are scalable and lightweight - they could be positioned strategically in a control loop flow to capture and filter VES events going in/out of analytics
Requires PDP's to support VES events (small work?)
Pros:
All policy and rule enforcement stays within Policy PDP-D and PDP-X
Flexible PAP API can move and deploy policies as needed by DevOps team
No modification to DCAE components to enforce filtering policies