Add an optional external admission controller to Capsule Operator

[bsctl]

Describe the feature

Capsule implements its own set of Admission Controllers through the Dynamic Admission Controller, providing callbacks to add further validation or resource patching. Currently these admission controllers address only a fixed set of use cases.

As long term evolution for this project we can evaluate to make the admission controllers (both the mutating and validating flavours) programmable in order to cover more and more use cases.

A viable option would be to include a Policy Engine, eg. Open Policy Agent (OPA), as embedded library and provide a programmable interface in Rego, see https://www.openpolicyagent.org/docs/latest/integration/#integrating-with-the-go-api. Since this will create another dependancy we have evaluate with care this option.
Let's to see also feedbacks from community.

[prometherion]

I'm not entirely convinced by this feature proposal, since in the end would create a huge dependency on OPA.

Maybe would be worth providing a meta-example to get a clear view of the benefits of an OPA integration, although it could mean adding further points of failures (e.g. what happens if the OPA service is no reachable?)

[bsctl]

I'm not entirely convinced by this feature proposal, since in the end would create a huge dependency on OPA.

That's my biggest concern too.

The idea here (feasibility to be checked) is to embed OPA as Go library:

import "github.com/open-policy-agent/opa/rego"

so technically is a smooth dependancy.

Let's keep this proposal just as possible long term evolution of the project depending on the feedbacks from the adopters.

IMHO main benefits are:

* programmable admission interface, so a new feature can be directly implemented using the Rego language not requiring to recompile the binary.

* reusing of policies already developed in the OPA community

* more traction of the Capsule project since OPA is the "de-facto" standard for programmable admission controllers

[bsctl]

@prometherion @MaxFedotov

The new proposal here is to re-engine the Operator in order to have all the current Admission and Mutating Webhooks running as a separated pod from the main Capsule Controller pod. This will help to make the Admission Controller swappable with an external Policy Engine, eg. OPA or Kyverno.

We do not need to throw away our webooks, just give the people the choice to use Capsule internal Webhook or write their own.

We should seriously evaluate this proposal since often I get people asking for having Capsule and OPA/Gatekeeper working together.

[maxgio92]

Hi there, I've started working on this idea as discussed with @bsctl, considering the native Validating Admission Policy.

I've set up a sample policy that should mimic the Capsule policy for Ingress class here.

The whole repository comprises an end-to-end scenario setup.

At the current state, the policy highlights a syntax error when using a parameter in the CEL expression, even though should be correct as for the official documentation..

I'll keep you posted.