Edit

Share via

Configure customer-managed keys for an Azure Elastic SAN

  • Article

All data written to an Elastic SAN volume is automatically encrypted-at-rest with a data encryption key (DEK). Azure uses envelope encryption to encrypt the DEK using a Key Encryption Key (KEK). By default, the KEK is platform-managed (managed by Microsoft), but you can create and manage your own.

This article shows how to configure encryption of an Elastic SAN volume group with customer-managed keys stored in an Azure Key Vault.

Limitations

The following list contains the regions Elastic SAN is currently available in, and which regions support both zone-redundant storage (ZRS) and locally redundant storage (LRS), or only LRS:

  • Australia East - LRS
  • Brazil South - LRS
  • Canada Central - LRS
  • Central US - LRS
  • East Asia - LRS
  • East US - LRS
  • East US 2 - LRS
  • France Central - LRS & ZRS
  • Germany West Central - LRS
  • India Central - LRS
  • Japan East - LRS
  • Korea Central - LRS
  • North Europe - LRS & ZRS
  • Norway East - LRS
  • South Africa North - LRS
  • South Central US - LRS
  • Southeast Asia - LRS
  • Sweden Central - LRS
  • Switzerland North - LRS
  • UAE North - LRS
  • UK South - LRS
  • West Europe - LRS & ZRS
  • West US 2 - LRS & ZRS
  • West US 3 - LRS

Elastic SAN is also available in the following regions, but without Availability Zone support:

  • Canada East - LRS
  • Japan West - LRS
  • North Central US - LRS

To enable these regions, run the following command to register the necessary feature flag:

Register-AzProviderFeature -FeatureName "EnableElasticSANRegionalDeployment" -ProviderNamespace "Microsoft.ElasticSan"

Prerequisites

To perform the operations described in this article, you must prepare your Azure account and the management tools you plan to use. Preparation includes installing the necessary modules, logging in to your account, and setting variables for PowerShell and the Azure CLI. The same set of variables are used throughout this article, so setting them now allows you to use the same ones in all of the samples.

To perform the operations described in this article using PowerShell:

  1. Install the latest version of Azure PowerShell if you haven't already.

  2. Once Azure PowerShell is installed, install version 0.1.2 or later, of the Elastic SAN extension with Install-Module -Name Az.ElasticSan -Repository PSGallery.

  3. Sign in to Azure.

    Connect-AzAccount

Create variables to be used in the PowerShell samples in this article

Copy the sample code and replace all placeholder text with your own values. Use the same variables in all of the examples in this article:

# Define some variables
# The name of the resource group where the resources will be deployed.
$RgName          = "ResourceGroupName"

# The name of the Elastic SAN that contains the volume group to be configured.
$EsanName        = "ElasticSanName"

# The name of the Elastic SAN volume group to be configured.
$EsanVgName      = "ElasticSanVolumeGroupName"

# The region where the new resources will be created.
$Location        = "Location"

# The name of the Azure Key Vault that will contain the KEK.
$KvName          = "KeyVaultName"

# The name of the Azure Key Vault key that is the KEK.
$KeyName         = "KeyName"

# The name of the user-assigned managed identity, if applicable.
$ManagedUserName = "ManagedUserName"

Configure the key vault

You can use a new or existing key vault to store customer-managed keys. The encrypted resource and the key vault can be in different regions or subscriptions in the same Microsoft Entra ID tenant. To learn more about Azure Key Vault, see Azure Key Vault Overview and What is Azure Key Vault?.

Using customer-managed keys with encryption requires that both soft delete and purge protection are enabled for the key vault. Soft delete is enabled by default when you create a new key vault and can't be disabled. You can enable purge protection either when you create the key vault or after it's created. Azure Elastic SAN encryption supports RSA keys of sizes 2048, 3072 and 4096.

Azure Key Vault supports authorization with Azure RBAC via an Azure RBAC permission model. Microsoft recommends using the Azure RBAC permission model over key vault access policies. For more information, see Grant permission to applications to access an Azure key vault using Azure RBAC.

There are two steps involved in preparing a key vault as a store for your volume group KEKs:

  • Create a new key vault with soft delete and purge protection enabled, or enable purge protection for an existing one.
  • Create or assign an Azure RBAC role that has the backup create delete get import get list update restore permissions.

The following example:

  • Creates a new key vault with soft delete and purge protection enabled.
  • Gets the UPN of your user account.
  • Assigns the Key Vault Crypto Officer role for the new key vault to your account.

Use the same variables you defined previously in this article.

# Setup the parameters to create the key vault.
$NewKvArguments = @{
    Name                    = $KvName
    ResourceGroupName       = $RgName
    Location                = $Location
    EnablePurgeProtection   = $true
    EnableRbacAuthorization = $true
}

# Create the key vault.
$KeyVault = New-AzKeyVault @NewKvArguments

# Get the UPN of the currently logged in user.
$MyAccountUpn = (Get-AzADUser -SignedIn).UserPrincipalName

