...
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
| Code Block |
|---|
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
| Code Block |
|---|
{
"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
| Code Block |
|---|
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”.
| Code Block |
|---|
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
| Code Block |
|---|
{ |
...
"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 creation 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
| Code Block |
|---|
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.
| Tip |
|---|
The package name and policy name should be same. If not, OPA-PDP will fail to deploy |
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.
...
| Code Block |
|---|
- /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
| Code Block |
|---|
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 |
Design Discussion
...
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:+}