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.

For e.g. consider a sample rego file having following contents

consistency.rego
package cell.consistency
default allow = false

# Rule to check cell consistency
check_cell_consistency {
    input.cell != data.cell.consistency.allowedCellId
}
# Rule to allow if PCI is within range 1-3000
allow_if_pci_in_range {
    input.PCI >= data.cellconsistency.minPCI
    input.PCI <= data.cellconsistency.maxPCI
}
# Main rule to determine the final decision
allow {
    check_cell_consistency
    allow_if_pci_in_range
}
------------------------------
topology.rego
package cell.consistency.topology
import rego.v1
 
# Rule to check cell consistency
check_cell_consistency if {
    input.cell != data.cellconsistency.allowedCellId
}

data.json

{   
  "allowedCellId" : 445611193265040129, 
  "minPCI": 1, 
  "maxPCI": 3000  
 }

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

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:
            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.0

For 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
default allow = false
# Rule to check cell consistency
check_cell_consistency if {
    input.cell != data.cell.consistency.allowedCellId
}
# Rule to allow if PCI is within 

...

range 1-3000
allow_if_pci_in_range  if {
    input.PCI >= data.cellconsistency.minPCI
    input.PCI <= data.cellconsistency.maxPCI
}
# Main rule to determine the final decision
allow  if{
    

...

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.cellconsistency.allowedCellId
}

data.json

{   

...

  "allowedCellId" : 445611193265040129, 
  "minPCI": 1, 
  "maxPCI": 3000  
 }

Deploy OPA policy

The same Policy API for deploying policy will be leveraged for OPA-PDP also.

The same CRUD API for policy -id: native.cell.consistency.opa policy-version: 1.0.0creation will be used here as well to create a policy

curl -u 'policyadmin:zb!XztG34' -X POST -H "Content-Type":"application/json" -d @deploy-policy.json http://policy-pap:6969/policy/pap/v1/pdps/policies

Contents of deploy-policy.json is shown
{ 
   "policies" : [
     {
      "policy-id": "cellconsistency",
      "policy-version": "1.0.0"
    }
  ]
}

OPA PDP after receiving the message on KAFKA will parse the message, extract policy, perform base64 decoding and deploys the policy to OPA. OPA PDP will send a PDP_STATUS message with the status of  policy deployment.

In the above case, OPA-PDP will create following directory structure and store policy and data files. The “.” mentioned in the policy will translate to subdirectories in OPA-PDP pod. This will also ensure each policy is referenced by the main rego file, this will avoid collision in case we have same library file used in multiple main rego files.

...

- /opt/policies
  - cell/
    - consistency/
      - policy.rego  // package cell.consistency will be stored here 
      - topology/ 
        - policy.rego  // package  cell.consistency.topology will be stored here 
- /opt/data
  - cell/
    - consistency/
      - data.json  // data will be stored here 

Policy Deployment - In Memory Mode

...

Policy Deployment - Bundle Mode

...

Option: 2 Packing both static Data and Policy in the same message.

Create a new Policy Type which includes data field also

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:
      data:
        type: map
        type_version: 0.0.0
        description: The data for Policy
        required: false
        metadata:
          encoding: Base64
      policy:
        type: map
        type_version: 0.0.0
        description: The rego PolicySet or Policy
        required: true
        metadata:
          encoding: Base64

OPA PDP will send a PDP_STATUS message with the status of  policy deployment.

Un-Deploy OPA policy

The same CRUD API for policy undeploy will be used here aswell to undeploy the policy

curl -u 'policyadmin:zb!XztG34' -X DELETE http://policy-pap:6969/policy/pap/v1/pdps/policies/native.cellconsistency.opa

OPA-PDP will receive PDP_UPDATE message and read the policies to be undeployed. policiesToBeUndeployed":[{"name":"cellconsistency","version":"1.0.0"}]

OPA-PDP will remove the directories /cell/consistency and polciy.rego file from the persistent storage and undeploy the policy from OPA SDK.

OPA-PDP will delete the data also, if PAP had deployed the data.

Data Deployment

OPA-PDP will support only dynamic update of data. This data will not be persisted in OPA-PDP. This facility is provided in case user want to fine tune the data configuration and validate. Once the configuration value is finalized , user can undeploy the existing policy and create data/policy with new configuration.

Modify existing Data ( whole or part data) using below CURD API

•Curl –u 'policyadmin:zb!XztG34' -X PUT -H "Content-Type":"application/yaml" –d @data.json http://policy-opa-pdp:8282/policy/pdpo/v1/data/{path:+}