# Setup the parameters to create the role assignment.
$CrptoOfficerRoleArguments = @{
    SignInName         = $MyAccountUpn
    RoleDefinitionName = "Key Vault Crypto Officer"
    Scope              = $KeyVault.ResourceId
}

# Assign the Cypto Officer role to your account for the key vault.
New-AzRoleAssignment @CrptoOfficerRoleArguments

To learn how to enable purge protection on an existing key vault with PowerShell, see Azure Key Vault recovery overview.

For more information on how to assign an RBAC role with PowerShell, see Assign Azure roles using Azure PowerShell.

Add a key

Next, add a key to the key vault. Before you add the key, make sure that you have assigned to yourself the Key Vault Crypto Officer role.

Azure Storage and Elastic SAN encryption support RSA keys of sizes 2048, 3072 and 4096. For more information about supported key types, see About keys.

Use these sample commands to add a key to the key vault with PowerShell. Use the same variables you defined previously in this article.

# Get the key vault where the key is to be added.
$KeyVault = Get-AzKeyVault -ResourceGroupName $RgName -VaultName $KvName

# Setup the parameters to add the key to the vault.
$NewKeyArguments = @{
    Name        = $KeyName
    VaultName   = $KeyVault.VaultName
    Destination = "Software"
}

# Add the key to the vault.
$Key = Add-AzKeyVaultKey @NewKeyArguments

Choose a key rotation strategy

Following cryptographic best practices means rotating the key that is protecting your Elastic SAN volume group on a regular schedule, typically at least every two years. Azure Elastic SAN never modifies the key in the key vault, but you can configure a key rotation policy to rotate the key according to your compliance requirements. For more information, see Configure cryptographic key auto-rotation in Azure Key Vault.

After the key is rotated in the key vault, the encryption configuration for your Elastic SAN volume group must be updated to use the new key version. Customer-managed keys support both automatic and manual updating of the KEK version. Decide which approach you want to use before you configure customer-managed keys for a new or existing volume group.

For more information on key rotation, see Update the key version.

Important

When you modify the key or the key version, the protection of the root data encryption key changes, but the data in your Azure Elastic SAN volume group remains encrypted at all times. There is no additional action required on your part to ensure that your data is protected. Rotating the key version doesn't impact performance, and there is no downtime associated with it.

Automatic key version rotation

Azure Elastic SAN can automatically update the customer-managed key that is used for encryption to use the latest key version from the key vault. Elastic SAN checks the key vault daily for a new version of the key. When a new version becomes available, it automatically begins using the latest version of the key for encryption. When you rotate a key, be sure to wait 24 hours before disabling the older version.

Important

If the Elastic SAN volume group was configured for manual updating of the key version and you want to change it to update automatically, change the key version to an empty string. For more information on manually changing the key version, see Automatically update the key version.

Manual key version rotation

If you prefer to update the key version manually, specify the URI for a specific version at the time that you configure encryption with customer-managed keys. When you specify the URI, your elastic SAN won't automatically update the key version when a new version is created in the key vault. For your elastic SAN to use a new key version, you must update it manually.

To locate the URI for a specific version of a key in the Azure portal:

  1. Navigate to your key vault.
  2. Under Objects select Keys.
  3. Select the desired key to view its versions.
  4. Select a key version to view the settings for that version.
  5. Copy the value of the Key Identifier field, which provides the URI.
  6. Save the copied text to use later when configuring encryption for your volume group.

Screenshot showing key vault key URI in Azure portal.

Choose a managed identity to authorize access to the key vault

When you enable customer-managed encryption keys for an Elastic SAN volume group, you must specify a managed identity that is used to authorize access to the key vault that contains the key. The managed identity must have the following permissions:

  • get
  • wrapkey
  • unwrapkey

The managed identity that is authorized access to the key vault can be either a user-assigned or system-assigned managed identity. To learn more about system-assigned versus user-assigned managed identities, see Managed identity types.

When a volume group is created, a system-assigned identity is automatically created for it. If you want to use a user-assigned identity, create it before you configure customer-managed encryption keys for your volume group. To learn how to create and manage a user-assigned managed identity, see Manage user-assigned managed identities.

Use a user-assigned managed identity to authorize access

When you enable customer-managed keys for a new volume group, you must specify a user-assigned managed identity. An existing volume group supports using either a user-assigned managed identity or a system-assigned managed identity to configure customer-managed keys.

When you configure customer-managed keys with a user-assigned managed identity, the user-assigned managed identity is used to authorize access to the key vault that contains the key. You must create the user-assigned identity before you configure customer-managed keys.

A user-assigned managed identity is a standalone Azure resource. To learn more about user-assigned managed identities, see Managed identity types. To learn how to create and manage a user-assigned managed identity, see Manage user-assigned managed identities.

The user-assigned managed identity must have permissions to access the key in the key vault. You can either manually grant permissions to the identity, or assign a built-in role with key vault scope to grant these permissions.

The following example shows how to:

  • Create a new user-assigned managed identity.
  • Wait for the creation of the user-assigned identity to complete.
  • Get the PrincipalId from the new identity.
  • Assign an RBAC role to the new identity, scoped to the key vault.

