Skip to content

Investigate approaches to scriptable agent behaviors

Spinning out of discussion from #92 (closed) beginning roughly at #92 (comment 513201617).

Towards the beginning of the discussion in #92 (closed) (which was itself spun out from the thread in !252 (comment 500660303)) it was generally agreed upon that as we implement conventional/default behaviours in the agent that we want to do so in a way that remains flexible, can be disabled, and can be reimplemented for arbitrary bespoke configurations.

Along those lines, the first use-case that pops up is applying and enforcing usage of conventional labels. This is the sort of behaviour that would be easy to toggle on/off, but more difficult to configure or change. This is a relatively trivial example, but as we continue adding functionality it will probably end up being much easier to provide users with a solution that is scriptable rather than us having to think about robust agent configuration options for every scenario.

My original suggestion here was to consider using OPA's rego scripting language (see #92 (comment 513201617)):

What I think would make more sense is having the agent leverage the OPA/rego Go API. My thinking was that the existing agent deployment would remain standalone and responsible for everything it does now plus these webhooks. We would simply implement the webhooks using default rego scripts that come bundled with the agent. The potential value of OPA/rego would be allowing users to override default agent behaviour with rego scripts managed as code in their agent config project.

@ash2k also brought up Starlark as another option (see #92 (comment 514773097)):

p.s. in addition to rego we can consider Starlark. FWIW it has a smaller set of dependencies and is designed to only allow deterministic programs (which is critically important in our case).

Yea that is certainly a good option as well. I think the important things to consider would be that the programs people write:

  1. can be easily managed as code in the agent config/manifest project without extra steps like compilation
  2. are easily and independently testable without running or fully configuring kas/agentk

Both would fit that bill nicely although I'm not sure I agree that determinism should be a hard requirement. Many interesting behaviours I envision us implementing would not be deterministic, for example: calling the GitLab API in the context of the project that is creating the resource to ensure the image passed a clean vulnerability scan.

Finally, the conclusion seemed to be that we should perhaps integrate with a full-blown OPA deployment rather than going with the embedded approach (see #92 (comment 515714438)):

I was just trying to say that if we wanted to go with a scripting based approach to implementing the labels and their enforcement (original scope of the issue) it would be a good idea because there is potential to enable all sorts of other nice behaviors (both built-in and user-defined) that way.

We discussed this with @nagyv-gitlab and it can be interesting indeed, however as a separate feature (optional OPA integration?). I wonder if there is a way to provide data/facts to OPA and let users use a vanilla OPA webhook if they need/prefer that. Would be great to hear your thoughts on what we could do. Could you create an issue for this - it'd be better to have a separate discussion.