Skip to main content

Creating a Policy

To create a Policy, open the Computational Governance Platform's registry by heading to Governance > Registry on the Witboost's navigation panel:

registry button

The Registry menu item in Witboost's navigation panel.

You will land in a page having an overview of all the available Policies and Metrics in the Computational Governance Platform. As shown below:

registry

The Computational Governance Platform's Registry main page.

To start the wizard for creating a new policy, click on Create Policy in the top right corner.

Step-by-step procedure​

In this section, we will see how to create a whole new Policy from scratch.

We will visit together each field of the wizard and how to fill them:

First step. Policy Metadata​

This section is to provide general information on the Metric that you are about to create.

General information

  • Name: A name for the policy, for display purposes.
  • Description: A description of the intended behaviour of the policy. What is it enforcing?
  • Environment: One or more environments where the policy will exist. By specifying more than one environment, you will actually create one distinct instance per environment, each one with a separate lifecycle.
  • Tags: (optional) A set of user-defined tags to more accurately distinguish the policy.

Platform Interaction settings

  • Interaction Type: Who is involved in the contract?. Explained in the Overview section. This information is used to generate notifications and to differentiate warning flags in the marketplace.
  • Severity: Defines how the policy behaves on non-compliant resources. Explained in dedicated section below.
note

Severity​

Severity defines how the policy will react to a non-compliant resource:

  • Info: This is the lowest severity level. Used to produce informative-only messages on non-compliant resources.
  • Warning: The Policy will raise a warning in the platform for the non-compliant resource, but a warning severity level won't prevent its deployment. The resource will still be deployable.
  • Error: The highest severity level, the resource will fail validation and will not deploy if the policy fails.

Execution settings

  • Context: Where does the execution of the governance entity happen?. Explained in the Overview section.
  • Timing: When is a governance entity executed?. Explained in the Overview section.
  • Cron Expression: It allows you to define the frequency of a governance entity execution during runtime.
  • Trigger: Who triggers the execution of this governance entity?. Explained in the Overview section.
  • Engine: How should the governance entity evaluate resources?. Explained in the Overview section.
  • Resource Preprocessing: How should the governance entity evaluate resources?. Explained in the Overview section.

Resources Perimeter settings

These settings allow you to restrict the resources that will be evaluable by the policy.

  • Resource Type: Which resources should the governance entity evaluate?. Explained in the Overview section.

  • Infrastructure Template ID (only available for Resource Type Data Product) It restricts the governance entity's resources perimeter to Data Products having the selected Infrastructure Template ID

  • Use-Case Template ID (only available for Resource Type Data Product) It restricts the governance entity's resources perimeter to Data Products having the selected Use-Case Template ID

  • Selectors: As an additional parameter to restrict the resources' perimeter, you can define filters to be applied to the resources descriptors. See details below.

note

Selectors​

Selectors are filters that can restrict which resources will be evaluated by the governance entity.

A selector is defined by three fields:

  • Description: a general description of the selector. for display purposes.
  • Path: a path to a field of the resource's descriptor
  • Values: field's value should be equal to one of these values

A selector checks that a given field of the resource's descriptor is equal to one of the allowed values.

As an example, let us consider this resource's descriptor:

environment: production
domain: finance
kind: dataproduct
domainId: urn:dmb:dmn:finance
id: urn:dmb:dp:finance:airflow-end-to-end-test:0
description: To perform end to end testing
name: Airflow End To End Test
fullyQualifiedName: null
version: 0.2.0-SNAPSHOT-1
billing: { }
tags: [ ]
specific:
  technology: airflow

We would like to check if the resource descriptor has the value airflow in his technology field. To do so, the selector will be defined as follows:

Selectors editor

In this example, the resource will fall in the governance entity's perimeter because at the path specific.technology there will be a match with an allowed value of the selector. Hence, this resource will be evaluated by this governance entity.

Second step. Engine Metadata​

Engine Metadata section allows you to insert the details needed by the selected engine and strategy to work:

  • For a policy that uses the CUE engine, you will be asked to provide a CUE script if you have one. This step is optional, since you can edit it later.

    CUE editor

    Engine metadata section when selected engine is Cue

  • For a policy with a Remote engine, you will be instead asked to provide a URL where the external service lives.

    External URL

    Engine metadata section when selected engine is Remote

Third step. Overview and confirmation​

As a final step, you will have an overview of all the details inserted, so that you can check that nothing is missing.

If you need to edit any field, you can go backward through each of the steps of the wizard.

To complete the creation process, click on Create.

CUE Engine​

The Computational Governance Platform offers an embedded CUE engine, that you can leverage to create Cue Policies.

For more information on the CUE Language, head to the official website here: CUELang Official Documentation.