Harness Governance Overview

Updated 2 weeks ago by Michael Cretzman

Currently, this feature is behind the Feature Flag OPA_PIPELINE_GOVERNANCE and is in Beta. Contact Harness Support to enable the feature.

This topic provides an overview of Harness Governance.

Looking for the quickstart? See Harness Governance Quickstart.

In this topic:

Before You Begin

Before learning about Harness Governance, you should have an understanding of the following:

How does Harness use OPA?

Harness Governance uses Open Policy Agent (OPA) as the central service to store and enforce policies for the different entities and processes across the Harness platform.

You can centrally define and store policies and then select where (which entities) and when (which events) they will be applied.

Currently, you can define and store policies directly in the OPA service in Harness.

Soon, you will be able to use remote Git or other repos (e.g. OCI-compatible registries) to define and store the policies used in Harness.

Governance Examples with Harness OPA

Example A: Pipeline > On Save

When a Pipeline is saved, there needs to be an Approval step before deploying to a production environment.

  • Success: you configure an Approval Step in the Pipeline and then proceed to configure a prod stage. When you save the Pipeline, the policy rule is evaluated and returns success.
  • Warning: a warning message appears: You need an Approval step. If you save the Pipeline and deploy, Harness will throw an error.
  • Failure: you configure a Pipeline with a Deploy stage that deploys to a prod environment without an Approval stage before it. When you save the Pipeline, Harness throws an error message indicating the rule was enforced and the Pipeline fails validation.

Example B: Pipeline > On Run

On deployment, I need my pod CPU and memory to be pre-defined.

  • Success: you deploy the Pipeline and during the dry run the pod CPU and memory have been defined and populated in the deployment manifest. As a result, the dry run progresses. Harness indicates that the rule was evaluated and the action was valid.
  • Failure: pod CPU and memory were not defined in the deployment manifest. As a result, the dry run fails. Harness indicates that a rule was enforced and the deployment is prevented.

Harness OPA Server

The Harness OPA server is an OPA server managed by Harness.

In Harness, you add Rego policies to a Policy Set and select the Harness entities (e.g. Pipelines) for evaluation. At that point, the policies are configured on the Harness OPA Server via a Kubernetes ConfigMap.

When certain events happen (e.g. saving or running a Pipeline), Harness reaches out to the Harness OPA server to evaluate the action using the Policy Set.

Harness Policies

A policy is a single OPA rule enforced on a Harness entity at a given event such as On Save, On Run, etc.

Policies are saved within the hierarchy in the Harness platform: Account > Organizations > Projects.

Policy scope is determined by the whether the policy is created at the account, Organization, or Project level. A policy added at the account level can be applied to all entities in the Orgs and Projects in the account. A policy added at the Project level can be applied to entities in that Project alone.

Polices can be tested individually, but they are not applied individually. To enforce a policy, it must be in a Policy Set.

Policies are written in the OPA policy language, Rego.

New to OPA Policy Authoring? Use the following resources to learn Rego:

Policy Editor

Harness policies are written and tested using the built-in policy editor.

For an example of how to use the policy editor, see Harness Governance Quickstart.

Harness Policy Set

You define a set of rules (policies) that are evaluated together in a Policy Set.

Policy Sets are stored to the Harness OPA server for a given entity type and event in Harness. The entity (Pipelines, etc) and event (On Save, On Run, etc) associated with a Policy Set determine when the policies in that set are evaluated.

Policy Sets are saved at the Harness account, Organization, or Project level, and where they are saved determines the scope of the Policy Set.

A Policy Set at the account level applies to all entities in the Orgs and Projects in the account. A Policy Set at the Project level only applies to entities in that Project alone.

Entities and Events

Currently, policies can be applied to Pipelines only.

Soon, policies can be applied to:

  • Connectors
  • Services
  • Environments
  • Feature Flags
  • Cloud Cost Management
  • Infrastructure Provisioners
  • Custom: You can define a policy with the entity type Custom. A Policy Set with the Custom entity type allows flexibility to enforce policy evaluations during Pipeline execution with different input data. For example, Terraform plans and deployment Environment details. A Policy Set with a Custom type does not have an event configured. You can trigger Policy Set evaluation via the Harness API from a Pipeline step.

See Also


Please Provide Feedback