Create a Custom Policy

In addition to built-in Cost, Security, Operational, and Compliance policies, the system supports creating custom policies using the new and purpose built Policy Template Language. These policies can then be uploaded and applied in Flexera One just like the pre-built ones.

It's first recommended to view the Policy Lifecycle to get a general sense of what happens during the execution of a policy.

Following are resources to help create a custom policy:

Tooling
Sample Policies
Policy Authoring Walkthrough
Debugging Tips and Tricks
Testing and Publishing the Custom Policy

Tooling

There are a few tools that a developer might find useful for interacting with APIs in general and the policy APIs and workflow specifically.

rsc is the all-purpose Flexera One API client, written in Go. It supports all API calls from the Policy, Self-Service, and Cloud Management APIs with built-in help and validation.
fpt or the Flexera Policy Tool is a command-line tool that interacts with the Policy API in a more specific way. It helps with the most common tasks that come up when developing your own policies, such as testing JavaScript, calling against external APIs, and checking Policy Template syntax.
Postman or HTTPie are also popular general-purpose tools for calling APIs and can get used to examine raw API responses from external sources.

Sample Policies

The easiest way to get started on developing your own policies is to look at pre-existing code. The full source code to all published List of Flexera Policies is open source and available online. Policies such as Unattached Addresses and Azure Reserved Instance Utilization demonstrate many of the different parts of the language.

We recommend storing all your custom policy source code in a version control system such as github with the .pt file extension.

Debugging Tips and Tricks

Following are some recommended debugging tips and tricks when creating a custom policy:

Policy Debug Log
API-Based Datasources
JavaScript-based Datasources
Incidents
Escalation and Resolution Actions

Policy Debug Log

Whenever a policy is applied it automatically creates a debug log that can be viewed by users with the Create policies role in the given account. The debug log is viewable in the Flexera One user interface by navigating to the Policies menu and clicking Applied Policies. When the Applied Policies screen opens, navigate to the Actions column and click the ellipses to select View Log. It displays the following information as the policy is evaluated:

Outgoing http requests including headers, body, and query parameters
Resources, Datasource, and JavaScript data as its evaluated
console.log and console.dir statements from JavaScript
Information about failed validation/check statements

API-Based Datasources

Raw JSON responses can be gathered using whichever tool you choose and compared against the debug log above to see if transformations are proceeding as planned.

The debug log always prints out the first 6K of the final datasource after all transformations have been applied.

JavaScript-based Datasources

For more complicated data transformations and logic, its recommended to do most of the work using JavaScript in a policy template script block. For details, see the Policy Template Language. Policy scripts are run in an interpreter with a limited set of capabilities. A script datasource can contain one or more other datasources as inputs and always outputs a single datasource. fpt contains a retrieve_data command which can fetch those input datasources and extract them to disk. The fpt script command can then be run on those extracted datasources to test out logic. Arbitrary data can also be fed in to test out corner cases and other conditions. The fpt script command evaluates scripts locally using the same environment and libraries as the service does.

Incidents

All data failing validation will be listed in the debug log. To force all data to fail, in order to test subsequent actions such as email, run or data templates, you can add a check false statement which will cause an incident to always be created.

policy "my_policy"

  validate_each $my_datasource do

    detail_template <<-EOS

# Table of data

 

| Account | Type | Field1 |

| ------- | ---- | ------ |

{{ range data -}}

| {{ .account }}({{ .type }}) | {{.field1}} |

{{ end -}}

EOS

    escalate $my_escalation

    check false

  end

end

Escalation and Resolution Actions

Any escalation and resolution actions containing a run action will be executed in Cloud Workflow Language. These executions will show up under the Self-Service Cloud Workflow Console. The Self-Service product must first be selected by going to the Product selector in the upper right corner and select Self-Service -- users must have the Manage self-service role to access this tool.

For run escalation actions, code from a define block can be pasted into the Cloud Workflow Console and arbitrary data supplied in order to test out actions in isolation.

For run escalation actions, within the code defined in a define block, you can log to audit entries. These entries require at minimum the observer role to access.

escalation "foo" do 

  run "myaction", data

end 

 

define myaction($data) do 

  $$debug = true 

  call sys_log('policy action',$data)

end 

 

define sys_log($subject, $detail) do 

  if $$debug

    rs_cm.audit_entries.create(

      notify: "None",

      audit_entry: {

        auditee_href: @@account,

        summary: $subject,

        detail: $detail 

      }

    )

  end 

end 

For run escalation actions, within the code defined in a define block, you can reference any authentication defined in an auth or credentials declaration. These request signers will automatically be exported as global variables to the Cloud Workflow process. It is recommended to use the credentials declaration.

credentials "auth_aws" do 

  schemes "aws", "aws_sts" 

  label "AWS" 

  description "Select the AWS credential from the list" 

  tags "provider=aws" 

end 

 

escalation "delete_unencrypted_s3_buckets" do 

  run "delete_unencrypted_s3_buckets", data

end 

 

#https://docs.aws.amazon.com/AmazonS3/latest/API/RESTBucketDELETE.html 

define delete_unencrypted_s3_buckets($data) return $all_responses do 

  $$debug=true 

  $all_responses = []

  foreach $item in $data do 

    sub on_error: skip do 

      $response = http_delete(

        auth: $$cred_aws,

        url: join(["https://",$item['host'],"/", $item['bucket_name']]),

      )

      $all_responses << $response 

      call sys_log('Delete AWS Unencrypted S3 Buckets',to_s($response))

    end 

  end 

end 

If you want to test out the code in the Self-Service Cloud Workflow Console, you can mimic the credentials reference passed through from the policy with the signer function to authenticate requests using existing credentials. The signer function (signer($identifier), which requires the admin role, accepts the credential id, available on the credentials show page as Identifier.

Testing and Publishing the Custom Policy

This section provides instructions for:

Testing Policies 
Publishing Policies 

Testing Policies

Important:Testing policies requires the Create policies and Manage policies roles. For complete descriptions of each role available in Flexera One, refer to Flexera One Roles.

When you are ready to test a policy, perform the following steps.

To test a policy

1. Upload the policy by navigating to Automation > Templates.

The Policy Templates page appears.

2. Click the Upload Template button and follow the slideout instructions to upload your policy.
3. After the policy is uploaded, click Apply Policy to review the output and any actions you have created.
4. To view the applied policy do either of the following:
Navigate to Automation > Applied Policies.
Navigate to Automation > Incidents.

Publishing Policies

Important:Publishing a policy requires the Publish policies role. For complete descriptions of each role available in Flexera One, refer to Flexera One Roles. Once the policy changes are complete, it can be published to make it available to the Automation Catalog for all Automation users with the Manage policies role.

To publish a policy

1. Navigate to Automation > Templates.

The Policy Templates page appears.

2. Click the policy template on the left that you would like to publish.

The policy appears in the Template tab of the screen.

3. Click the Publish button.