Get Even More Visitors To Your Blog, Upgrade To A Business Listing >>

Create key vault and secrets with access policies in Microsoft Azure

Azure Key Vault is a cloud service used to manage keys, secrets, and certificates. Key Vault eliminates the need for developers to store security information in their code. It allows you to centralize the storage of your application secrets which greatly reduces the chances that secrets may be leaked. Key Vault also allows you to securely store secrets and keys backed by Hardware Security Modules or HSMs. The HSMs used are Federal Information Processing Standards (FIPS) 140-2 Level 2 validated. In addition, key vault provides logs of all access and usage attempts of your secrets so you have a complete audit trail for compliance.

Azure key vault helps in below ways.

Enhance data protection and compliance
Secure key management is essential to protecting data in the cloud. With Azure Key Vault, you can safeguard encryption keys and application secrets like passwords using keys stored in hardware security modules (HSMs). For added assurance, you can import or generate your encryption keys in HSMs. If you choose to do this, Microsoft will process your keys in FIPS 140-2 Level 2 validated HSMs (hardware and firmware). Key Vault is designed so that Microsoft does not see or extract your keys. Monitor and audit key use with Azure logging–pipe logs into Azure HDInsight or your SIEM for additional analysis and threat detection.

All of the control, none of the work
With Key Vault, there's no need to provision, configure, patch, and maintain HSMs and key management software. You can provision new vaults and keys (or import keys from your own HSMs) in minutes and centrally manage keys, secrets, and policies. You maintain control over your keys–simply grant permission for your own and third-party applications to use them as needed. Applications never have direct access to keys. Developers easily manage keys used for Dev/Test and migrate seamlessly to production keys managed by security operations.

Boost performance and achieve global scale
Improve performance and reduce the latency of cloud applications by storing cryptographic keys in the cloud instead of on-premises. Key Vault rapidly scales to meet the cryptographic needs of your cloud applications and match peak demand without the cost associated with deploying dedicated HSMs. You can achieve global redundancy by provisioning vaults in Azure global datacenters–keep a copy in your own HSMs for added durability.

To start deploying service search for Key vaults in the top-middle search bar on Azure Portal. 

Choose Subscription, Resource group (if already created else create new). Provide Key vault name, Vault name must only contain alphanumeric characters and dashes and cannot start with a number. The name selection should be unique, or you might see error message simmilar to The name '' is already in use, or is still being reserved by a vault which was previously soft deleted. Please use a different name. Choose the region and pricing tier, Azure Key Vault service is offered in two service tiers: standard and premium

Recovery options: Soft delete protection will automatically be enabled on this key vault. This feature allows you to recover or permanently delete a key vault and secrets for the duration of the retention period. This protection applies to the key vault and the secrets stored within the key vault.

To enforce a mandatory retention period and prevent the permanent deletion of key vaults or secrets prior to the retention period elapsing, you can turn on purge protection. When purge protection is enabled, secrets cannot be purged by users or by Microsoft.

Soft-Delete: It has the ability to turn off soft delete via the Azure Portal has been deprecated. You can create a new key vault with soft delete off for a limited time using CLI / PowerShell / REST API. The ability to create a key vault with soft delete disabled will be fully deprecated by the end of the year.

Days to Retain deleted vaults: It can be configured to between 7 to 90 days. Once it has been set, it cannot be changed or removed.

Enabling "Purge protection" on a key vault is an irreversible action. Once the purge protection property has been set to "true", it cannot be changed or removed. I will keep the default option Disable purge protection (allow key vault and objects to be purged during retention period)

Click Next: Access Policy.

There are various option to configure Access Policy and which will help and organize access to Key vault. Here I am leaving the options as it is. By default my user id is added to access policy with full access. Click Next: Networking.

You can connect to this key vault either publicly, via public IP addresses or service endpoints, or priviatily using a private endpoint. Networking connectivity method I am keeping is Public endpoint (all network). Click Next: Tags

