We’ve got a pretty great resource for people getting started with rego, originally posted . Sharing here as well in-case it helps anyone. here uses the (OPA) as the decision engine for evaluating authorization decisions. is the policy language for defining rules that are evaluated by the OPA engine. Aserto Open Policy Agent Rego For engineers that are used to imperative languages like Javascript or Python, Rego can look a bit foreign. In this post, we give a few tips for how to get started with reading and writing Rego policies. More like SQL than like a programming language Rego isn’t a language for writing arbitrary programs. Rather, it’s a declarative language for defining rules - and can be thought of in the same way you think of a query language (like SQL). For all you language geeks, Rego is based on (a subset of Prolog), and contains some simplifying assumptions that make it easier to learn, easier to implement an evaluator for, and faster to execute. Turing-complete Datalog Packages are namespaces package aserto.InviteUser Every Rego file is in a . This defines the scope for the policy. Policy files that use the same package name are in the same namespace. package Decisions The result of a policy evaluation is a set of named decisions and their values. Each decision is a header in a block. For example, allowed { true } returns for the decision. true allowed Input documents The inputs to a policy are all keyed in an variable. Aserto automatically maps to the properties of the user in the context of which the policy is evaluated, and to the resource that is passed in as an optional resource context. input input.user input.resource Using values from the input document in the policy In the policy below, returns only if the attribute on the input map is equal to the string . allowed true foo "bar" allowed { input.foo == "bar" } Multiple decision outputs You can have more than one named decision in a policy. For example, in the policy below, there are two decisions ( and ), and enabled takes the value of . allowed enabled allowed allowed { input.foo == "bar" } enabled { allowed } Expressions inside a decision block are “AND-ed” together In the policy below, both conditions must be for the allowed decision to evaluate to . true true allowed { input.foo == "bar" input.bar == "baz" } Note that the conditions can be listed in any order - Rego doesn’t care about order when it comes to evaluation. Blocks with the same name are “OR-ed” together In the policy below, is if is , OR if is . allowed true foo "bar" bar "baz" allowed { input.foo == "bar" } allowed { input.bar == "baz" } Data documents You can embed a data document named in a Rego policy. This document is namespaced based on the directory it is in. For example, will show up as an object called in the policy evaluation context. data.json roles/data.json data.roles With the document below, : mydata/data.json { "hello": "world" } You could write a policy that accesses it in the following way: allowed { input.hello == data.mydata.hello } The decision would evaluate to if was equal to . allowed true input.hello "world" Expressions over arrays Rego has set operators that make it easy to construct expressions over each value in an array. For example, if is an array that can contain one or more roles, the following policy will return for the decision if any of the roles in the array is equal to : input.user.roles true allowed "viewer" allowed { some i input.user.roles[i] == "viewer" } Note that writing an expression over an array means iterating over every value of that array - a bit like a database table scan. That’s why at Aserto we prefer Rego objects over arrays, since indexing into an object using a key is a constant-time operation. Summary Rego is an expressive policy language that can be used to construct a wide variety of RBAC and ABAC-style policies. We’ve gone through the most common patterns to get you started on writing authorization policies in Rego. Happy hacking! Also Published Here