Skip to main content

Configuring approvals

In nullplatform you're allowed to take finer control over the lifecycle of certain entities through approvals.

Authorization vs. Approvals​

Approvals are a softer way to authorization in the sense that authorization represents a static, coarse-grained decision regarding "who can do what". On the other hand, approvals are designed to be more flexible, giving you the ability to give access under certain conditions (eg: "deploy only before 6pm") that can also be programmatic (ie: decided by a software that receives the approvals and checks the conditions).

It's also worth noting that, while authorization is standardized across organizations, approvals are extensible and can be tailored by each organization to fit its own needs.

Actions, Notifications & Policies​

To create an approval you have to create an approval action that specifies which resources and actions require an approval.

On the other hand, an approval is not useful if nobody can approve / reject it, so it's likely that you'll want to set one or more notifications for your approvals.

To tailor the approval process to your needs, you can configure a policy with business rules that determine the conditions and criteria for approvals.

Example Workflow​

  1. Create a Policy:
POST /approval/policy
{
    "nrn": "organization=1",
    "name": "Dev Scopes Rules",
    "conditions": {
      "scope.requested_spec.memory_in_gb": { "$lte": 4 },
      "scope.capabilities.scheduled_stop.enabled": true
    }
}
  1. Create an Approval Action
POST /approval/action
{
    "nrn": "organization=1:account=2:namespace=3:application=4",
    "entity": "scope",
    "action": "scope:create",
    "dimensions": {
        "environment": "dev"
    },
    "on_policy_success": "approve",
    "on_policy_fail": "deny"
}
  1. Associate the Policy with the Action
POST /approval/action/5678/policy
{
    "policy_id": 1234
}
  1. Example Result - Evaluating policies against the organization's entities.
{
  "policies": [
    {
      "id": 1,
      "name": "Dev Scopes should have less than 4GB ram",
      "conditions": {
        "scope.requested_spec.memory_in_gb": {
          "$lte": 4
        },
        "scope.capabilities.scheduled_stop.enabled": true
      },
      "evaluations": [
        {
          "criteria": {
            "scope.requested_spec.memory_in_gb": {
              "$lte": 4
            }
          },
          "result": "met"
        },
        {
          "criteria": {
            "scope.capabilities.scheduled_stop.enabled": true
          },
          "result": "not_met"
        }
      ],
      "passed": false
    }
  ],
  "action": "deny"
}

In this case, our particular scope, will be denied its creation.

Notifications for your approvals​

An approval is useful as long as somebody gets the approval notification and approves / rejects it, so we provide a way to set up notifications through different channels.

Please refer to our notifications section for instructions to start getting approval notifications.

Reply HTTP Notification​

After you determine if the approval should be approved or denied, you have to reply to the approval by doing an HTTP request to the approve_url or deny_url provided, where you can also indicate some metadata in the body.

Example to deny:

POST https://api.nullplatform.com/approval/1234/deny?token=the-token
{
  "reviewer": {
    "name": "Mr Manager",
    "email": "mr.manager@yourdomain.com",
    "nullplatform_user_id": null
  },
  "message": "Out of deployment window",
  "details": {
    "deployment_window": "Production services: weekdays, 9-11 AM"
  }
}

All fields in the approval reply body are optional, but they could help to provide visibility to requester in nullplatform's UI.

Approval denied details