Software Secure Workload
Activity Configure

Unused Policies

This endpoint returns the policy identifiers in an published workspace for which no conversations are observed over a specified time interval.

Policy Identifier

All policies and ADM-generated clusters can change their IDs across application workspace versions even if the underlying filter queries or policy port and protocol do not change. In order to keep track of flow hit counts for a particular policy across workspace versions we use consistent UUIDs for the filters that do not change across versions and a composite key called the policy identifier comprising the provider and consumer consistent UUIDs along with rank, action, priority, port and protocol.

Thus, policy identifiers serve as a composite key that can both identify and describe the important aspects of a policy across application workspace versions, whereas policy IDs (such as those used in the regular CRUD endpoints) can change across versions of the workspace.


 

Provider/Consumer consistent UUIDs and policy identifiers do not uniquely identify a filter or policy as they are shared across different application workspace versions.

To perform CRUD operations on a particular cluster or policy it is recommended to resolve the identifier to a concrete policy for a specific application workspace version the search endpoint.

Regular CRUD operations can be performed using policy IDs whereas only Policy Statistics and Destroy With Identifier accept the policy identifier as input. This is mainly for convenience to avoid the intermediate call to search, and instead directly validate and destroy all unused policies in a workspace.

It is strongly recommended that policy and filter IDs are used wherever possible and to not manually generate policy identifiers for the Policy Statistics or Destroy With Identifier API endpoints. However, the following example illustrates one way of generating policy identifiers from the policy object:


    resp = restclient.get(f'/policies/631b0590497d4f09b537b973')
    policy = resp.json() # policy object
    policy_identifer = {
        'consumer_consistent_uuid': policy['consumer_filter']['consistent_uuid'],
        'provider_consistent_uuid': policy['provider_filter']['consistent_uuid'],
        'rank': policy['rank'],
        'action': policy['action'],
        'priority': policy['priority'],
        'protocol': policy['l4_params'][0]['proto'],
        'start_port': policy['l4_params'][0]['port'][0],
        'end_port': policy['l4_params'][0]['port'][1]
    }


 

After a new version of the application workspace is published it can take up to 6 hours before results become available. All the timestamp resolutions will also have a minimum granularity of 6 hours.

To get the unused policies across enforced versions of an application workspace the URL path is:

POST /openapi/v1/unused_policies/{application_id}/enforced

To get the unused policies across analyzed versions of an application workspace the URL path is:

POST /openapi/v1/unused_policies/{application_id}/analyzed

The query body consists of a JSON body with the following schema:

Name

Type

Description

t0

string

The beginning of the time interval in RFC-3339 format.

t1

string

(Optional) The end of the time interval in RFC-3339 format; defaults to current time if left unspecified.

limit

integer

(Optional) Limits the number of policies per request.

offset

string

(Optional) Offset received from previous response – useful for pagination.


    application_id = '62e1915e755f026f2bcdd805'
    resp = restclient.post(f'/unused_policies/{application_id}/analyzed', json_body=f'''
    {{
        "t0":"2022-07-06T00:00:00Z",
        "t1":"2022-07-28T19:00:00Z"
    }}''')'

Sample response

The response is a JSON object in the body with the following properties.

Keys

Values

application_id

The ID of the application workspace.

policy_identifiers

A list of policy identifiers of the unused policies.

offset

Response offset to be passed for the next page of results.

To generate the next page of results, take the object received by the response in offset and pass it as the value for the offset of the next query.


    {
      "application_id": "63054a97497d4f2dc113a9c4",
      "policy_identifiers": [
        {
          "consumer_consistent_uuid": "62fff45c497d4f5064973c4d",
          "provider_consistent_uuid": "62fff45c497d4f5064973c4d",
          "version": "p1",
          "rank": "DEFAULT",
          "policy_action": "ALLOW",
          "priority": 10,
          "proto": 6,
          "start_port": 10000,
          "end_port": 10000,
          "agg_start_version": 1,
          "agg_start_time": "2022-08-10T23:00:00.000Z"
        },
        {
          "consumer_consistent_uuid": "62fff45c497d4f5064973c4d",
          "provider_consistent_uuid": "62fff45c497d4f5064973c4d",
          "version": "p1",
          "rank": "DEFAULT",
          "policy_action": "ALLOW",
          "priority": 10,
          "protocol": 6,
          "start_port": 10001,
          "end_port": 10001,
          "agg_start_version": 1,
          "agg_start_time": "2022-08-10T23:00:00.000Z"
        }
      ],
      "offset": "eyJvZmZzZXQiOjZ9"
    }