enable opa-wasm

currently, the rego bundles are distributed using rego which runs in the rego interpreter, with this pr, I enable the wasm evaluation engine of opa which will allow opa to evaluate wasm based bundles which based on this blogpost it should give us a 10x performance boost.

the way to test it:

# policy.rego
package envoy.http.public

import rego.v1

default allow := false

allow if {
	input.attributes.request.http.method == "GET"
	input.attributes.request.http.path == "/"
}

allow if input.attributes.request.http.headers.authorization == "Basic charlie"

# opaconfig.yaml
bundles:
  play:
    resource: bundles/{{ .bundlename }}
    polling:
      long_polling_timeout_seconds: 45
services:
  - name: play
    url: http://127.0.0.1:8000 # your http server address
plugins:
  envoy_ext_authz_grpc:
    # This needs to match the package, defaulting to envoy/authz/allow
    path: envoy/http/public/allow
    dry-run: false
decision_logs:
  console: true

# compile policy to wasm

$ opa build -t wasm -O 3 -e envoy/http/public policy.rego # the entrypoint is the name of the package in the rego file

# prepare the http server to host the bundle
$ mkdir -p opa-server/bundles && mv bundle.tar.gz opa-server/bundles/play

# run python simple http in the directory
$ cd opa-server && python3 -m http.server

# run skipper

$ skipper -enable-open-policy-agent -open-policy-agent-config-template opaconfig.yaml -inline-routes 'notfound: * -> opaAuthorizeRequest("play") -> inlineContent("<h1>Authorized Hello</h1>") -> <shunt>'

please ignore the fuzzer compile errors for now, I will fix them later in another PR.

@szuecs / @AlexanderYastrebov PTAL

:+1:

@mjungsbluth FYI

Can you add performance tests to show the improvement?

Yes and no feature without a test and optimizations should have a benchmark.

@MustafaSaber I have asked our IAM guys to have a look and do some benchmarks and loadtests, the results will be posted here,

I need to highlight that this has no user impact as the opa plugin automatically detects if the bundle is rego or wasm and it will run them in the appropriate environment, so current user base will not be affected as both engines are supported in parallel.

It's a nice finding. In addition to the loadtests we have below points also to be considered.

1. Unsupported built-in functions - https://www.openpolicyagent.org/docs/latest/wasm/#current-status as for this it seems WASM is not supporting some built-in functions. Eventhough http.send is discouraged either way, not sure what else is missing.

2. Bundle building is handled by the OPA control plane. So far it doesn't seem to support building WASM bundles. Will need a separate approach to handle this, if taking this path.

Interesting experiment @sepehrdaddev , looking forward to the results!

As for local performance testing, you can add one benchmark to the existing local benchmarks here. I would however not expect a massive change as the WASM variant should play out its strengths for more complex policies but you should already see some numbers.

We'll need to see how this then plays out in total as this optimises the evaluation but leaves decision logging and input conversion as is. To see a flame graph with a minimal policy, look here

I need to highlight that this has no user impact..

This change still changes one of the core ingredients of the filter, the Compiler, so in a "been there, done that" sense I would recommend hiding the change of behaviour behind a flag to enable WASM support.

So then I would say add enable-open-policy-agent-wasm via config/config.go and pass it in skipper.go to OPA filter configurations