🐛 fix core asset.labels + ✨ new asset.platformMetadata

[afiune]

The labels of an asset come from the asset itself, not the platform, but as some point
we made a mistake to use the platform labels, this PR is the first step to fix this issue.

In this PR we are:

• Introducing a new field to the proto message asset.Platform.Metadata with the goal
  to give more clarity and avoid confusions with asset.Labels
• We are deprecating asset.Platform.Labels in favor of asset.Platform.Metadata (this field
  will be remove in v12)
• We are introducing a new asset.platformMetadata to the asset MQL schema, this
  new field will have the asset.Platform.Metadata
• We are fixing the asset.labels MQL resource to have the actual asset labels but, we are
  going to merge this field with the platform labels for backwards compatibility

After merging this PR, we will start migrating the use of asset.Platform.Labels to
asset.Platform.Metadata, so that in v12 we can remove `asset.Platform.Labels.

[github-actions]

Test Results

3 369 tests  +15   3 365 ✅ +15   1m 37s ⏱️ -7s
  392 suites + 1       4 💤 ± 0 
   30 files   ± 0       0 ❌ ± 0 

Results for commit 274f071. ± Comparison against base commit 03ab221.

♻️ This comment has been updated with latest results.

[arlimus]

Why did we use Platform.Labels before and what change does it make to switch to Asset.Labels? Are there different code paths that set these across different providers? I'm worried that with both fields existing we might run into similar problems again.

[chris-rock]

I do some extra testing but this is what I discussed with @afiune as a solution. It stuck me that we use asset.Annotations but not asset.Labels. I am 99% sure the labels from platform are actually incorrect.

[arlimus]

@chris-rock I asked @afiune to investigate the solution, so we make sure it doesn't break things. We shouldn't have both structures because it can lead to bugs like this one :)

[afiune]

Thank you both, I agree with @arlimus, if we don't use one, we should get rid of it.

I will do some digging and report back any findings.

[afiune]

@chris-rock @arlimus I found a few places where we are using asset.platform.labels, I can update the tests but I want to check with you both if this change is heading in the right direction, or not.

[chris-rock]

Asset labels and platform labels have two different purposes and are not the same. We introduced platform labels to allow platform detection to add dynamic data that is not part of the normal go struct eg. windows uses that

cnquery/providers/os/resources/asset_cpe.go

Lines 43 to 45 in 0162b01

	if conn.Asset().Platform.Labels["windows.mondoo.com/product-type"] == "1" {
	workstation = true
	}

and

cnquery/providers/os/detector/detector_win.go

Lines 45 to 46 in 0162b01

	pf.Labels["windows.mondoo.com/product-type"] = productType
	pf.Labels["windows.mondoo.com/display-version"] = current.DisplayVersion

Generally, asset labels are derived from the asset itself eg. EC2 instance tags and platform labels are operating system / platform specific, like Windows attaches specific information. I think the use of the same name 'labels' on two different structs leads to confusion as it is not always clear for new engineers what the difference is.

I think we should do the following:

1. we expose platform labels as asset.platformMetadata on asset.
2. we rename platform.Labels struct to platform.Metadata, which leads to less confusion

This would also require us to update the asset schema:

// General asset information
asset @defaults("name platform version") {
  // Human readable name of the asset
  name string
  // Platform for this asset (redhat, windows, k8s-pod)
  platform string
  // Version of the platform
  version string
  // Architecture this OS is running on
  arch string
  // Human-readable title of the platform (e.g., "Red Hat 8, Container")
  title string
  // List of platform families that this platform belongs to
  family []string
  // Fully qualified domain name (optional)
  fqdn string
  // Build version of the platform (optional)
  build string
  // Platform Metadata eg. key values from /etc/os/release
  platformMetadata map[string]string
  // Asset labels derived from the source system
  labels map[string]string
  // User-provided custom annotations (tags) on the asset
  annotations map[string]string
}

Since policies may depend on platform labels to be exposed on asset, we need to apply this migration into two steps:

1. Introduce platformMetadata field
2. Ensure all policies are migrated away to the new platformMetadata field
3. Switch asset.Labels field over to asset.Labels from platform.Labels in v12

[chris-rock]

Those updates should not be part of this PR since they distract the review.

[chris-rock]

That is not correct. Mvd Platform is just a conversion of the platform object.

[chris-rock]

pkg managers do not need to know the asset information