FeatureRequest: remote write to another instance

[jmueller42]

We have a lot of k8s clusters, which means we have a separate kubeclarity instance per cluster, which does scheduled scanning.

It would be nice if each of these kubeclarity instances could push its results to a central kubeclarity instance, such that one could review the results of all clusters in one place. This feature could be like the remote write feature that prometheus offers.

[github-actions]

Thank you for your contribution! This issue has been automatically marked as stale because it has no recent activity in the last 60 days. It will be closed in 14 days, if no further activity occurs. If this issue is still relevant, please leave a comment to let us know, and the stale label will be automatically removed.

[github-actions]

This issue has been marked stale for 14 days, and is now closed due to inactivity. If the issue is still relevant, please re-open this issue or file a new one. Thank you!

[akpsgit]

Hi @jmueller42, thanks a lot for the feature request. We are planning to support this feature by a big change in KubeClarity very soon. The idea is to replace the scanner and the scan orchestrator logic by the much more advanced and scaleable capabilities that are under development in VMClarity. This will be addressed in the following features:
openclarity/vmclarity#353
openclarity/vmclarity#558

Once completed, we'll move into switching the infra of KubeClarity to VMClarity.
Would love to hear your thoughts on it.
Thanks!

[jmueller42]

Hi @akpsgit ,

thank you for the information.

I think it would be better to have an agent based approach, especially in the kubernetes environment.
So discovering the vulnerabilites can be centralized, but the creation of the SBOM should be done inside the clusters. So some sort of agent should reside in the cluster, such that SBOM generation is done inside the cluster. This has the security advantage, that the credentials needed to pull the container images (image pull secrets) never leave the cluster and only the SBOM needs to be transferred to the central instance, which then can compare the SBOM to different sources of CVE vulnerabilites.
What I like about this centralized approach is the possibility to handle CVEs centrally, which will save a lot of manual work, when evaluating the found CVEs and planning corresponding measures.

[akpsgit]

@jmueller42 exactly! There will be a component ("agent" ) in the runtime environment that will analyze the content (e.g. SBOM) that will use image pull secrets, take container snapshots etc. This is the data-plane scanner that will have the privileges to do it only within the env, for the reasons you mentioned.
For the example of CVEs for an image, we don't even need to scan it again, as the SBOM of images is fixed, we can just correlate it for newly discovered vulnerabilities in the centralized control-plane.

[jmueller42]

@akpsgit That sounds great.
Is there a timeline when this will be available?

[github-actions]

Thank you for your contribution! This issue has been automatically marked as stale because it has no recent activity in the last 60 days. It will be closed in 14 days, if no further activity occurs. If this issue is still relevant, please leave a comment to let us know, and the stale label will be automatically removed.

[github-actions]

This issue has been marked stale for 14 days, and is now closed due to inactivity. If the issue is still relevant, please re-open this issue or file a new one. Thank you!

[akpsgit]

Hi @jmueller42, sorry for the late response. The K8s scanning capabilities are under final review now in VMClarity in:
openclarity/vmclarity#864
openclarity/vmclarity#711
@chrisgacsal, @lgecse, do you know when it is expected to be merged? Also, what is the timeline for the VMClarity & KubeClarity merge?

[jmueller42]

@akpsgit Thank you.
I will check out vmclarity when this is merged.