Cannot add new controls that uses previously unknown objects to Kubescape

[slashben]

Description

This issue is an umbrella ticket for an operational problem that exists between Kubescape and the Regolibrary.

I am using this to describe the problem and track the workaround between multiple components. The reason why it is under this repo since Regolibrary cannot evolve without solving this issue.

Issue

A problem was introduced in Kubescape code in the past year when it went through refactoring.

Kubescape scan process was divided into two phases:

1. Collecting objects to be tested
2. Running actual rego tests over the collected objects

Rules in Regolibrary declare in their metadata on what Kubernetes API objects they operate. Kubescape collects the list of rules it needs to run in a scan and builds a list of objects it needs to collect for the above no. 1 phase. After this it collects these objects and goes into phase 2.

Due to the aforementioned problem, if Kubescape failed to collect a single object in phase 1 it did not continue to phase 2 and the whole scan failed. Due to how Kubescape'a ClusterRole is built, it specifically defines access to the object Kubescape needs access as opposed to * access. This means every time we wanted to add or change a Rule to use a previously unused object we needed to update the ClusterRole of Kubescape. But due to the fact of this issue, even if we updated the ClusterRole in a new Helm release the old Kubescape deployments who download the latest Regolibrary release started to crash.

Since Regolibrary releases are completely orthogonal to Kubescape, this is a big forward compatibility problem.

[slashben]

This is the PR that solves the forward compatibility issues in Kubescape:
kubescape/kubescape#1578