Associate a policy with an action
Next, let's link the newly created policy to the approval action so that when a policy is evaluated against an approval action, each condition is checked.
To do this, you'll need to send a POST request to associate the policy with the action.
Example request
In the request, you'll need to send through:
- the approval action ID as a path parameter:
98765
. - the policy ID in the request body:
12345
.
curl -L 'https://api.nullplatform.com/approval/action/98765/policy' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-d '{
"policy_id": 12345
}'
A successful response (200 OK) confirms the association.
What a policy evaluation looks like
Here's an example result of evaluating policies against the organization's entities:
{
"id": 123456,
"name": "Acme service rules",
"conditions": {
"service.name": {
"$dynamicPattern": {
"template": "^{application}-[a-zA-Z0-9_-]+$",
"fields": {
"application": {
"path": "tags.application"
}
}
}
}
},
"evaluations": [
{
"criteria": {
"service.name": {
"$dynamicPattern": {
"template": "^{application}-[a-zA-Z0-9_-]+$",
"fields": {
"application": {
"path": "tags.application"
}
}
}
}
},
"result": "not_met",
"nestedEvaluations": [
{
"criteria": {
"service.name": "acme-service-123"
},
"expected": "acme-app-[a-zA-Z0-9_-]+$",
"result": "not_met"
}
]
}
],
"passed": false
}
What's evaluated here:
- The policy requires the service name to start with the application name (as found in
tags.application
). - The application name (
acme-app
) is extracted from the tags. - The provided service name (
acme-service-123
) does not match the required pattern (acme-app-[a-zA-Z0-9_-]+$
). - As a result, the evaluation fails (
passed: false
), and the service creation request is flagged for manual review.
Alternative passing scenario:
If the service name had been acme-app-service-123
, it would have met the required pattern, and the evaluation would have resulted in "passed": true
.