OPA PDP Phase 2
- Deena Mukundan
Support Dynamic Policy Updation
User shall be able to deploy policy via PAP at run time. As currently we are supporting only Native policy for OPA, the design proposal is to encode rego file content in base 64 format and provide in the policy field.
Following actions to be supported at run time :-
Create OPA policy
Deploy OPA policy
Un-Deploy OPA policy
Dynamic Data Update
Create OPA policy
The same Policy API for creating policy will be leveraged for OPA-PDP also. As we are supporting only Native policy for OPA, the rego file content will be encoded in base 64 format and provided in the policy field as shown.
The same CRUD API for policy creation will be used here aswell to create a policy
curl -u 'policyadmin:zb!XztG34' -X POST -H "Content-Type":"application/yaml" --data-binary @policy.yaml http://policy-api:6969/policy/api/v1/policytypes/onap.policies.native.opa/versions/1.0.0/policies
For Create/Update Policy, In the tosca template the rego contents will be encoded and added in policy field. All the data key needs to be prefixed by “node”.
Tosca Definition for OPA
tosca_definitions_version: tosca_simple_yaml_1_1_0
topology_template:
policies:
- native.cell.consistency.opa:
type: onap.policies.native.opa
type_version: 1.0.0
properties:
data:
node.cell.consistency: >-
eyAgIAogICJhbGxvd2VkQ2VsbElkIiA6IDQ0NTYxMTE5MzI2NTA0MDEyOSwgCiAgIm1pblBDSSI6IDEsIAogICJtYXhQQ0kiOiAzMDAwICAKIH0=
policy:
cell.consistency: >-
cGFja2FnZSBjZWxsLmNvbnNpc3RlbmN5CmltcG9ydCByZWdvLnYxCmRlZmF1bHQgYWxsb3cgPSBmYWxzZQojIFJ1bGUgdG8gY2hlY2sgY2VsbCBjb25zaXN0ZW5jeQpjaGVja19jZWxsX2NvbnNpc3RlbmN5IGlmIHsKICAgIGlucHV0LmNlbGwgIT0gZGF0YS5jZWxsLmNvbnNpc3RlbmN5LmFsbG93ZWRDZWxsSWQKfQojIFJ1bGUgdG8gYWxsb3cgaWYgUENJIGlzIHdpdGhpbiByYW5nZSAxLTMwMDAKYWxsb3dfaWZfcGNpX2luX3JhbmdlICBpZiB7CiAgICBpbnB1dC5QQ0kgPj0gZGF0YS5jZWxsY29uc2lzdGVuY3kubWluUENJCiAgICBpbnB1dC5QQ0kgPD0gZGF0YS5jZWxsY29uc2lzdGVuY3kubWF4UENJCn0KIyBNYWluIHJ1bGUgdG8gZGV0ZXJtaW5lIHRoZSBmaW5hbCBkZWNpc2lvbgphbGxvdyAgaWZ7CiAgICBjaGVja19jZWxsX2NvbnNpc3RlbmN5CiAgICBhbGxvd19pZl9wY2lfaW5fcmFuZ2UKfQ==
cell.consistency.topology: >-
cGFja2FnZSBjZWxsLmNvbnNpc3RlbmN5LnRvcG9sb2d5CmltcG9ydCByZWdvLnYxCiMgUnVsZSB0byBjaGVjayBjZWxsIGNvbnNpc3RlbmN5CmNoZWNrX2NlbGxfY29uc2lzdGVuY3kgaWYgewogICAgaW5wdXQuY2VsbCAhPSBkYXRhLmNlbGxjb25zaXN0ZW5jeS5hbGxvd2VkQ2VsbElkCn0=
name: cell.consistency
version: 1.0.0
metadata:
policy-id: cell.consistency
policy-version: 1.0.0For e.g. consider a sample rego file having following contents
As in this below case, if there are multiple rego files. The policy name should contain the main rego file package name “cell.consistency” in this case. The main policy should be the first in the list and secondary rego file should have the name starting with main rego package name.
in this case “cell.consistency”.
package cell.consistency
import rego.v1
import data.cell.consistency.topology
default allow = false
# Rule to allow if PCI is within range 1-3000
allow_if_pci_in_range if {
input.PCI >= data.node.cell.consistency.minPCI
input.PCI <= data.node.cell.consistency.maxPCI
}
# Main rule to determine the final decision
allow if{
topology.check_cell_consistency
allow_if_pci_in_range
}
---
package cell.consistency.topology
import rego.v1
# Rule to check cell consistency
check_cell_consistency if {
input.cell != data.node.cell.consistency.allowedCellId
}data.json
{
"allowedCellId" : 445611193265040129,
"minPCI": 1,
"maxPCI": 3000
}