Allow kwctl to interact with Rego policies that have been compiled to WebAssembly
Both OPA and Gatekeeper use Rego to express their policies. However the policies have to be written in different ways, because of how policy settings are handled by OPA and Gatekeeper.
OPA relies on the data dictionary to pass additional data to the policy, while Gatekeeper enriches the input dictionary. While it's easy to understand whether a Wasm policy has been generated by opa built -t wasm, there currently is no way to know if the a policy has been written for OPA or Gatekeeper.
To eliminate this ambiguity, we will rely on the user to kwctl annotate the Wasm policy to explain whether the policy was written for OPA or for Gatekeeper.
Aside from that, kwctl can easily identify Wasm modules that have been produced by opa (as opposed to say, a kubewarden policy). The identification can be done by looking at the following globals that are always defined inside of "rego-based" Wasm files: opa_wasm_abi_version, opa_wasm_abi_minor_version. These are documented here.
Admission criteria
Allow users to annotate a Wasm file produced by opa build to indicate whether this is targeting OPA or Gatekeeper
Extend kwctl inspect: tell the user the policy has been created by opa build, show whether the policy was meant to be used with OPA or Gatekeeper, show a warning message when this information is not available inside of the policy metadata
Extend kwctl push: refuse to push a "rego-based" policy that hasn't been annotated. The force option would have no effect with this policy because otherwise we would never know how to evaluate the policy at runtime.
kwct run: ensure both kubewarden and "rego-based" policies can be evaluated. The user can populate the data dictionary using the settings feature of kubewarden
Allow kwctl to interact with Rego policies that have been compiled to WebAssembly
Both OPA and Gatekeeper use Rego to express their policies. However the policies have to be written in different ways, because of how policy settings are handled by OPA and Gatekeeper.
OPA relies on the
data
dictionary to pass additional data to the policy, while Gatekeeper enriches theinput
dictionary. While it's easy to understand whether a Wasm policy has been generated byopa built -t wasm
, there currently is no way to know if the a policy has been written for OPA or Gatekeeper.To eliminate this ambiguity, we will rely on the user to
kwctl annotate
the Wasm policy to explain whether the policy was written for OPA or for Gatekeeper.Aside from that,
kwctl
can easily identify Wasm modules that have been produced by opa (as opposed to say, a kubewarden policy). The identification can be done by looking at the following globals that are always defined inside of "rego-based" Wasm files:opa_wasm_abi_version
,opa_wasm_abi_minor_version
. These are documented here.Admission criteria
opa build
to indicate whether this is targeting OPA or Gatekeeperkwctl inspect
: tell the user the policy has been created byopa build
, show whether the policy was meant to be used with OPA or Gatekeeper, show a warning message when this information is not available inside of the policy metadatakwctl push
: refuse to push a "rego-based" policy that hasn't been annotated. Theforce
option would have no effect with this policy because otherwise we would never know how to evaluate the policy at runtime.kwct run
: ensure both kubewarden and "rego-based" policies can be evaluated. The user can populate thedata
dictionary using thesettings
feature of kubewardenPart of https://github.com/kubewarden/policy-evaluator/issues/14