Falco: Consider OPA Rego

[kris-nova]

Motivation

We know there are several concerns with encapsulating rules in Lua, and even more concerns at runtime with how the Lua libraries perform internally to the Falco engine.

In the name of exploring other options, and driving adoption and integration with Falco - should we explore using Rego as a rule encapsulation mechanism with Falco?

Feature

One to one parity with the current rule parsing library.
One to one parity with the current rule set.
All of this, but somehow with Rego.

Alternatives

Additional context

Please read this thread that I had with the OPA folks discussions options and examples we could use here.

https://openpolicyagent.slack.com/archives/C1H19LW4F/p1590629073247900

[fntlnz]

The fact that the parser we use is written in lua is a separate problem than using a completely different language.

In fact, we can rewrite the parser in C++ and use the same language. In that way we remove lua and still offer the same experience to our users.

For this reason, I'm a no on this. I don't think that rego fits our use case better than our rules language and I would dedicate the time and effort required to switch to rego to improve what we have instead.

[kris-nova]

So I agree that Lua is another concern and out of scope for this issue -- which is why I changed the name. This is NOT suggesting that we replace Lua, but rather that we consider Rego for rules SOMEHOW.

After a few hours of reading about Rego/trying it out/trying to understand it - I can safely say that I do not enjoy using it, and most of the conventions are unnatural.

Bottom line, there is a high barrier to entry for adopting the language.

However, there seems to be traction and adoption of Rego so the same could be said if someone is going in the opposite direction and learned Rego first. They could have the same concerns while learning the Falco rules conventions after starting with Rego.

It might be wise to consider a translation method from going bi-directionally from Lua to Rego. Which is where this issue came from.

---

As a Kubernetes administrator, I would potentially want to prevent, alert, or allow things in my cluster. Let's take running a privileged container as a classic example.

You can see pod security policy and gatekeeper and even admissions controllers are viable options to PREVENT this behavior.

You can see that falco is a way to DETECT this behavior.

As a Kubernetes administrator, I would like an easy way to control these various components for my different use cases.

(This following is important)

In the following example, we could use Rego to control Falco, as well as other tools. The implementation of how we translate the following into Falco or Lua or whatever future rules-language might exist for Falco is implementation detail. It's an exercise similar to this one in for PSPs.

---

privileged=prevent

This controls Falco, and Gatekeeper from the same place.

input

{
   "cluster": "my-secure-cluster",
   "privileged": "prevent"
}

output

{
   "falco": 
      {
          "rules": [ "detect_privileged" ]
      },
   "gatekeeper": 
      {
          "rules": [ "prevent_privileged" ]
      }
}

Note that the gatekeeper implementation work is already done, but the overall story from an administrative experience is much more compelling.

---

privileged=detect

This only controls Falco, as Gatekeeper is not relevant anymore.

input

{
   "cluster": "my-secure-cluster",
   "privileged": "detect"
}

output

{
   "falco": 
      {
          "rules": [ "detect_privileged" ]
      }
}

---

privileged=allow

This does nothing. Everything is open. No tools need to be changed.

input

{
   "cluster": "my-secure-cluster",
   "privileged": "allow"
}

output

{
}

---

As the OPA and Kubernetes community progress, I am assuming that policy like the one outlined above, despite being confusing at first, will be considered the norm.

If Falco can capitalize on integrating with these types of rules we could potentially spare the maintainers' work in the long run from having to support alternatives in our community. We could also take advantage of existing tooling like Envoy has done here.

TLDR; I believe people will begin using Rego more and more in the future. If we can figure out a way to get the Falco runtime to respect Rego policy we are directly contributing to the goal of driving adoption. How it happens - is a different discussion - but it still believe it should be considered nevertheless.

---

This is just one of many examples. I really believe if an administrator was defining global policy for a system they would be more likely to try Falco if it was an exercise of copy/pasting easy to understand policy in their existing workflow than re-learning another policy or rules framework.

I think using rego as a "high level glue" for Falco could be an easy to way to start integrating with tools like:

• https://github.com/saschagrunert/seccomp-operator
• https://github.com/elastic/go-seccomp-bpf
• https://github.com/opencontainers/selinux
• https://github.com/open-policy-agent/gatekeeper
• https://github.com/open-policy-agent/opa-envoy-spire-ext-authz
• https://istio.io/docs/reference/config/policy-and-telemetry/adapters/opa/
• https://www.solo.io/blog/5-min-with-gloo-api-gateway-configuration-with-open-policy-agent/

