Why is the exact difference between "violation" and "deny" in OPA/Rego?

Question

In Open Policy Agent (https://www.openpolicyagent.org/)

regarding to Kubernetes, depending which engine is used:

• Gatekeeper: https://github.com/open-policy-agent/gatekeeper

OR

• Plain OPA with kube-mgmt: https://www.openpolicyagent.org/docs/latest/kubernetes-introduction/#how-does-it-work-with-plain-opa-and-kube-mgmt

There are different ways to define validation rules:

• In Gatekeeper the violation is used. See sample rules here: https://github.com/open-policy-agent/gatekeeper-library/tree/master/library/general

• In plain OPA samples, the deny rule, see sample here: https://www.openpolicyagent.org/docs/latest/kubernetes-introduction/#how-does-it-work-with-plain-opa-and-kube-mgmt

It seems to be the OPA constraint framework defines it as violation: https://github.com/open-policy-agent/frameworks/tree/master/constraint#rule-schema

So what is the exact "story" behind this, why it is not consistent between the different engines?

Notes:

• This doc reflects on this: https://www.openshift.com/blog/better-kubernetes-security-with-open-policy-agent-opa-part-2

• Here is mentioned how to support interoperability in the script: https://github.com/open-policy-agent/gatekeeper/issues/1168#issuecomment-794759747

• https://github.com/open-policy-agent/gatekeeper/issues/168 In this issue is the migration mentioned, is just because of "dry run" support?.

Answer 1

Plain OPA has no opinion on how you choose to name your rules. Using deny is just a convention in the tutorial. The real Kubernetes admission review response is going to look something like this:

{
  "kind": "AdmissionReview",
  "apiVersion": "admission.k8s.io/v1beta1",
  "response": {
    "allowed": false,
    "status": {
      "reason": "container image refers to illegal registry (must be hooli.com)"
    }
  }
}

So whatever you choose to name your rules the response will need to be transformed into a response like the above before it's sent back to the Kubernetes API server. If you scroll down a bit in the Detailed Admission Control Flow section of the Kubernetes primer docs, you'll see how this transformation is accomplished in the system.main rule:

package system

import data.kubernetes.admission

main = {
  "apiVersion": "admission.k8s.io/v1beta1",
  "kind": "AdmissionReview",
  "response": response,
}

default response = {"allowed": true}

response = {
    "allowed": false,
    "status": {
        "reason": reason,
    },
} {
    reason = concat(", ", admission.deny)
    reason != ""
}

Note in particular how the "reason" attribute is just built by concatenating all the strings found in admission.deny:

reason = concat(", ", admission.deny)

If you'd rather use violation or some other rule name using plain OPA, this is where you would change it.