AKS [Feature] Add ARM Metadata to Mariner image

Is your feature request related to a problem? Please describe. When developing Azure Policies, I'd like a way to determine if a VMSS is part of a Kubernetes cluster. Naming conventions are unreliable.

There are ARM fields in VMSS resources: storageProfile.imageReference.offer, storageProfile.imageReference.publisher, storageProfile.imageReference.sku, and storageProfile.imageReference.version which are populated by other Linux distributions. Mariner leaves them null, and I can only work with storageProfile.imageReference.id. This seems to use unique identifiers which can vary over time.

Describe the solution you'd like Populate the fields with the necessary metadata to enable a better experience when managing AKS VMSS resources:

storageProfile.imageReference.offer
storageProfile.imageReference.publisher
storageProfile.imageReference.sku
storageProfile.imageReference.version

Describe alternatives you've considered We use storageProfile.imageReference.id today, but it varies by tenant and seems to change over time.

Additional context Add any other context or screenshots about the feature request here.

I'm not sure if this is relevant for other scenarios. Mine specifically relates to Azure Policy development and deployment, and we have to carve out a special case for AKS clusters to avoid dropping extensions/modifying the AKS VMSS as much as possible.

Mar 28 '24 16:03 corygehr

In case of misunderstanding: not only "Mariner", even the default "Ubuntu" won't provide the same necessary metadata and gave the null instead. For example:

az vmss show -n aks-agentpool-12345678-vmss -g MC_joey-aks-default --query virtualMachineProfile.storageProfile
{
  "dataDisks": null,
  "diskControllerType": "SCSI",
  "imageReference": {
    "communityGalleryImageId": null,
    "exactVersion": null,
    "id": "/subscriptions/109a5e88-712a-48ae-9078-9ca8b3c81345/resourceGroups/AKS-Ubuntu/providers/Microsoft.Compute/galleries/AKSUbuntu/images/2204gen2containerd/versions/202402.26.0",
    "offer": null,
    "publisher": null,
    "resourceGroup": "AKS-Ubuntu",
    "sharedGalleryImageId": null,
    "sku": null,
    "version": null
  },
  "osDisk": {
    "caching": "ReadWrite",
    "createOption": "FromImage",
    "deleteOption": null,
    "diffDiskSettings": null,
    "diskSizeGb": 128,
    "image": null,
    "managedDisk": {
      "diskEncryptionSet": null,
      "securityProfile": null,
      "storageAccountType": "Premium_LRS"
    },
    "name": null,
    "osType": "Linux",
    "vhdContainers": null,
    "writeAcceleratorEnabled": null
  }
}

virtualMachineProfile.storageProfile.imageReference.* parameters are important for audit purpose on customer side, which is to determine whether it is an official image or not (usually seen in VM scenarios, but AKS should be same here).

In simple: make the images used for AKS present in more official way will help on audit process.

Also, well notice that, if you are developing Azure built-in policy, be aware of NAP feature, which is based on VM not VMSS: https://learn.microsoft.com/en-us/azure/aks/node-autoprovision

Mar 29 '24 02:03 JoeyC-Dev

Action required from @aritraghosh, @julia-yin, @AllenWen-at-Azure