Make it easier for users to correlate an application to specific pod(s) in the cluster

[Starttoaster]

Is your feature request related to a problem? Please describe.
Kubernetes operators (the humans that maintain the cluster) tend to see applications deployed to a kubernetes cluster as a list of Pods, Deployments, Helm releases, etc. Currently the UI lists Resource Names in the Application tab that seem to either correlate to an app or name label on the pod, or falls back to the image tag in the absence of those. I can't go anywhere to see the actual pod name, so I either need the context to infer it from the information currently provided, or figure it out manually with kubectl.

Describe the solution you'd like
When you click on an Application in the table, you get a nice summary of the pod labels associated with that application. Just add another area in the UI there that provides a list of pod names.

Describe alternatives you've considered
Another option, and would perhaps be interesting to do as well as the solution I mentioned above, is to have a table very similar to the Applications tab that uses pod name as the primary key instead of application name. In the event that multiple pods are identical, such as pods owned by a ReplicaSet, it lists all identical pods as one row.

Additional context
N/A

[Zaunei]

The way the application name is determined is also very suboptimal for my use case. Kubeclarity simply tries to derive an application name from commonly used labels, and if the labels are not used, the pod name is used. This also leads to the fact that if different stages are mapped with different namespaces, but the app.kubernetes.io/name labels in these deployments are identical, Kubeclarity will package them all into one application. The result is that the environments are no longer distinguishable in Kubeclarity.

In this case, I would find it very handy to have a special, optional label that defines the name of the Kubeclarity application. Would this be something for which a pull request would be accepted?

[Starttoaster]

The way the application name is determined is also very suboptimal for my use case. Kubeclarity simply tries to derive an application name from commonly used labels, and if the labels are not used, the pod name is used. This also leads to the fact that if different stages are mapped with different namespaces, but the app.kubernetes.io/name labels in these deployments are identical, Kubeclarity will package them all into one application. The result is that the environments are no longer distinguishable in Kubeclarity.

In this case, I would find it very handy to have a special, optional label that defines the name of the Kubeclarity application. Would this be something for which a pull request would be accepted?

If you look at Openclarity's project kanban board it kind of looks like they've abandoned this project entirely in favor of a different one "vmclarity" which obviously doesn't really relate to kubernetes at all so I'm starting to think a fork is more in order, in lieu of maintainers looking for contributions or feedback, personally. I've been thinking of doing just this but I am a bit hesitant to add yet another side project to fill the gaps in my personal time.

[Tehsmash]

If you look at Openclarity's project kanban board it kind of looks like they've abandoned this project entirely in favor of a different one "vmclarity" which obviously doesn't really relate to kubernetes at all so I'm starting to think a fork is more in order, in lieu of maintainers looking for contributions or feedback, personally. I've been thinking of doing just this but I am a bit hesitant to add yet another side project to fill the gaps in my personal time.

I think perhaps this hasn't been well communicated but we're in a transition period. KubeClarity/VMClarity are merging together and becoming a unified platform under the OpenClarity brand.

The VMClarity infrastructure was more mature (better separation of concerns, pluggable, more supported scanners, finding history) so we're focusing the development on that as the underlying infrastructure for the unified platform. New features will be developed on top of that infrastructure.

We already have a Kubernetes driver and installer for VMClarity, please take a look, it even supports scanning running containers not just images as KubeClarity does. We have a ticket in the board to provide a migration script for existing KubeClarity users once we're happy that the new platform is stable enough for folks to migrate.

Regarding this ticket, the data model in VMClarity is a bit different from KubeClarity, we capture much more information about the discovered Assets (there is asset discovery in VMClarity without running a scan) and provide a robust user facing query language to let you search through discovered assets to find the ones you care about and select a sub-set of them for scanning.

[Starttoaster]

I think perhaps this hasn't been well communicated but we're in a transition period. KubeClarity/VMClarity are merging together and becoming a unified platform under the OpenClarity brand.

A notice about this in kubeclarity's README might make this a bit more obvious? Simply by looking at the names, I deduced that these were two completely different products and you're correct that there was seemingly nothing signaling to me that I was wrong. But this is excellent news, and thank you for commenting here!

[ramizpolic]

Thanks for reporting @Starttoaster, I captured the issue and will add the necessary details for future KubeClarity users. In the meantime, feel free to create this issue it in the VMClarity repo if the existing Kubernetes functionalities are insufficient for your use case.

[grieshaber]

Hi @ramizpolic - I'm still missing the information about kubeclaritys future in the readme. I just found this issue and the info "by accident" after wondering why that repo is so inactive..

[ramizpolic]

We are actively working on the migration efforts and will provide all the details in the upcoming weeks @grieshaber. Stay tuned in the Project discussion board where we will make the announcement.