What is Azure Key Vault?

Microsoft Azure is a leader in cloud computing, transforming the way organizations manage their digital infrastructure. An important aspect of Azure’s security framework is the management of sensitive data, commonly known as “secrets”. Azure Key Vault is a service designed for the secure handling of these secrets, offering tools for storing, accessing, and managing confidential information in the cloud.

What is Azure Key Vault?

Azure Key Vault is a cloud service for managing, retrieving, and storing sensitive information such as database credentials, API keys, and other secrets. It helps in securing access to applications, services, and IT resources without hard-coding sensitive information in plain text.

Key features

• Secure storage: Azure Key Vault offers highly secure storage for secrets, keys, and certificates, encrypted both in transit and at rest.
• Seamless integration: It integrates effortlessly with other Azure services and applications, enhancing overall security architecture.
• Access control: Azure Key Vault allows fine-grained access control with Microsoft Entra and access policies.

Creating Azure Key Vault secrets

Azure Key Vault secrets can be created via the Azure CLI. Before creating secrets in Azure, you must first make sure you have the Azure CLI installed. Once you have installed the Azure CLI, run the az login command to authenticate to your Azure account.

# Example az login interaction and output
$ az login
To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code LZURMHUR9 to authenticate.
[
  {
    "cloudName": "AzureCloud",
    "homeTenantId": "706….",
    "id": "028….",
    "isDefault": true,
    "managedByTenants": [],
    "name": "Subscription Name",
    "state": "Enabled",
    "tenantId": "706….",
    "user": {
      "name": "your@username.com",
      "type": "user"
    }
  }
]

Create a secret via the CLI

Before creating a secret, you must first create both a resource group and a Key Vault resource.

You can create a resource group using the az group create command:

$ az group create --location westus --name MyResourceGroup
{
  "id": "/subscriptions/028…/resourceGroups/MyResourceGroup",
  "location": "westus",
  "managedBy": null,
  "name": "MyResourceGroup",
  "properties": {
    "provisioningState": "Succeeded"
  },
  "tags": null,
  "type": "Microsoft.Resources/resourceGroups"
}

You can create a Key Vault using the az keyvault create command. Note that Key Vault names are globally unique, so you will need to replace the value of <YourVaultName> below with a unique name for your resource:

# The example output has been truncated for easier visualization
$ az keyvault create --name <YourVaultName> --resource-group MyResourceGroup

{
  "id": "/subscriptions/028…/resourceGroups/MyResourceGroup/providers/Microsoft.KeyVault/vaults<<YourVaultName>",
  "location": "westus",
  "name": "<YourVaultName>",
  "properties": {
    ….
  },
  "resourceGroup": "MyResourceGroup",
  ….
  "tags": {},
  "type": "Microsoft.KeyVault/vaults"
}

Now that you have your resource group and Key Vault created, you can create a secret by running the az keyvault secret set command:

$ az keyvault secret set --vault-name <YourVaultName> --name MySecretName --value MySecretValue

{
  "attributes": {
    "created": "2023-11-28T19:01:35+00:00",
    "enabled": true,
    "expires": null,
    "notBefore": null,
    "recoveryLevel": "Recoverable+Purgeable",
    "updated": "2023-11-28T19:01:35+00:00"
  },
  "contentType": null,
  "id": "https://<YourVaultName>.vault.azure.net/secrets/MySecretName/88d5668ebe7447c0af796ed",
  "kid": null,
  "managed": null,
  "name": "MySecretName",
  "tags": {
    "file-encoding": "utf-8"
  },
  "value": "MySecretValue"
}

Verify the secret was created with the az keyvault secret list command.

$ az keyvault secret list --vault-name <YourVaultName>

