Skip to main content

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.