OPA PDP
- Deena Mukundan
Overview
•OPA-PDP will be integrated as a new Policy Engine in the existing ONAP Policy Framework
•The OPA PDP Engine will utilize the open source implementation of Open Policy Agent to enable fine-grained policy decisions in ONAP
•It will support Rego version 1 for both policies and requests/responses for access control decisions
•Only Native Policy will be supported (Policy Type : onap.policies.native.opa)
•OPA-PDP will be compatible with all messaging interfaces towards PAP, similar to other Policy engines.
•OPA PDP will provide a Decision API that can be used to render decisions for ONAP components.
ONAP OPA PDP Supported Policy Types
Currently only Native Policy will be supported .This Policy type is used by any client or ONAP component who has the need of native OPA evaluation.
onap.policies.native.opa
Policy Type | Action | Description |
|---|---|---|
onap.policies.native.opa | native | any client or ONAP component |
Tosca template for the opa policy type is as below
tosca_definitions_version: tosca_simple_yaml_1_1_0
policy_types:
onap.policies.Native:
derived_from: tosca.policies.Root
description: a base policy type for all native PDP policies
version: 1.0.0
name: onap.policies.Native
onap.policies.native.opa:
derived_from: onap.policies.Native
version: 1.0.0
name: onap.policies.native.opa
description: a policy type for native opa policies
properties:
policy:
type: string
type_version: 0.0.0
description: The rego PolicySet or Policy
required: true
metadata:
encoding: Base64How OPA-PDP fits in ONAP Policy Framework
OPA-PDP high level architecture
Phase-1 implementation Details
In Phase-1 the OPA-PDP will be pre-loaded with sample policy, deployment of policy via PAP is not supported.
OPA-PDP implements a kafka listener, Publisher to receiving and sending messages to PAP
Once OPA-PDP is up it will send “Registration”( PDP_STATUS) message to PAP
Some of the information included in the message are:
pdpType the type of the PDP opa .
pdpGroup to which the PDP should belong to defaultGroup
state the initial state of the PDP which is PASSIVE.
healthy whether the PDP is “HEALTHY” or not.
name a name that is unique to the PDP instance for e.g. “opa-f849384c-dd78-4016-a7b5-1c660fb6ee0e”
Sample Registration Message { "messageName": "PDP_STATUS", "pdpType": "opa", "state": "PASSIVE", "healthy": "HEALTHY", "description": "Pdp Status Registration Message", "response": null, "policies": null, "name": "opa-949018d3-cc9b-429b-96ae-46ca9c314e42", "requestId": "9fed8880-d023-4004-b6bf-647efd10a7df", "pdpGroup": "defaultGroup", "pdpSubgroup": null, "timestampMs": "1731335546889" }
On receiving the registration message from a PDP, PAP checks and assigns it to a subgroup under the group. PAP sends PDP_UPDATE message. PAP also sends the pdpHeartbeatIntervalMs which is the time interval in which PDPs should send heartbeats to PAP. Currently (In first phase) OPA-PDP handles only the pdpHeartbeatIntervalMs and starts a timer for sending STATUS messages periodically. OPA-PDP sends PDP_STATUS response to PDP_UPDATE message.
OPA-PDP currently doesn’t handle the policies to be deployed sent in "policiesToBeDeployed" field in PDP_UPDATE
Example PDP_STATUS response
{
"messageName": "PDP_STATUS",
"pdpType": "opa",
"state": "PASSIVE",
"healthy": "HEALTHY",
"description": "Pdp Status Response Message For Pdp Update",
"response": {
"responseTo": "06f6d05f-6045-48d9-bcd8-40364fb695ae",
"responseStatus": "SUCCESS",
"responseMessage": "PDP Update was Successful"
},
"policies": null,
"name": "opa-949018d3-cc9b-429b-96ae-46ca9c314e42",
"requestId": "e6a0607f-5fc8-4d62-afca-3cb984d827a3",
"pdpGroup": "defaultGroup",
"pdpSubgroup": "opa",
"timestampMs": "1731335550030",
"deploymentInstanceInfo":""
}In Phase-1, OPA-PDP STATUS message will not include details on predefined policies (policy name and version). It will be assigned to “null”
PAP sends PDP_STATE_CHANGE message
OPA-PDP handles PDP_STATE_CHANGE. PAP sends PDP_STATE_CHANGE message to PDPs to change the state from PASSIVE to active or ACTIVE to PASSIVE. After registration is complete, PAP makes a PDP ACTIVE by default. OPA-PDP sends PDP_STATUS response to PDP_STATE_CHANGE. PDP updates its state as per the PDP_STATE_CHANGE received from PAP. When a PDP is changed to ACTIVE, any policies that are already pushed to the PDP start execution and start processing events as per the policies deployed.
In “ACTIVE” state OPA-PDP is in ready state to receive any decision requests
Example PDP_STATUS response for PDP_STATE_CHANGE
Currently OPA policies are pre-loaded in the docker setup.
Decision Requests are REST requests sent from ONAP components. Below is the format of Decision API request.
API endpoint :- policy/pdpx/v1/decision. Below is the snippet of Decision Request that will be received in Phase-1 .
Decision Response will contain following parameters
Currently OPA-PDP will respond with either PERMIT, DENY or INDETERMINATE values .
The policies and data json are currently mounted as files in docker volume for OPA-PDP.
OPA-PDP will also support health check request. The end point for health check is policy/pdpx/v1/healthcheck
Statistics :Currently we support only following counters and other counters will be set as 0.
totalErrorCount
permitDecisionsCount
denyDecisionsCount
totalPolicyTypesCount
Health Check API Request/Response
Support sending output in Decision Response
OPA supports sending structured response to OPA request. In order to support this functionality a new field “policyFilter” is added in the Decision request. If the policy filter is provided in the decision request, OPA-PDP will provide filtered response. 'policyFilter” is a list of filter values, we can specify multiple filters for which output is required. In case user wants to see the output only, then package name should be mentioned in the “policyName” field.
Below is an example of the policy rego file
Below is the example of request where output is required instead of decision.