Open policy agent - explicit logical AND in CI pipeline - eval

Question

I am trying to write a policy which governs administrator username compatibility, which consists of three rules: alphanumeric value, not part of disallowed names (admin, administrator etc.), and longer than 5 characters.
I have found that when using OPA as part of a CI pipeline (which is my use case), the most comfortable solution is to create an object (dictionary) which contains policy results so that I can query them directly. My line inside the CI pipeline will look like this:
for file in rego_directory:
opa eval -i file -d data.json "package_name.policy"
Which doesn't print all of the variables and temporary resources I use inside the rego file (which saves a lot of logs and outputs). In order to make this "policy" object, I have inside my rego file the following pattern:
policy[policy_name] = result {
policy_name :=
...
computations...
...
result := <logical condition>
}
Now, my questions are as following: This doesn't seem like a best practice to me. Is there another way to simply omit the variables from the output? previously I've worked with separate values (i.e. something like this:
default policy_1 = false
default policy_2 = false
policy_1 = {
<logical condition>
}
policy_2 = {
<logical condition>
}
Second question: How do I create an output dictionary (since JSON output of a dictionary is a nice format to work with, after all) which can satisfy multiple conditions? looking back at my example, I can't write something like this:
policy[policy_name] = result {
policy_name :=
...
computations...
...
result := <logical condition>
result := <logical condition 2>
}
Since this is double assignment, which is invalid. Even if I use = instead of :=, it creates conflicts if one term is true and the other is false, and errors are not what I'm looking for (I need boolean answers). How do I create a complex rule whose output I can put inside this dictionary?
Thanks in advance.

Answer 1

TLDR; to answer your questions explicitly:
Now, my questions are as following: This doesn't seem like a best practice to me. Is there another way to simply omit the variables from the output?
There's nothing wrong with having your software query for the value generated by some rule. In fact, rules are the fundamental way of defining abstractions in your policies so that you can decouple policy decision-making (i.e., the logic that produces the decision) from policy enforcement (i.e., the logic/actions taken based on the policy decision.)
The only real alternative is to query for a set of rules inside one or more packages like you showed.
Second question: How do I create an output dictionary (since JSON output of a dictionary is a nice format to work with, after all) which can satisfy multiple conditions? looking back at my example, I can't write something like this:
You're asking how to express Logical OR. In this case, you would create multiple definitions (we call them "incremental definitions" in some places) of the policy rule:
policy[policy_name] = result {
policy_name :=
...
computations...
...
result := <logical condition>
}
policy[policy_name2] = result2 {
policy_name2 :=
...
some other computations...
...
result2 := <some other logical condition>
}
This snippet defines an object (named policy) that maps policy_name to result and policy_name2 to result2. We call this kind of rule a Partial Object. You can also define Partial Sets. When you define a Partial Object, you need to ensure that each key maps to at-most-one value (otherwise you'll get a runtime error.)
Another way of structuring your policy would be to (essentially) define a deny-list using partial sets:
package usernames
deny["username must use alphanumeric characters"] {
re_match("[a-zA-Z0-9]", input.username)
}
deny["username must be at least 5 characters long"] {
count(input.username) < 5
}
deny["username is reserved"] {
reserved_usernames[input.username]
}
reserved_usernames := {"admin", "root"}
Then your CI pipeline can simply query for deny:
opa eval -i input.json 'data.usernames.deny'
The result will contain reasons why the username should not be allowed.