[TrustedLaunch] Default --enable-secure-boot and --enable-vtpm to true and optional flags in relation to --security-type TrustedLaunch

[sirfamelin]

Related command
az vm create
az vmss create

Is your feature request related to a problem? Please describe.
Today if a customer does not provide the values for --enable-vtpm and --enable-secure-boot, the values are not defaulted to true. This will result in a VM that does not take advantage of the full features of Trusted Launch

Describe the solution you'd like
We would like to make EnableVtpm and EnableSecureBoot as optional flags in relation to SecurityType, and have the EnableVtpm and EnableSecureBoot flags set to true in the background. This will lower the bar of entry even further, provide the customer the full set of Trusted Launch features by default, as well as provide the Guest Attestation extension by default functionality.

Describe alternatives you've considered
n/a

Additional context
az vm create -n "s1win1" -g sirlinazsub_1 --location japaneast --size Standard_D2s_v3 --image MicrosoftWindowsServer:WindowsServer:2019-Datacenter-Gensecond:latest --admin-username "player1" --admin-password "supersecurepw" --security-type TrustedLaunch

az vmss create -n s1vmss1 -g sirlin5 --location westcentralus --instance-count 5 --data-disk-sizes-gb 2 --os-disk-size-gb 128 --image SUSE:SLES-15-SP2:GEN2:latest --admin-username "player1" --admin-password "supersecurepw" --security-type TrustedLaunch

Both scenarios listed above should result in secureboot enabled, vtpm enabled, and MSI enablement, and Guest Attestation extension installation.

[yonzhan]

Compute feature

[zhoxing-ms]

@sirfamelin Please note that if we directly modify the default value of those parameters, it will cause breaking change to users.

I suggest that when the --security-type used by the VM/VMSS creation is TrustedLaunch, we print the warning log to recommend users to specify the --enable-secure-boot True and --enable-vtpm True first.

Since CLI has bi-annual breaking change releases coinciding with Microsoft Build and Ignite. Until the next breaking change window (Ignite Event) of CLI, please submit a new feature request one month before that to change the default value, then we will change the default value in that sprint to avoid the big impact of breaking change on users.

[sirfamelin]

Interesting, I did not realize that --enable-secure-boot and --enable-vtpm were defaulted to false and optional already. It seems like we don't really have choice but to wait until Ignite. Does that mean I should raise the request in the beginning of October?

In the meantime, a warning message will do. Something like "Please set --enable-secure-boot to True and --enable-vtpm to True in order to receive the full suite of security features that comes with Trusted Launch."

[zhoxing-ms]

Does that mean I should raise the request in the beginning of October?
In the meantime, a warning message will do.

@sirfamelin Yes, we only add warning logs to inform users of migration usage first and then wait until the next breaking change release Ignite to modify the default behavior, this is the best solution I can think of that will have the least impact on users at present.

For more details about the CLI breaking change process, you can refer to this draft guideline doc link

[sirfamelin]

Okay. For the change to add warning logs, can we target the August release or is it too late?

[zhoxing-ms]

@sirfamelin We can target the August release, @PARADISSEEKR please be aware

[sirfamelin]

@zhoxing-ms , I just got around to checking the PR, I see the message to encourage users to enable vtpm and secureboot, but I don't see the warning message of the upcoming breaking change.

On that note, I would like to revisit enabling vtpm as a breaking change. By enabling vTPM by default, there's no impact or disruptions to customer workloads. Secureboot is a breaking change, I agree, but I think vTPM is not indicative as a breaking change.

[zhoxing-ms]

@sirfamelin I'd like to ask why enabling vTPM will not cause breaking change to users? Could you guarantee that the vTPM will only add new feature to users, but not affect the existing features of users?

[zhoxing-ms]

@sirfamelin By the way, since this question was raised late and we will launch the release of the new CLI version tomorrow, I suggest that the warning message of breaking change and the behavior of enabling vTPM by default be added in the next sprint (09-06), do you think it's acceptable?

[sirfamelin]

@zhoxing-ms, that is correct. Vtpm will not cause breaking changes as it will not affect existing software. The vTPM provides cryptographic functions and key storage. It should not impact customer workloads.

Is 09/06 the release date?

[zhoxing-ms]

that is correct. Vtpm will not cause breaking changes as it will not affect existing software. The vTPM provides cryptographic functions and key storage. It should not impact customer workload

@sirfamelin Got it, thanks~

Is 09/06 the release date?

Yes