Open Policy Agent support?

[spacedub]

Hi,

Recently started looking into OPA, and was wondering if it would make sense to integrate with ghost (likely using their go sdk: https://www.openpolicyagent.org/docs/latest/integration/#integrating-with-the-go-api)

Before spending more time on this, I thought I would ask here:

• if this is something that has been considered already
• if this is something desirable for this project

Thanks!

[csstaub]

I'm a big fan of OPA, I think this would be neat. I'm not entirely sure what the best way to integrate it would be though -- e.g. would we want to talk to an external server or use the runtime in-process to evaluate policies for example.

[spacedub]

I was thinking in-process, but then this is early for me - I just started looking into this.

You guys have a discord for ghostunnel?

[csstaub]

There's no discord, but happy to talk on here if you want to sketch something out.

[spacedub]

Cool!
I will likely start looking seriously into this later this month, and will get back here with more crisp ideas / a plan.

Unrelated/related: I sent you a note on linkedin - as we are using ghostunnel for our stuff, we are interested in supporting the project - so, if this would be useful too, let me know over there?

Thanks in all cases and ttyl!

[csstaub]

Thanks @spacedub!

I think there's basically two approaches:

• Provide a policy to Ghostunnel at startup. We load the policy using the OPA runtime library and execute it in-process, this yields lower latency (no context switch) but less flexibility.
• We let Ghostunnel talk to the OPA REST API (specifically the Query API). This is a bit more flexible, you can reload policies, change it on the fly, etc. by restarting your OPA server. But it adds extra latency and context switching.

[spacedub]

Ok, I have a small POC for the in-process approach that does verify the CN of a client cert.

I have this policy defined in a local rego file:

package mtls.authz

import input.identity

default allow := false

allow {
	input.client.Subject.CommonName == "spacedub (104954251)"
}

I am obviously hooking-up on TLSConfig.VerifyPeerCertificate to map the client certificate to the input (a la VerifyPeerCertificateServer in auth.go).

From a command-line perspective, I am passing along the policy and the query:
--policy opa-policy-tls.pol --query "data.mtls.authz.allow"

The key question IMO: what UX do we want?
Also, I am very new to OPA - just correct me if I am going in the wrong direction.

So, what about this:

ghostunnel --allow-policy policyfile.rego --allow-query "some query"

• that would be mutually exclusive with the other allow flags
• would still hook-up at the same level as the other allow flags (in auth.go)

Thoughts?

[csstaub]

Left some comments on the pull request, overall I think this is the right direction and looks pretty good already.