Harness Policy Engine Overview for Feature Flags

Updated 2 weeks ago by Clare Wilkinson

Harness Policy Engine uses Open Policy Agency (OPA) to store policies that you can then enforce on your Feature Flags. You can use Harness Policy Engine with the following Harness entities on the Harness Platform:

  • Flag
  • Target
  • Target group
  • Environment
  • SDK keys

For example, you can use policies to ensure your Feature Flags: 

  • Match the naming convention you set.
  • Have only the correct type, for example, only Boolean flags can be created.
  • Have the correct default on and off values set. 
  • Have been turned on in a test environment before being enabled in a production environment.

This topic provides an overview of how Harness Policy Engine works with Feature Flags.

For steps to set up your policies on the Harness Platform, see Use Harness Policy Engine for Feature Flags.

In this topic: 

Before You Begin

Before learning about Harness Policy Engine, you should understand the following:

 New to Rego? Use the following resources to learn Rego:

How Does Harness Policy Engine Use OPA?

Harness Policy Engine uses OPA as the central service to store and enforce policies for the different entities and processes across the Harness Platform. You can define and store policies directly in the Harness Platform. 

In the Harness Platform, you add policies written in Rego to a Policy Set and select the Harness entities (for example, Feature Flags) for evaluation.

Screenshot of the Policy Editor

Then, when a Feature Flag is saved, Harness reaches out to the Harness OPA server to evaluate the action using the Policy Set. The Feature Flag is saved successfully, saved with a warning, or not saved and an error is received.

Example of a policy for a Feature Flag
  1. Set your policy: The names of all Feature Flags created must match the regex you set. You set the regex as having to be in the format ABC, dash, and three numbers, for example, ABC-123.
  2. Insert the Rego code into the Policy Engine on the Harness Platform, for example, the Rego code for the policy above is:
package feature_flags

# Deny flags whose names aren't a valid jira ticket format for our projects
# e.g. "ABC-123" is allowed. "My cool flag" is not allowed

deny[sprintf("feature flag name '%s' doesn't match regex", [input.flag.name])] {
   not regex.match("[ABC]+[-][1-9][0-9]?", input.flag.name)
}
  1. Run the policy against your Feature Flags.
When you create the policy you can choose whether a Feature Flag receives only a warning message, or receives an error and can’t be saved when the policy isn’t met. For more information about how to do this, see Creating a Policy.
  • Success: You create a Feature Flag and name it ABC-567, which matches the naming regex you set. When you save the flag, the policy rule is evaluated, returns Flag created, and the flag is saved.
  • Warning: You create a Feature Flag and name it Flag2, which doesn’t match the naming regex you set. The flag is saved but you receive the following warning message:
Screenshot of the warning message "Flag saved with policy warnings".
  • Failure: You create a Feature Flag and name it Flag2, which doesn’t match the naming regex you set. The flag doesn’t save and you receive the following error message:
Screenshot of the error message "flag cannot be saved due to the policy evaluation failures".

See Also 


Please Provide Feedback