[Issue - 10441] Improved k8s cluster discovery

[Chichichkin]

🚀 Overview

Addressing the issue 👉 #10441

🎯 User-facing change?

✅ The new way of building the platform IDs relies solely on the namespaces now.

⚠️ Risk Assessment: what can go wrong?

🟢 n/a

[github-actions]

Thank you for your submission. We really appreciate it. Before we can accept your contribution, we ask that you sign the Mondoo Contributor License Agreement. You can sign the CLA by adding a new comment to this pull request and pasting exactly the following text.

---

I have read the Mondoo CLA Document and I hereby sign the CLA

---

1 out of 2 committers have signed the CLA.
✅ (imilchev)[https://github.com/imilchev]
❌ @Chichichkin
_{You can retrigger this bot by commenting recheck in this Pull Request. Posted by the CLA Assistant Lite bot.}

[imilchev]

we need to hold off merging this PR. I believe this change conflicts with how we build platformids when scanning manifests. I need to take a look how to set this up such that it works for both manifests and clusters

[github-actions]

Test Results

3 478 tests  ±0   3 474 ✅ ±0   1m 41s ⏱️ -10s
  392 suites ±0       4 💤 ±0 
   30 files   ±0       0 ❌ ±0 

Results for commit 865da99. ± Comparison against base commit bb2d4a9.

[imilchev]

This PR makes sure we have more stable platform IDs for k8s assets. With the previous implementation different platform IDs were generating for all workloads depending whether the scan would discover the cluster asset or not.

With this change the platform ids should always be the same:

When scanning a cluster: <-- this is different from the current implementation

• cluster asset has it's own platform ID, which is based on the kube-system namespace UID //platformid.api.mondoo.app/runtime/k8s/uid/1bda2ae0-27fe-49ed-90fd-39d3bb8da955
• workload IDs have platform IDs based on the parent namespace's UID //platformid.api.mondoo.app/runtime/k8s/uid/ee1df06e-55c1-4ce3-b0a7-820efed0417a/namespace/default/pods/name/nginx

When scanning manifests: <-- this has not changed

• manifest asset has it's own platform ID based on the path hash for the manifest/directory //platformid.api.mondoo.app/runtime/k8s/uid/ed37af0ce97030c84a07fb9d3311841f5f180a77573c664da6fbe3d8dc481896
• workload IDs have platform IDs based on the manifest/directory path //platformid.api.mondoo.app/runtime/k8s/uid/ed37af0ce97030c84a07fb9d3311841f5f180a77573c664da6fbe3d8dc481896/namespace/mondoo-operator/deployments/name/mondoo-operator-controller-manager

[czunker]

I can currently only think of two one cases where this might not work:

• The user has no privileges to access kube-system. Are we still able to get the uuid from the namespace list?

Did I read this correctly, that we do not discover the cluster when a namespace filter is set?

[czunker]

According to the comments in this PR, the manifest part didn't change. Why did this increase?

[imilchev]

we discover the namespaces now. Before we skipped over them which was actually a bug. We turned on namespace discovery for api scans, but not for manifests