Eric Jarvi https://docs.microsoft.com/archive/blogs/ejarvi/feed.xml Tue, 16 Apr 2019 05:04:49 GMT en-US hourly 1 Encrypting Data Disks on Linux with Azure Disk Encryption https://docs.microsoft.com/archive/blogs/ejarvi/encrypting-data-disks-on-linux-with-azure-disk-encryption Fri, 30 Mar 2018 14:42:44 GMT https://blogs.msdn.microsoft.com/ejarvi/?p=2655 There are two main ways to encrypt data disks using Azure Disk Encryption.  You can choose to thoroughly encrypt the existing disk block-by-block using EnableEncryption, or you can choose to rapidly format and encrypt the data disk using EncryptFormatAll.

Both of these techniques have a common setup requirement that will signal to the ADE solution which data disks are to be encrypted:

Prerequisite Data Disk Setup​

First, prior to enabling encryption, the data disks to be encrypted need to be properly listed in /etc/fstab. Take care to use a persistent block device name for this entry, as device names in the "/dev/sdX" format cannot be relied to be associated with the same disk across reboots particularly after encryption is applied. For more detail on this behavior, see:  https://docs.microsoft.com/en-us/azure/virtual-machines/linux/troubleshoot-device-names-problems

  Next, ensure that the /etc/fstab settings are configured properly for mounting.  To do this, run the mount -a command or reboot the VM and trigger the remount that way.  Once that is complete, check the output of the lsblk command to verify that the desired drive is still mounted.  The reason for this test is simple. If the /etc/fstab file does not mount the drive properly prior to enabling encryption, ADE will not able to mount it properly either.  The ADE process will be moving the mount information out of /etc/fstab and into its own configuration file as part of the encryption process.  Do not be surprised to see the entry missing from /etc/fstab after data drive encryption completes.  Also be sure to give time after reboot for the ADE process to mount the newly encrypted disks.  They will not be immediately available after a reboot, the ADE process will need time to start, unlock, and then mount the encrypted drives prior to their being available for other processes to access.  This may take more than a minute after reboot depending on the system characteristics.  

​A simple example of commands that can be used to mount the data disks and create the necessary /etc/fstab entries can be found here:

https://github.com/ejarvi/ade-cli-getting-started/blob/master/validate.sh#L197-L205

 
Once the data disk is ready, you can choose to either encrypt the existing data block-by-block using EnableEncryption, or you can choose to rapidly format and encrypt the data disks using EncryptFormatAll.

EnableEncryption (encrypt data drive contents, preserving content)

This process can be very time consuming depending on the size of the drive contents to encrypt, but it allows existing content to be encrypted.

Powershell:

To use this process, prepare the drive as above and then use the Powershell cmdlet Set-AzureRmVmDiskEncryptionExtension:
https://docs.microsoft.com/en-us/powershell/module/azurerm.compute/set-azurermvmdiskencryptionextension?view=azurermps-5.4.0
Encryption may take several hours if the "OS" or "All" VolumeType is selected.  If the "Data" VolumeType is selected then the time required will be proportional to the size of the data volume(s) to be encrypted.

CLI:

Prepare the drive as above, and then use the az vm encryption enable command.
An example bash script of how to enable encryption end to end that uses this command is available here: https://github.com/ejarvi/ade-cli-getting-started/blob/master/validate.sh
Please note that on successful completion of this script, the script will automatically delete the resources that it just created.  If you would like to preserve the resource, make sure to comment out or remove the last line of the script prior to running.

ARM Template:

Using an ARM template to encrypt a running Linux VM is possible.  Ensure the EncryptionOperation value is set to "EnableEncryption” - I don't have a pointer to a template that uses this yet, but for now modifying this template may be sufficient:  

EncryptFormatAll

This process is very fast but is only for scenarios where there is no existing content on the mounted data drives.
After running this command any drives that were mounted previously will be formatted and then the encryption layer will be started on top of that now empty drive.
Additionally, when this option is selected, the "ephemeral" resource disk attached to the VM will also be encrypted.  If the ephemeral drive is reset, it will be reformatted and re-encrypted by the ADE solution in the VM at the next opportunity.
Some additional documentation of the EncryptFormatAll mode including powershell and ARM template examples is available at:
]]> How to Check Your Azure Management Tools Version https://docs.microsoft.com/archive/blogs/ejarvi/how-to-check-your-azure-management-tools-version Wed, 28 Mar 2018 14:57:43 GMT https://blogs.msdn.microsoft.com/ejarvi/?p=2645 Both Azure Powershell SDK and Azure CLI 2.0 are frequently updated to stay current.  Older versions have limited shelf life.

If a certain Azure management scenario isn't working as expected, it may be because of stale tools. Here are commands to check the version of the tools you may currently have installed:

Azure Powershell:

Get-Module -ListAvailable -Name Azure -Refresh

Azure CLI 2.0: 

az --version​

The version number corresponding to the most recent release for each of these projects is documented in the Github release history:

​If keeping the installed version of these tools up to date is an annoyance, I would suggest checking out Azure Cloud Shell as a possible alternative.   The Cloud Shell feature is maintained by Azure Portal and tracks to the most recent version of Powershell or CLI automatically.  Doesn't require you to install Powershell or CLI locally on your machine.  You access it through the browser, but it feels pretty close to what you'd get from a local shell. More details at:    https://azure.microsoft.com/en-us/features/cloud-shell/
]]> generating self-signed certificates with keyvault https://docs.microsoft.com/archive/blogs/ejarvi/generating-self-signed-certificates-with-keyvault Tue, 10 Jan 2017 17:23:19 GMT https://blogs.msdn.microsoft.com/ejarvi/?p=2575 pre-existing self-signed certificates into KeyVault.  But... what if you don't have a pre-existing self-signed certificate? It is possible to have KeyVault generate the new self-signed certificate for you inside of your KeyVault.  One and done.  No import. No messy certificate residue left behind at your admin console. The trick to getting KeyVault to do this for you is to use "Self" as the issuer name in your policy file.  Here is a simple example of how to generate the self-signed certificate using the Azure CLI: 
azure keyvault certificate policy create --issuer-name Self --subject-name "CN=www.contoso.com" --file policy.json --validity-in-months 12
azure keyvault certificate create --vault-name mykeyvault --certificate-name mycert --certificate-policy-file policy.json
Here is an example of how to do it using Powershell (as found in the Quick Start document below): 
$policy = New-AzureKeyVaultCertificatePolicy -SubjectName "CN=www.contoso.com" -IssuerName Self -ValidityInMonths 12
Add-AzureKeyVaultCertificate -VaultName $vaultName -Name $certificateName -CertificatePolicy $policy
If you want to dive deeper, or if what you really want is a full fledged SSL certificate created in similar fashion, here is some more documentation: ]]>