Adding logs on policy failure

[beepdot]

Hello there,

I would like to know if there are some ways we can add logs when a policy fails. For instance a simple rule like below

validate {
  # check something here
}

allow {
 validate
  # any way to print a message to console here if validate block fails like `validate failed`. I dont want to print anything on success
}

I read about print statements, but that would not do something like printing logs only in case of policy failure. The reason I am asking is to be able to identify why a request was rejected (in this case validate block failed).

Addding a snippet on what exactly I am looking for from another programming langurage -

if ! validate {
  console.log("validate failed")
}

Any ideas on how we can have such a functionality?

I have tried these -

validate {
  print("in validate)
  # check something
  # always prints irrespective of check passes or fails
}

validate {
  # check something here
   # prints only if check passes
  print("in validate)
}

[anderseknert]

The print function is included in OPA for debugging purposes only, and it should not be used as a "logger". Use decision logging if you want to log the decisions OPA takes, which includes the input of the request. If you want to drill down to where rule evaluation stopped in a debugging context, you could either look into tracing, or simply move the print event to the validate rule as you did in your last example. That'll give you the opportunity to at least derive where printing "stops" and what is likely the cause of evaluation to fail. In tests, the coverage feature could also be useful for determining what lines are evaluated and not.

Finally, a pretty common approach is to use partial rules that buid sets, for which you can provide a reason as to why the rule "failed" - i.e. why it was denied. Something like:

decision := {
    "allow": count(deny) == 0,
    "reason": concat(" | ", deny),
}

deny["User must be admin"] {
    not "admin" in input.user.roles
}

# more deny rules here

[beepdot]

Thanks a ton @anderseknert for the tip. Your code block has given me good insights. I am already using decision logging and test cases. Now combining them with some changes to rules to emit some message, like your example, does the job of printing why request was rejected in the logs.