Confidential Compute CLI Change Request - VM OS Disk / Disk Encryption Set Create

Is your feature request related to a problem? Please describe

No, feature request to add new parameter and add values into existing parameters for following commands to support Confidential VM - Planned GA by end of June CY22:

• az disk create
• az disk-encryption-set create

Feature is to support customers with:

• creating Disk Encryption Set which will support Confidential VM Creation using customer encryption keys.
• creating managed OS Disk for Confidential VM with flexibility to choose between Platform keys and customer-managed keys.

Describe the solution you’d like

Existing Parameter

az disk create

Customer to use az disk create command with parameter –security-type to set Security Type. For confidential VM Additional accepted security type should be ConfidentialVM_DiskEncryptedWithCustomerKey, ConfidentialVM_VMGuestStateOnlyEncryptedWithPlatformKey, ConfidentialVM_DiskEncryptedWithPlatformKey

Post change, following values will be accepted:

SecurityType
TrustedLaunch
ConfidentialVM_VMGuestStateOnlyEncryptedWithPlatformKey
ConfidentialVM_DiskEncryptedWithPlatformKey
ConfidentialVM_DiskEncryptedWithCustomerKey

az disk-encryption-set create

Customer to use az disk-encryption-set create command with parameter –encryption-type to set Encryption type. For confidential VM, additional accepted encryption type should be ConfidentialVmEncryptedWithCustomerKey

Post change, following values will be accepted:

EncryptionType
EncryptionAtRestWithPlatformKey
EncryptionAtRestWithCustomerKey
EncryptionAtRestWithPlatformAndCustomerKeys
ConfidentialVmEncryptedWithCustomerKey

New Parameter

–secure-vm-disk-encryption-set (az disk create)

New Parameter –secure-vm-disk-encryption-set for command az disk create:

• Allows customer to provide ARM ID for Disk Encryption Set created with ConfidentialVmEncryptedWithCustomerKey encryption type. This will allow customer to use Customer Managed Key (CMK) encryption.
• Mandatory and required only when –security-type is set to ConfidentialVM_DiskEncryptedWithCustomerKey

End to End Usage

Scenario 1 - Managed OS Disk Create

1. Store Disk Encryption Set ID in variable:

   diskEncryptionSetId=$(az disk-encryption-set show -n $diskEncryptionSetName -g $rgName --query [id] -o tsv)

2. Create Virtual Machine Disk with ConfidentialVM_DiskEncryptedWithCustomerKey Security Type

   az disk create --name $diskName -g $rgName \
       --hyper-v-generation V2 --os-type Windows \
       --security-type ConfidentialVM_DiskEncryptedWithCustomerKey \
       --secure-vm-disk-encryption-set $diskEncryptionSetId \
       --image-reference "MicrosoftWindowsServer:WindowsServer:2019-datacenter-gensecond:latest"
   

Scenario 2 - Disk Encryption Set Create

1. Create New key vault with premium SKU

   KeyVault="myKeyVault"
   az keyvault create --name $KeyVault --resource-group $rgName --location $region --sku Premium --enable-purge-protection 
   

2. Create RSA-HSM Key with key release policy

   $KeyName = <name of key>
   $KeySize = 3072
   az keyvault key create --vault-name $KeyVault --name $KeyName --ops wrapKey unwrapkey --kty RSA-HSM --size $KeySize --exportable true --policy "@.\skr-policy.json"
   

3. Query Key-vault key required for Disk Encryption Set

   keyUrl=$(az keyvault key show -n $keyName --vault-name $keyVaultName --query [key.kid] -o tsv)

4. Create Disk Encryption Set

   az disk-encryption-set create -n $diskEncryptionSetName \
       -g $rgName -l $location \
       --key-url $keyUrl --encryption-type "ConfidentialVmEncryptedWithCustomerKey"
   

5. Assign Access to Disk Encryption Set

   desIdentity=$(az disk-encryption-set show -n $diskEncryptionSetName -g $rgName --query [identity.principalId] -o tsv)
   
   az keyvault set-policy -n $KeyVault \
   -g $rgName \
   --object-id $desIdentity \
   --key-permissions wrapkey unwrapkey get
   

Describe alternatives you’ve considered