Use the same variables you defined previously in this article.

# Create a new user-assigned managed identity.
$UserIdentity = New-AzUserAssignedIdentity -ResourceGroupName $RgName -Name $ManagedUserName -Location $Location

Tip

Wait about 1 minute for the creation of the user-assigned identity to finish before proceeding.

# Get the `PrincipalId` for the new identity.
$PrincipalId = $UserIdentity.PrincipalId

# Setup the parameters to assign the Crypto Service Encryption User role.
$CryptoUserRoleArguments = @{
    ObjectId           = $PrincipalId
    RoleDefinitionName = "Key Vault Crypto Service Encryption User"
    Scope              = $KeyVault.ResourceId
}

# Assign the Crypto Service Encryption User role to the managed identity so it can access the key in the vault.
New-AzRoleAssignment @CryptoUserRoleArguments

Use a system-assigned managed identity to authorize access

A system-assigned managed identity is associated with an instance of an Azure service, such as an Azure Elastic SAN volume group.

The system-assigned managed identity must have permissions to access the key in the key vault. This article uses the Key Vault Crypto Service Encryption User role to the system-assigned managed identity with key vault scope to grant these permissions.

When a volume group is created, a system-assigned identity is automatically created for it if the -IdentityType "SystemAssigned" parameter is specified with the New-AzElasticSanVolumeGroup command. The system-assigned identity isn't available until after the volume group has been created. You must also assign an appropriate role such as the Key Vault Crypto Service Encryption User role to the identity before it can access the encryption key in the key vault. So, you can't configure customer-managed keys to use a system-assigned identity during creation of a volume group. When you create a new volume group with customer-managed keys, you must use a user-assigned identity when you create the volume group, you can configure a system-assigned identity after it's created.

Use this sample code to assign the required RBAC role to the system-assigned managed identity, scoped to the key vault. Use the same variables you defined previously in this article.

# Get the Elastic SAN volume group.
$ElasticSanVolumeGroup = Get-AzElasticSanVolumeGroup -Name $EsanVgName -ElasticSanName $EsanName -ResourceGroupName $RgName

# Generate a system-assigned identity if one does not already exist.
If ($ElasticSanVolumeGroup.IdentityPrincipalId -eq $null) {
Update-AzElasticSanVolumeGroup -ResourceGroupName $RgName -ElasticSanName $EsanName -Name $EsanVgName -IdentityType "SystemAssigned"}

# Get the `PrincipalId` (system-assigned identity) of the volume group.
$PrincipalId = $ElasticSanVolumeGroup.IdentityPrincipalId

# Setup the parameters to assign the Crypto Service Encryption User role.
$CryptoUserRoleArguments = @{
    ObjectId           = $PrincipalId
    RoleDefinitionName = "Key Vault Crypto Service Encryption User"
    Scope              = $KeyVault.ResourceId
}

# Assign the Crypto Service Encryption User role.
New-AzRoleAssignment @CryptoUserRoleArguments

Configure customer-managed keys for a volume group

Select the Azure PowerShell module or the Azure CLI tab for instructions on how to configure customer-managed encryption keys using your preferred management tool.

Now that you've selected PowerShell, select the tab that corresponds to whether you want to configure the settings during creation of a new volume group, or update the settings for an existing one.

Use this sample to configure customer-managed keys with automatic updating of the key version during creation of a new volume group using PowerShell:

# Setup the parameters to create the volume group.
$NewVgArguments        = @{
    Name                         = $EsanVgName
    ElasticSanName               = $EsanName
    ResourceGroupName            = $RgName
    ProtocolType                 = "Iscsi"
    Encryption                   = "EncryptionAtRestWithCustomerManagedKey"
    KeyName                      = $KeyName
    KeyVaultUri                  = $KeyVault.VaultUri
    IdentityType                 = "UserAssigned"
    IdentityUserAssignedIdentity = @{$UserIdentity.Id=$UserIdentity}
    EncryptionIdentityEncryptionUserAssignedIdentity = $UserIdentity.Id
}

# Create the volume group.
New-AzElasticSanVolumeGroup @NewVgArguments

To configure customer-managed keys with manual updating of the key version during creation of a new volume group using PowerShell, add the KeyVersion parameter as shown in this sample:

# Setup the parameters to create the volume group.
$NewVgArguments        = @{
    Name                         = $EsanVgName
    ElasticSanName               = $EsanName
    ResourceGroupName            = $RgName
    ProtocolType                 = "Iscsi"
    Encryption                   = "EncryptionAtRestWithCustomerManagedKey"
    KeyName                      = $KeyName
    KeyVaultUri                  = $KeyVault.VaultUri
    KeyVersion                   = $Key.Version
    IdentityType                 = "UserAssigned"
    IdentityUserAssignedIdentity = @{$UserIdentity.Id=$UserIdentity}
    EncryptionIdentityEncryptionUserAssignedIdentity = $UserIdentity.Id
}

# Create the volume group.
New-AzElasticSanVolumeGroup @NewVgArguments

Next steps