Helm charts for Open Policy Agent

[tsandall]

On the OPA biweekly meeting today @eshepelyuk brought up the need for a Helm chart that creates an OPA deployment on the cluster to expose it as a service for other K8s apps to consume. We currently have a Helm chart in the kube-mgmt repo that has primarily been used to deploy openpolicyagent/opa along with the kube-mgmt sidecar as an admission controller. Similarly, we have a Helm chart for Gatekeeper as well.

I'd like to figure out if it would make sense to create a new top-level "charts" repo that could house the various charts that are useful to OPA users. The first three candidate charts would be:

• K8s Admission Control with OPA + kube-mgmt
• K8s Admission Control w/ OPA Gatekeeper
• Generic OPA deployment for application use cases

Additionally, we could look at creating charts that deploy multiple OPAs for multiple use cases. Ideally that would compose these individual charts.

The devil is details here but a few things to understand:

• Would one repo with multiple charts play nicely with Helm tooling? We should adhere to Helm idioms.
• How would release automation work? E.g., ideally when we cut vX.Y.Z of OPA the dependent charts (or just values.yaml files) get updated.
• How would we distribute the charts? @eshepelyuk has suggested using GitHub Packages over in #8.

I'm probably missing a few things.

cc @ritazh @phisco @eshepelyuk if you folks can weigh in, that would be super helpful.

[eshepelyuk]

Some thoughts

1. A new repository for Helm chart / Helm charts source code is mandatory IMO. The chart(s) is a separate project that has own versioning and release lifecycle. So, even moving out current chart from kube-mgmt repo is a great step forward.
2. One repo with multiple charts is absolutely fine, check out Bitnami repo hosting dozens of charts.
3. Release automation will require update of particular component version (e.g. OPA, Gatekeeper etc) in particular chart. As you may check in my PR to kube-mgmt, as soon as new versions will be commited, the new release of a Chart maybe triggered either automatically or manually by kicking of certain GH action. Manual release trigger is preferable IMO, since we may want to combine multiple features inside a single release.
4. About multiple charts, as I already mentioned - I consider that OPA should have only a single chart with multiple parameters that can enable / disable certain components. The one of main reasons for such desing is the fact that OPA components are closely coupled with each other ( i.e. Adminssion need OPA server, kube-mgmt needs OPA server etc). When components reside in a single chart - it is extremely easy to automatically generate links to k8s service names for communicating between component. This will improve general customer experience, since users won't need to provide a links to OPA server manually, instead chart will generate them.

[eshepelyuk]

I had taken a took at gatekeeper chart and it looks like it is quite complicated to be joined together with what currently exists in kube-mgmt.

So, maybe it worth to create a new repo helm-charts and move there 2 existing charts

• Gatekeeper
• OPA ( opa + optional kube mgmt + optional admission controller)
  But, both charts should have own release cycle, version management, i.e. be independent of each other.

[mnmami]

It's intriguing four years later this is still open. +1 for this.

[anderseknert]

That's 4 years without a single member from the community showing up to support the idea — or offer to help.
Which is intriguing in its own right, I suppose :) If you or anyone else would want to work on this, I'm happy to support you with whatever you might need.

[eshepelyuk]

kube-mgmt does everything that was missing previously to deploy OPA as generic API service. for the admission controller - gatekeeper exists.
This can be closed.