Include Guest Attestation Extension and enable System Assigned MSI by default when Trusted Launch configuration is met

[sirfamelin]

Is your feature request related to a problem? Please describe.
Trusted Launch VMs (GA in Nov 2021) are Gen 2 VMs with new security guarantees. The north star is to have all Gen 2 VMs created in Azure be Trusted Launch VMs - greatly improving the security posture of Azure and customer workloads. One feature of Trusted Launch that we need help driving user adoption is to lower the bar of entry of a critical feature that makes Trusted Launch VMs secure - the Guest Attestation Extension. Today, customer's are experiencing friction when installing the extension - either they do not know it exists or they have to manually install the extension post VM creation or they have to change their scripts to include an extra command to install the extension and enable MSI. The goal is to have the extension and MSI enabled when the VM configuration meets the Trusted Launch configuration without. requiring the customer to use another command.

Describe the solution you'd like
We want to ensure that the Guest Attestation extension is added to the VM object and MSI enabled at the Az Cli layer when the trusted launch config conditions are met without extra CLI commands or parameters, and without having to make changes to the rest-api-specs and SDK. In the case that the customer does not want to install the extension, we would like to introduce an optional parameter --disable-integrity-monitoring to the following CLI command interface:
Az vm create
Az vm update
Az vmss create
Az vmss update
In this case, the Guest Attestation extension as well as MSI should not be enabled even when the VM config matches the Trusted Launch config.

The extension details for Windows:
Name:
Publisher: Microsoft.Azure.Security.WindowsAttestation

The extension details for Linux:
Name: GuestAttestation
Publisher: Microsoft.Azure.Security.LinuxAttestation

Describe alternatives you've considered
An alternative that would be acceptable is the inverse of the preferred solution. In this case, we would want to add a parameter such as --enable-integrity-monitoring to the following:
Az vm create
Az vm update
Az vmss create
Az vmss update
In this case the customer would have to explicitly pass in the parameter --enable-integrity-monitoring to have the Guest Attestation extension installed and MSI enabled.

Additional context
The extension details for Windows:
Name:
Publisher: Microsoft.Azure.Security.WindowsAttestation

The extension details for Linux:
Name: GuestAttestation
Publisher: Microsoft.Azure.Security.LinuxAttestation

[yonzhan]

Compute

[sirfamelin]

@PARADISSEEKR I see you have self-assigned this feature request, what are the next steps? Do you need more information from me?

[zhoxing-ms]

@sirfamelin self-assigned means that he will help develop this requirement. We will communicate with you when necessary, thanks for you help~

[Jing-song]

Hi @sirfamelin, I'm not sure how --enable-integrity-monitoring works, could you please provide an example, such as a swagger link.

[sirfamelin]

@PARADISSEEKR , this parameter is not part of the swagger spec or the SDK, would it be possible to implement this change only at the Cli layer?

[zhoxing-ms]

@sirfamelin Yes, CLI supports VM and VMSS through the ARM template and does not need to update Swagger and Python SDK.
But we need the example of the reuqest body to the service, just like these examples under directory compute_request_example
Could you provide it?

[sirfamelin]

We would like to reduce the scope of the ask to only cover the create operations:
Az vm create
Az vmss create

[sirfamelin]

Hi @zhoxing-ms, my apologies but it looks like I missed a crucial configuration of the VMSS. By default, it looks like the upgrade policy is set to "manual". This blocks the updates (MSI, Guest Attestation Extension) to the VMSS model to be applied to the individual instances. In order to apply the changes, we need to run the following AFTER MSI and the extension is updated in the VMSS model:

az vmss update-instances --resource-group "rgname" --name "vmssName" --instance-ids *

Should I open a new GitHub issue to request this update, or can we continue using this issue?

[zhoxing-ms]

@sirfamelin Please create a new feature request.
In addition, since the work of this sprint has been fully arranged, is it acceptable for this requirement to be developed and released in the next sprint (07-05)?

[sirfamelin]

@zhoxing-ms, I raised a new issue here: #22338

FYI @akashgupta29 in case Xing Zhou has more questions while I am OOF.