[operator] Integrate kube-hunter scanner

[krol3]

@danielpacak what will be the steps? - Adding a kubehunterReport in pkg/operator/controller/ ?

[danielpacak]

Before we get into implementation we should identify:

• [ ] What problems are we solving by integrating KubeHunter?
• [ ] What is the lifecycle of a KubeHunterReport CR?
• [ ] Isn't the CLI integration enough?
• [ ] How often do we scan / rescan?
• [ ] Any other considerations?

Based on the initial evaluation we should be able to decide whether a K8s controller patter is suitable for the integration or not. If yes, then which K8s API object we want to watch?

[krol3]

@danielpacak great points! Following the starboard documentation, if we choose to install using operator, we don't have the option of kube-hunter, the lifecycle will be the same as kube-bench. Both tools need to use in the case of new or update cluster processes. If these assumptions are correct, are kube-bench and kube-hunter a good case for operator use?

[danielpacak]

IMHO there's a difference between KubeBench and KubeHunter:

• Starboard operator discovers K8s nodes and runs a KubeBench on each node (using node selector), which automatically detects applicable CIS benchmark checks (control plane vs worker node checks). Each CISKubeBenchReport has the same lifecycle as the corresponding K8s node, therefore each report is controlled by the K8s node. This works well for new installation as well as cluster updates (e.g. add, update, delete node).
• When it comes to KubeHunter Starboard CLI can run it as a Pod without targeting any particular K8s node. Since there's no K8s resource that represents a whole K8s cluster the KubeHunterReport created by the CLI has no owner - there's only once instance named cluster. Not having a native K8s resource that we can watch to trigger KubeHunter scans is the main challenge here.