Not Applicable, new product feature request.

Additional context

Related to #22199

Request for Confidential VM - Planned GA by end of June CY22

• Link to CVM Disk RP Swagger Spec
• Link to Compute RP Swagger Spec
• Confidential VM with Customer Managed Keys ARM JSON
• Confidential VM with Platform Managed Keys ARM JSON
• Confidential Compute CLI Change Request - VM / VMSS Create
• Confidential VM GA Request Powershell change on Set-AzDiskSecurityProfile cmdlet
• Confidential VM GA Request Powershell change on Set-AzVmSecurityProfile cmdlet
• Confidential VM GA Request Powershell change on Set-New-AzDiskEncryptionSetConfig cmdlet

Additional Checks

• User provides value for –hyper-v-generation as V2 when –security-type parameter is used. If not, help message to be printed - SecurityType value for parameter --security-type is supported with --hyper-v-generation set to v2., where SecurityType value will be replaced by value passed for parameter --security-type.
• When parameter --security-type is used, supported create options for disk are FromImage, Import, ImportSecure, UploadPreparedSecure. Empty is not supported.
• ARM URI of Disk Encryption Set ID provided for new parameter –secure-vm-disk-encryption-set should have encryption type set to ConfidentialVmEncryptedWithCustomerKey.

Contacts

Role	Contact
Main developer contacts (emails + github aliases)	Abhishek Verma (AZURE) [e-mail], Anshul Solanki [e-mail]
PM contact (email + github alias)	Ajay Kundnani [e-mail]
Other people who should attend a design review (email)	Run Cai [e-mail], Deepak J V [e-mail]

[AjKundnani]

@AjKundnani In order to avoid breaking change, I suggest that we can state this limitation in the help message first. And when users use the --security-type parameter, if they do not use the --hyper-v-generation parameter or they specify the --hyper-v-generation parameter as V1, CLI will only print a warning log to prompt them that they should specify the --hyper-v-generation parameter as V2 when using the --security-type parameter As for adding verification, we can wait for the next breaking change window (Ignite Event), and then you can submit a new feature request to remind us to add verification for --hyper-v-generation parameter What do you think of this solution?

• In case user does not specifies --hyper-v-generation parameter, as it is auto-setting itself to V2 in current release, we can skip the warning log.
• In case user specifies value V1 for --hyper-v-generation parameter, if CLI can print warning log, that’ll be good, prompt should be non-interactive.
• Yes, will submit new request to add verification in sprint close to Ignite event.

[AjKundnani]

@AjKundnani In current official CLI, if users pass in the --security-type parameter but do not pass in --hyper-v-generation parameter or specify the --hyper-v-generation parameter as V1, will the REST service raise an error at present? If so, there is no breaking change. Otherwise, it will block this usage so as to cause breaking change

@zhoxing-ms : Below is the current behavior for --security-type TrustedLaunch, if we can retain same behavior for new values please:

1. It checks for CreateOption if image reference is not passed, Error (BadRequest) Security Type ‘TrustedLaunch’ is not supported for CreateOption ‘Empty’. Supported create options are FromImage, Import, ImportSecure, UploadPreparedSecure.
2. After adding image reference, it checks for size, if less than 128GB, it throws error (ResizeDiskError) The disk/snapshot resource with id https://md-txp1chwkmhw1.z20.blob.storage.azure.net/ghgfvpxvrqx4/abcd cannot be resized down. Reducing disk/snapshot size is not supported in Azure to prevent data loss. If you do need to reduce the size of the disk, please create new snapshot/disks with the appropriate size. More information is available at https://aka.ms/AzureDisksFAQ.
3. After passing image reference and size 128GB, without specifying parameter --hyper-v-generation, the disk is created with --hyper-v-generation set to V2
4. Adding parameter --hyper-v-generation with value V2, same result as step 3 above.
5. Adding parameter --hyper-v-generation with value V1, it creates the disk with Hyper-V generation v1, this shouldnt occur but to avoid breaking change, please do not add this check at present, if we can add a help message stating Security Type value for parameter --security-type is supported with --hyper-v-generation V2. (where Security type value can be replaced with value end user passed), and during next breaking change release we can add this check, if that will be ok?