Azure Key Vault is arguably one of the most important services that Microsoft Azure provides to enable organizations to centrally and securely store encryption keys, secrets, and certificates. There aren’t many configuration parameters in Azure Key Vault but having an understanding of the 3 core components it stores, their purpose, and how the service works is important so this blog post serves to provide an overview and the configuration of this service.
As always, I would like to provide the following links to the official Microsoft Azure Key Vault documentation:
Azure Key Vault basic concepts
https://docs.microsoft.com/en-us/azure/key-vault/general/basic-concepts
About Azure Key Vault
https://docs.microsoft.com/en-us/azure/key-vault/general/overview
Azure Key Vault security
https://docs.microsoft.com/en-us/azure/key-vault/general/security-features
Best practices to use Key Vault
https://docs.microsoft.com/en-us/azure/key-vault/general/best-practices
Using secrets from Azure Key Vault in a pipeline
https://azuredevopslabs.com/labs/vstsextend/azurekeyvault/
What is Azure Key Vault?
Azure Key Vault provides the service to store 3 types of entities:
- Keys
- Secrets
- Certificates
These 3 entities fulfill various functionalities of applications, virtual machines and other services within Azure and also on-premise networks. Having Azure Key Vault centrally store these entities allow an organization to easily provision, manage, and audit access of the objects in the vault.
What type of “Keys” does Azure Key Vault Store?
The type of keys that are stored in an Azure Key Vault are keys used for encryption and are typically asymmetric encryption keys such as RSA and EC (Elliptic-curve). AES symmetric keys are also available but a managed HSM service will be required. An example of a service that would utilize the Azure Key Vault to store encryption key would be Azure Server-side Encryption (SSE) and Azure Disk Encryption (ADE). I’ve written two blog posts about how they work:
Azure Server-side Encryption (SSE) and Azure Disk Encryption (ADE) - Part 1 of 2
http://terenceluk.blogspot.com/2021/05/azure-server-side-encryption-sse-and.html
Azure Server-side Encryption (SSE) and Azure Disk Encryption (ADE) - Part 2 of 2
http://terenceluk.blogspot.com/2021/05/azure-server-side-encryption-sse-and_8.html
What type of “Secrets” does Azure Key Vault Store?
The type of secrets that Azure Key Vault stores can be:
- A string of characters or numbers that serves as a password
- A certificate that is uploaded.
Note that #2 has been deprecated and will eventually be removed because of the certificate store feature. Attempting to use a secret to store a certificate will display the following message:
This feature has been deprecated. Click here to go to your list of certificates and import a new certificate.
An example of a service that would utilize the Azure Key Vault to store secrets would be an Azure App Service or Function that requires a place to safely store SQL Database connection strings, which contains information such as the credentials password. Rather than storing sensitive information in the application’s code, it can now use a URI to retrieve the string as a secret.
What type of “Certificates” does Azure Key Vault Store?
The Azure Key Vault provides management of x509 certificates that are used in many internet protocols with SSL/HTTPS being one of the most popular. Administrators are able to create self-signed and Certificate Authority generated certificates, as well as importing existing certificates. Certificate owners can implement secure storage and management of X509 certificates without interaction with private key material. Policies can be created to direct Key Vault to manage the life-cycle of a certificate and allow certificate owners to provide contact information for notification about life-cycle events of expiration and renewal of certificate. Certain level of automation for renewals are available selected issuers - Key Vault partner X509 certificate providers / certificate authorities.
An example of a service that would utilize the Azure Key Vault to store certificates can be an Azure Front Door service accessing the key vault to retrieve an X509 certificate to secure the frontend or an App Service similarly retrieving a certificate for its TLS/SSL binding.
----------------------------------------------------------------------------------------------------------------------------
With each feature described, I would like to provide the following diagram outlining the Azure Key Vault’s services and some resources that uses the service. Note that many services require one or more of Azure Key Vault’s services in order to secure their functionality or data.
Creating an Azure Key Vault
Creating an Azure Key Vault is fairly straight forward as there aren’t many configuration parameters available. The configuration settings that require consideration are as follows:
Key vault name
This value needs to be unique across all of the customers in Azure as the name will be used for the the access URL.
Region
The region placement of the key vault is important because you cannot move a key vault from one region to another and you cannot encrypt VMs with SSE or ADE if the Key Vault is not in the same region as the VM.
Pricing tier
There are two pricing tiers: Standard and Premium. The specifications for both versions are identical aside from Premium having the ability to use HSM-protected keys. Note that there is also a Managed HSM option that is not presented by the Azure Portal GUI but can be created through CLI or PowerShell (https://docs.microsoft.com/en-us/azure/key-vault/managed-hsm/quick-create-powershell#create-a-managed-hsm). I won’t be covering a Managed HSM in this post.
Soft-delete and Days to retain deleted vaults
Moving further down the Basics tab will display the Soft-delete and this is enabled by default with 90 days set. Losing keys, secrets, and certificates can mean losing access to services or data and having soft-delete provides a layer of protection against accidental deletion.
Purge protection
Purge protection is disabled by default but highly suggested to be enabled as this protects accidental purge of vaults as well as protection against malicious attempts to delete vaults and purge them in the event where there is unauthorized access.
The Access policy tab contains settings for the controlling access to the new key vault.
Enable Access to
The 3 access settings are not enabled by default but should be reviewed and enabled if the intention of the key vault is to be used with those services.
Azure Virtual Machines for deployment
Specifies whether Azure Virtual Machines are permitted to retrieve certificates stored as secrets from the key vault.
Azure Resource Manager for template deployment
Specifies whether Azure Resource Manager is permitted to retrieve secrets from the key vault. Instead of putting a secure value (like a password) directly in a template or parameter file, this value can retrieve the value from an Azure Key Vault during a deployment.
Azure Disk Encryption for volume encryption
Specifies whether Azure Disk Encryption is permitted to retrieve secrets from the vault and unwrap keys. Enabling this will allow ADE to use this key vault to store keys and secrets for BitLocker to encrypt a VMs.
Permission model
The permission model provides 2 methods of controlling access to the key vault.
Vault access policy
The default Vault access policies allows specific rights to be granted to an identity to operate with keys, secrets, and certificates. These settings are configured on a per vault basis and cannot be applied to Azure resource hierarchies such as Management Groups, Subscriptions, and Resource Groups.
The following are the specific rights that can be granted to an identity:
- Key, Secret, Certificate Management
- Key & Secret Management
- Secret & Certificate Management
- Key Management
- Secret Management
- Certificate Management
- SQL Server Connector
- Azure Data Lake Storage or Azure Storage
- Azure Backup
- Exchange Online Customer Key
- SharePoint Online Customer Key
- Azure Information BYOK
Azure role-based access control
Azure role-based access control, also known as Azure RBAC, is a more modern method to control access to the Key Vault that allows permissions to be granted based on predefined or custom created roles to an identity such as a user, group, service principal, or managed identity. Scope level such as management groups, subscriptions, and resource groups can be used as well
The following are RBAC Key Vault built-in roles for keys, certificates, and secrets access management:
- Key Vault Administrator
- Key Vault Reader
- Key Vault Certificate Officer
- Key Vault Crypto Officer
- Key Vault Crypto User
- Key Vault Crypto Service Encryption User
- Key Vault Secrets Officer
- Key Vault Secrets User
More information about the differences between the two types of permission model can be found here:
Migrate from vault access policy to an Azure role-based access control permission model
https://docs.microsoft.com/en-us/azure/key-vault/general/rbac-migration
As with other PaaS services, Service Endpoints and Private Endpoints are available:
Creating a Standard Azure Key Vault generally doesn’t take much time.
Azure Key Vault Keys
Once the Azure Key Vault is created, the first of the 3 types of objects is the Keys and as mentioned earlier in this post, these keys can be used for cryptographic operations like for SSE (CMK option) and ADE. To create a key for SSE or ADE, simply navigate to the Keys setting then click Generate/Import:
Options to create an RSA or EC keys with activation and expiration dates are presented:
Other than generating a key, Import and Restore Backup options are also available. These features are useful for scenarios for migrating services that previously stored encryption keys elsewhere into the key vault or restoring a backup if the key vault had been deleted:
The properties of the key can be reviewed by clicking onto the key:
The version of the key will be displayed and further details of the key can be reviewed by clicking on the version of interest:
Notice that it is possible to download the public key (this is an asymmetric key) but not the private key. It is also possible to modify the Activation date and Expiration date, and the Permitted operations on this key:
It is possible to back up the key:
Note the following message about where the backup can be restored:
The backup of this key will be encrypted to Azure Key Vault and can only be restored in Azure Key Vault within the same subscription. Please download and save this backup somewhere secure, as it will not be persisted following this browser session.
A .keybackup file will be available for download:
New versions of the key can be generated:
The options to generate a new key will be presented:
Then a new key will be generated and placed under CURRENT VERSION, while the previous key will be placed under OLDER VERSIONS:
With soft-delete enabled on the vault, any deleted keys will be recoverable with the Managed deleted keys within the retention configured:
Azure Key Vault Secrets
Secrets can be a string of characters for any service that needs to securely store the value (e.g. ARM template with an administrator password, an App Service with a SQL connection string). To create a secret, simply navigate to the Secrets setting then click Generate/Import:
As mentioned earlier, secrets used to be the service that can store certificates but the feature has since been deprecated:
Proceed to select Manual as the Upload options and configure the secret’s parameters as required:
The new secret will be displayed as such once created:
As with keys, versioning of the secret is provided:
Opening the properties of the secret will display configuration and the Secret Identifier of the secret which could be used by App Services to retrieve the secret from the key vault (permissions for the App Service will need to e configured):
Note how you can review the secret by clicking on the Show Secret Value button:
----------------------------------------------------------------------------------------------------------------------------
Example of how the Secret Identifier would be used for an App Service
The process of configuring an App Service to store and retrieve secrets in an Azure Key Vault is fairly straight forward so I would like to quickly demonstrate storing a SQL database connection string here.
Begin by creating an Azure Key Vault with Azure role-based access control as the Permissions Model:
You can also alternatively change the Permissions model of an existing Key Vault via the Access Policies configuration:
You won’t be able to browse the keys, secrets or certificates with Azure role-based access control set as the Permissions Model even though you may be an owner:
To correct this, grant yourself the Key Vault Administrator role via the Access Control (IAM):
With the Key Vault Administrator role assigned, you should now be able to browse the keys, secrets, and certificates:
Proceed to create a secret with the SQL connection string, open the secret and copy the Secret Identifer:
https://my-test-keyvault01.vault.azure.net/secrets/appService-to-SQLDB/e49822276fab4f28ac24a75bbfb5e104
Proceed to add the secret identifier reference to the Azure App Service Settings by opening the App Service configuration settings, then click on New Connection String:
Type the Name of the connection string (you can use the same name as the secret name in the key vault, configure the Value as:
@Microsoft.KeyVault(SecretUri=<Value of the Secret Identifier>)
For example:
@Microsoft.KeyVault(SecretUri=https://my-test-keyvault01.vault.azure.net/secrets/appService-to-SQLDB/e49822276fab4f28ac24a75bbfb5e104)
Next, we’ll need to grant the App Service permissions to access the secret in the key vault by using a System assigned identity. Proceed to select the Identity setting in the App Service, under the System assigned tab, turn on the Status:
Note the message indicating the app service will be registered with Azure Active Directory so it can be granted permissions to access resources protected by Azure AD (Azure role-based access control set as the Permissions Model for the key vault):
Proceed to click on Azure role assignments to assign permissions to the App Service:
Click on Add role assignment:
Grant the permissions to the App Service:
Scope: Key Vault
Subscription: <the subscription>
Resource: <the key vault>
Role: Key Vault Secrets User
With the connection string configured on the App Service, the connection string contents of the web.config can now be cleared.
----------------------------------------------------------------------------------------------------------------------------
Similar to keys, secrets can also be backed up. Instead of a .keybackup file, a .secretbackup file is created:
Attempting to open the backup file will display a series of scrambled text even though there is only 1 secret stored in the backup:
Another example of how a secret is used is for Azure Disk Encryption to store its secrets. Below is a screenshot of an Azure Key Vault used by ADE to store BitLocker BEKs (BitLocker Recovery Key):
Opening the secret will allow you to browse the BitLocker Recovery Key (BEK) details:
Azure Key Vault Certificates
The last object that the key vault stores are certificates. To create a certificate, simply navigate to the Certificates setting then click Generate/Import:
The Create a certificate menu will provide various certificate options:
The ability to generate a certificate request or import a certificate (PFX or PEM):
If a new certificate is to be created there are 3 options:
- Self-signed certificate
- Certificate issued by an integrated CA – Only DigiCert and GlobalSign are currently supported (https://docs.microsoft.com/en-us/azure/key-vault/certificates/create-certificate#partnered-ca-providers)
- Certificate issued by a non-integrated CA
Lifecycle management can be managed by the Lifetime Action Type where the following options are available:
- Automatically renew at a given percentage lifetime
- Automatically renew at a given number of days before expiry
- E-mail all contacts at a given percentage lifetime
- E-mail all contacts at a given number of days before expiry
The automatically renew options will be dependent on whether the certificate was generated from an integrated CA.
Additional advanced policy configuration are available for the certificate:
The following is a request generated for a non-integrated CA:
Navigating into the request will allow you to browse the certificate request information:
Navigating back out to the Overview section and clicking on Certificate Operation will allow you to download the CSR as well as merge the signed request the signing CA provides:
Another method of place certificates into the key vault is to import a PEM or PFX. The following is an example of importing a PFX:
With the certificate imported in the key vault, we can now allow resources such as App Services to import the certificate from the key vault. Before proceeding to import the certificate, we’ll need to grant the App Service the required RBAC role to retrieve the certificate and this process and the role required is the Key Vault Secrets User. Once the appropriate role is assigned to the App Service, use the Import Key Vault Certificate feature under the Private Key Certificates (.pfx) tab to import the certificate from the key vault:
----------------------------------------------------------------------------------------------------------------------------
Note that if you attempt to import a certificate from a key vault that is not in the same region as the App Service then the process will fail with the following message with no other detail:
Import Key Vault Certificate
Failed to import Key Vault Certificate
----------------------------------------------------------------------------------------------------------------------------
Other services such as Azure Front Door can also leverage key vaults to import certificates:
How many Key Vaults should an organization have?
Microsoft general guideline is to have 1 key vault per application, per environment, per region. With that said, this can quickly grow to many key vaults in a large environment.
How can an organization manage Key Vaults at scale?
When a large organization has many key vaults distributed across the Azure because of the amount of applications and divisions, it is suggested to use Azure Policy manage organization compliance and set standards such as key sizes and validity periods. Auzre Policy can be applied to a scope within the organization (managemend group, subscription, resource group or individual key vault) and ensure all resources within the scope to be evaluated for compliance against the rule. Policies can be configured to only evaluate whether the resource meets a compliance rule or not, or enforce compliance and block the creation or import of objects that don’t meet the policy rule.
I will not go further into the details and will provide the following Microsoft document:
Integrate Azure Key Vault with Azure Policy
https://docs.microsoft.com/en-us/azure/key-vault/general/azure-policy?tabs=certificates
----------------------------------------------------------------------------------------------------------------------------
I hope this post is able to help anyone who may be looking for more information about how Azure Key Vault works, what the differences are between keys, secrets, and certificates, and what the configuration looks like.
No comments:
Post a Comment