Consider private offerings when checking that a VM or VMSS has Linux

[VeraBE]

When checking if a VM or VMSS has Linux (#1701) we should also account for private offerings

Reference: https://learn.microsoft.com/en-us/azure/marketplace/private-offers-api

[BenjaminEngeset]

@VeraBE

Actually very interesting to see this now, was going to report it as I saw the same pattern for some agent pools I configured in the weekend. The rule was not excecuted due to this and just had outcome None.

[BernieWhite]

@VeraBE @bengeset96 So basically we are saying that there isn't really any way to determine is it Linux this from the resource configuration of the VM/VMSS (even under private offers) so we need to provide customers some option to configure offers that are Linux ideally through an automated export process.

[VeraBE]

@BernieWhite I'm not sure if I understood the question, are you suggesting we let the customers specify which VMs are Linux and then we analyze those? Why do you say "even under private offers"? If we had all the public and private offerings the current check would work, but I don't know how could we validate the private ones

For now, we could also just change the precondition to a merge between the current approach and what we had before: a VM has Linux if either the offering is a public Linux offering OR it defines a linuxConfiguration property OR the disk check, what do you think about that?

[BenjaminEngeset]

I think it's better to have something than nothing, so what @VeraBE proposed here in the last statement would improve the confidence further for now.

But the ultimate goal must be to be confident if it's GNU/Linux or not, and in order to achieve that we have to provide the customers some sort of exporting experience. Having someone deploying GNU/Linux virtual machines or virtual machine scale sets without SSH keys only should not be possible unless it is explicitly stated.

I'm starting to see this pattern more and more for "new" resource declarations/updates provided by Microsoft, the resource declarations does not explicily state all potensial configuration anymore. It also means that we have to come up with a additional way of handling these scenarios/situations that I just assume will increase in close future.

[BernieWhite]

@VeraBE @bengeset96 Ok great. Thanks for the feedback.

My thoughts would be:

• Add the Properties.storageProfile.osDisk.osType or Properties.osProfile.linuxConfiguration for VM.
• Add the properties.virtualMachineProfile.OsProfile.linuxConfiguration for VMSS.
• Add offer match for *ubuntu*, *linux*, *rhel*, centos, *redhat*, *debian*, *suse*.
• Add configuration parameter AZURE_LINUX_OS_OFFER for additional SKUs that can be set by the customer.

While it is not 100% it should get us close. Any other gaps you can see with this?

[BenjaminEngeset]

From my side I think this should cover it well, with fairly high confidence.

[VeraBE]

@BernieWhite Sounds good to me. I can make a PR with those changes, but I don't have that much context on the last item. Is there a similar configuration parameter I can look at as a guide?

[BernieWhite]

Thanks @VeraBE.

There is some documentation around configuration over here: https://microsoft.github.io/PSRule/v2/concepts/PSRule/en-US/about_PSRule_Variables/#configuration

Here are some examples of usage:

PSRule.Rules.Azure/src/PSRule.Rules.Azure/rules/Azure.Policy.Rule.ps1

Lines 33 to 35 in cc54e5f

	Rule 'Azure.Policy.WaiverExpiry' -Ref 'AZR-000146' -Type 'Microsoft.Authorization/policyExemptions' -With 'Azure.PolicyExemptionWaiver' -Tag @{ release = 'GA'; ruleSet = '2021_06' } {
	$Assert.LessOrEqual($TargetObject, 'properties.expiresOn', $Configuration.AZURE_POLICY_WAIVER_MAX_EXPIRY);
	} -Configure @{ AZURE_POLICY_WAIVER_MAX_EXPIRY = 366 }

PSRule.Rules.Azure/src/PSRule.Rules.Azure/rules/Azure.Deployment.Rule.ps1

Line 22 in cc54e5f

$propertyNames = $Configuration.GetStringValues('AZURE_DEPLOYMENT_SENSITIVE_PROPERTY_NAMES');

PSRule.Rules.Azure/src/PSRule.Rules.Azure/rules/Azure.Automation.Rule.ps1

Line 60 in cc54e5f

$configurationLogCategoriesList = $Configuration.GetStringValues('AZURE_AUTOMATIONACCOUNT_ENABLED_PLATFORM_LOG_CATEGORIES_LIST');

The configuration value defaults are defined over here:

https://github.com/Azure/PSRule.Rules.Azure/blob/main/src/PSRule.Rules.Azure/rules/Config.Rule.yaml#L27-L37

Because it is intended that customers override it, we can just leave it as an empty array.

We have some basic documentation over here for the customer on the configuration option:

https://github.com/Azure/PSRule.Rules.Azure/blob/main/docs/setup/configuring-rules.md / https://azure.github.io/PSRule.Rules.Azure/setup/configuring-rules/