Tags are name/value pairs that enable you to categorize resources and view consolidated billing by applying the same tage to multiple resources and resource groups. Click Next: Review + create.

Review the setting configured, Once validation passed, click create button.

It takes few minutes to azure service deployment, either click go to resource or check the key vault resource under Resource group.

Inside the key vault I will create a Secret (store a password value), Click Secrets and press + Generate/Import.

In the create a secret wizard Upload options is set to Manual (There are two option Manual and certificate). Provide secret a Name (Secret names can only contain alphanumeric characters and dashes) and Value (The Azure Portal currently only supports single-line secret values. Use Azure PowerShell to set multi-line values.). Content type (description) is optional. Set activation date is Sets when this resource will become active. This sets the 'nbf' property on the resource. Set expiration date is Sets when this resource will become active. This sets the 'nbf' property on the resource. Click Create button.

Once secret is created double click it and go to Current Version then show secret value. Here basic key vault with secret is configured.

Next I will configure Access Policy which I didn't configured while deploying Key Vault. A Key Vault access policy determines whether a given security principal, namely a user, application or user group, can perform different operations on Key Vault secrets, keys, and certificates,  Also another options are to specify Azure Virtual Machines for deployment, Azure Resource Manager for template deployment and Azure Disk Encryption for volume encryption.

Click Access policies on the key vault and then press + Add Access Policy.

I have created a user vaultviewer in Azure Active Directory (this user principal doesn't have any access/rights/privideges on Azure). I will use it to login and access key vault secret.

Creating a new user in Azure AD using oneliner PowerShell and Azure CLI.

In the Add access policy, Configure from template (optional) is set to Secret Management. Secret Permissions are set to Get and List. Select vaultviewer user in the principal. click Add.

Next Add role assignment under Access control (IAM), In the Role choose Key Vault Reader, Assign access to User, group or service principal and select AzureAD user vaultviewer. Click Save.

Key vault reader can only read metadata of key vaults and its certificates, keys, and secrets. Cannot read sensitive values such as secret contents or key material. Only works for key vaults that use the 'Azure role-based access control' permission model.

Check and verify in the View my access that vaultviewer has key vault reader has access correctly applied on the selected powershellkeys key vault.

Azure Key vault is deployed and configured successfully. Next I will test it with Powershell az module. To login I am using vaultviewer user.

Powershell Azure Az module Install-Package cannot convert value 2.0.0-preview to type system.version 

#Login to Azure using Powershell az module

#Get list of KeyVault List and Note down the Vault Name

With below script I can easily get the stored secret password information.

#Get the Secret list in the Azure Key vault
Get-AzKeyVaultSecret -VaultName powershellkeys

#Get the Azure key vault secret information & know the securestring Secret password stored inside the secret
$secret = Get-AzKeyVaultSecret -VaultName powershellkeys -Name vCenter
$key = ConvertFrom-SecureString

#Decode and convert the secure string secret password into readable format
$BSTR = [System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($secret.SecretValue)
$password = [System.Runtime.InteropServices.Marshal]::PtrToStringAuto($BSTR)

Useful Articles
Create and manage Azure budgets
Connect-AzAccount The 'Connect-AzAccount' command was found in the module 'Az.Accounts', but the module could not be loaded
Microsoft Azure Rest API using PowerShell
Microsoft Azure Rest API using PowerShell Part 2
AzCopy copy transfer fails with 403 This request is not authorized to perform this operation using this permission
Azure azcopy login error Selected user account does not exist in tenant 'Microsoft Services' and cannot access the application '579a7132-0e58-4d80-b1e1-7a1e2d337859'

This post first appeared on Tales From Real IT System Administrators World And Non-production Environment, please read the originial post: here

Share the post

Create key vault and secrets with access policies in Microsoft Azure


Subscribe to Tales From Real It System Administrators World And Non-production Environment

Get updates delivered right to your inbox!

Thank you for your subscription