or probably the most important link -- all of these:

• https://www.openpolicyagent.org/docs/latest/ecosystem/

[airadier]

My 2 cents.

About rego, I hated it, but after fighting several hours with it for the Sysdig OPA image scanner, I must admit I don’t hate it that much now… Even I can appreciate some beauty on it, once you change your mindset.

I still prefer the simpler Falco rules syntax, but probably the declarative rego language can define much more complex rules, as it is more powerful. So the strength of Falco rules is simplicity, and the strength of rego is power, at the price of a steep learning curve, not trivial, and often frustrating. But, many of the things that I required for the image scanner rules wouldn't be possible with Falco syntax.

Usage of OPA Gatekeeper and rego is becoming more and more common, so it is worth considering.

I admit that I already thought about having a pluggable rule engine for Falco, so you could use rego instead of Falco syntax, and make the evaluation engine just one replaceable part. Does it make sense? For any evaluation engine, we would just evaluate a set of fields and conditions.

It might even make sense, maybe, to push Falco events to a cluster where OPA Gatekeeper is running, create some kind of CRD for the events, and use Gatekeeper and rego rules to detect non-compliances and get notified. But pushing all events to a cluster is not feasible, we need to trigger the ones matching a rule, so we are back to the rule engine inside Falco.

Just thinking aloud...

[kris-nova]

Related: https://github.com/falcosecurity/falco/issues/607

[omer-sd]

On top of Detect vs Prevent as Kris mentioned, while there is some overlap between the tools, Falco is still runtime behavior oriented vs config changes focused that I believe most folks are using OPA for.

For the overlapped use cases, we can implement the detect (falco) -> prevent (opa), but it won't be comprehensive without adding things like selinux and apparmor to complete the story, where OPA is just one piece of the puzzle.

[kris-nova]

Right, most folks hear OPA and think gatekeeper.

But regardless of the misnomer - OPA aims to be a policy standard - so as the usecases start to span multiple concepts and multiple tools - having a standard set of config would be useful in my mind.

[omer-sd]

Good point about OPA != Gatekeeper. I want to add that there is no good alternative for gatekeeper right now, which might explain the wide adoption.
So another approach to explore is having a Falco Admission Controller connector, and using the Falco language to address a broader set of use cases.

[kris-nova]

Honestly I have been dying to write an admissions controller for security purposes. The world needs this so bad. As far as I can tell Gatekeeper was just a port of pod security policy and doesn't do anything more than that. Which is where seccomp and selinux get exciting.

As far as the falco language itself is concerned - I have weak opinions - but regardless of gatekeeper vs a new admissions controller that still leaves us in the land of inventing our own language or using another project. We could be in the same place we are today even after building a "falco language compliant" admissions controller if another use case with an OPA integration walks up to the table.

---

Why not both? Why can't falco rules just be dynamic and have the engine agnostic? There is a reason -oyaml and -ojson exists right?

Why can't we just have an OPA library that translates Rego policy into Falco rules? We might not even have to write anything to disk if we make the rules endpoint for Falco dynamic such that a Go client can easily build structs in memory and pass them to/from the Falco engine over something like gRPC.

[patrick-east]

As far as I can tell Gatekeeper was just a port of pod security policy and doesn't do anything more than that.

Just to add a tiny bit more context on that point. The PSP policies shown in the gatekeeper library are just _one_ example of what you can do with it. I'd even go so far as to say they are simple policies to implement, and there is considerable room for users to write much more sophisticated checks.

That tangent aside.. I would agree that some sort of pluggable rule engine seems like it makes the most sense from a high level (aside from just using OPA as the default.. although I'm biased 😄 ). Being able to "offload" the decision making is a pretty nice feature, especially if the rules are in a standard format. That sort of thing is, IMO, a pretty big factor in making OPA so popular in many different use-cases throughout the CNCF ecosystem.

[dnwe]

Why can't we just have an OPA library that translates Rego policy into Falco rules

This would be excellent. As mentioned above, there's a lot of crossover between Falco rules for detecting/alerting and PSP / NetworkPolicy et al. for preventing. Currently to permit a new action we have to typically add the action in multiple disparate places. It would be great if we could instead have a high-level set of rego rules that could be used to apply the necessary falco+PSP+NetworkPolicy+OPA as appropriate to provide defense-in-depth.

The OPA rules would also be a one-stop shop for showing overall compliance rules

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. Issues labeled "cncf", "roadmap" and "help wanted" will not be automatically closed. Please refer to a maintainer to get such label added if you think this should be kept open.