[
  {
    "attributes": {
      "created": "2023-11-28T19:01:35+00:00",
      "enabled": true,
      "expires": null,
      "notBefore": null,
      "recoveryLevel": "Recoverable+Purgeable",
      "updated": "2023-11-28T19:01:35+00:00"
    },
    "contentType": null,
    "id": "https://<YourVaultName>.vault.azure.net/secrets/MySecretName",
    "managed": null,
    "name": "MySecretName",
    "tags": {
      "file-encoding": "utf-8"
    }
  }
]

Accessing Azure Key Vault secrets

Now that you have created an Azure Key Vault secret, you can access the value via the Azure CLI using the az keyvault secret show command.

$ az keyvault secret show --name MySecretName --vault-name <YourVaultName>
{
  "attributes": {
    "created": "2023-11-28T19:01:35+00:00",
    "enabled": true,
    "expires": null,
    "notBefore": null,
    "recoveryLevel": "Recoverable+Purgeable",
    "updated": "2023-11-28T19:01:35+00:00"
  },
  "contentType": null,
  "id": "https://<YourVaultName>.vault.azure.net/secrets/MySecretName/88d5668ebe7447c0af796ed",
  "kid": null,
  "managed": null,
  "name": "MySecretName",
  "tags": {
    "file-encoding": "utf-8"
  },
  "value": "MySecretValue"
}

Best practices

• Regularly rotate secrets: Implement a strategy for the regular rotation of secrets.
• Provide least-privilege access: Minimize the number of entities with access to the Key Vault.
• Monitor access and usage: Use Azure Monitor and Azure Security Center to track access and activities.

Challenges and considerations

Azure Key Vault, while a powerful tool for managing secrets and cryptographic keys, does come with its own set of challenges, considerations, and limitations. Some of the key aspects to be aware of include:

• Service limits: Azure Key Vault has specific service limits that apply to both Vaults and Managed HSMs (Hardware Security Modules). These limits include the maximum number of transactions allowed in a given time frame, such as key creation and retrieval operations. Exceeding these limits can result in throttling, indicated by a 429 HTTP status code​​.
• Vault management and access control: Access to a Key Vault requires proper authentication and authorization. Authentication is done via Microsoft Entra ID, while authorization can be managed via Azure role-based access control (RBAC) or Key Vault access policy. This layered approach to security necessitates careful management to ensure that only authorized users or applications have access to the stored secrets​​.
• Network security options: Azure Key Vault allows for network security configurations to limit vault access by IP address or range, with further restrictions possible through firewall rules. These rules include options for trusted services, specific IP addresses and ranges, virtual networks using dynamic IP addresses, and private links. Such configurations require careful planning to ensure they align with an organization’s security policies​​.
• Backup limitations: Azure Key Vault does not support the backup of an entire vault simultaneously. Instead, users must manually back up each key, secret, or certificate within the vault. This can be a significant consideration for organizations with extensive key and secret management needs, as it necessitates a more hands-on approach to backup and recovery processes​​.
• Vault segmentation strategy: It is recommended to use separate key vaults for each specific application or environment (development, pre-production, production) to reduce risk and limit the sharing of keys and secrets across different environments. This approach, while enhancing security, can add complexity to the management of multiple vaults, especially in larger organizations with numerous applications and environments​​.

These considerations highlight the importance of understanding Azure Key Vault’s capabilities and limitations in order to effectively incorporate it into an organization’s cloud security strategy. Proper planning, configuration, and management are essential to leverage the full benefits of Azure Key Vault while mitigating potential risks and challenges.

Conclusion

The hard part of Azure Key Vault is not storing a secret, it’s everything that surrounds it: who can reach the vault, how access is authenticated and authorized, how secrets get rotated, and how vaults are segmented across applications and environments. Treat the vault as one piece of your infrastructure rather than a manual side task, and define it, its access policies, and the secrets it holds the same way you define the rest of your cloud resources. When the vault is described as code, its security boundaries become reviewable and repeatable instead of something a person has to remember to configure correctly.

You can manage Azure Key Vault secrets as code with Pulumi, and centralize secrets across environments with Pulumi ESC. The Pulumi community on Slack is open for questions and discussion.