REGO 101: Starting Your PaC Journey

Last updated
April 18, 2024

Table of Contents

No items found.

Try Monokle Desktop Today

In the world of policy enforcement and management, the Open Policy Agent (OPA) has emerged as a pivotal tool to help organizations implement a consistent policy enforcement layer across various components in their stacks. And, underpinning the workings of OPA is a powerful, high-level declarative language known as REGO.

Here, we'll give you a beginner-friendly introduction to REGO where we'll provide an understanding of its foundational concepts and show how it can be effectively employed to define and enforce policies.

What is REGO?

REGO is the policy language used by the Open Policy Agent (OPA) for policy definition. It's a high-level declarative language, meaning you describe your desired state or outcome, and REGO figures out the steps to achieve it. This abstraction removes the necessity for users to specify how to reach a goal, focusing instead on what the goal is.

REGO's Components

A REGO policy file is typically composed of three main components:

  1. Data: The information that your policy uses to make decisions. This could be static data included directly in the policy, or dynamic data from your application or environment provided to OPA as input.
  2. Rules: Rules are the assertions that govern how the policy is evaluated. They're like the logic or the conditions that define your policy. Rules can be simple (like "all containers must have a set resource limit") or complex, involving multiple conditions and logic operators.
  3. Packages and Imports: Packages in REGO help group rules under a common namespace, much like packages in software development. Imports are used to bring in namespaces into the policy file to use their rules or data.

How REGO Works

At its core, a REGO policy defines a desired state or behavior. When you query OPA with some input, the REGO policy evaluates that input and returns a decision.

Consider a simple policy that dictates, "all Kubernetes deployments should run with a non-root user". The input to this policy might be the configuration data of a proposed deployment. The REGO policy evaluates this data against its rules, and returns a decision: either the deployment is compliant (it uses a non-root user), or it's non-compliant (it uses a root user).

Below, we'll break down exactly how REGO works step-by-step:

1. Basic Structure

REGO policies are composed of:

  • Rules: Rules define the logic and conditions that should be met. They consist of a head (name and output) and a body (one or more expressions which must all be true for the rule to be satisfied).
  • Packages: Rego allows you to group rules into packages for better organization.
  • Imports: This lets you use rules and data from other packages.


In the above example:

  • play.greeting is the package name.
  • There are two rules named hello.
  • The first hello is a default rule, which will be used if no other rule named hello is true.
  • The second hello rule has a body with two expressions; both must be true for the rule to be satisfied.

2. Data Input

REGO can make decisions based on the input data you pass to it. The data is usually JSON, and Rego can evaluate this data against the policies you define.


Passing the following input would trigger the second rule:

3. Built-In Functions

REGO includes numerous built-in functions for operations such as string manipulation, arithmetic, aggregation, and more. This adds to the expressiveness and power of the language.


4. Variables

REGO allows for the declaration of variables within rules. This can be helpful for creating more readable and modular policies.

5. Decision Making

OPA evaluates Rego policies to make decisions. This usually involves checking if certain conditions are met (expressed in the body of rules), and returning corresponding values or actions defined in the head of the rule.

6. Policy Composition

Rego policies can be composed by importing rules from different namespaces. This allows for reusability and modularization of policy logic.

7. Safety

REGO is designed with safety in mind. A policy query will never have undefined behavior, and policies will always produce complete and defined results.

REGO's high-level, declarative nature allows for the concise expression of complex logic in policies. Its ability to handle JSON input, use built-in functions, and compose policies makes it a powerful tool in the Open Policy Agent for policy definition and enforcement across various systems and applications.

About Monokle

Monokle helps you achieve high-quality Kubernetes deployments throughout the entire application lifecycle—from code to cluster. It enables your team to define Kubernetes configuration policies to ensure consistent, secure, and compliant application deployments every time. In addition to policy enforcement, Monokle’s ecosystem of tools make your team’s daily YAML configuration workflows easier. Get started with Monokle for free.