Getting Started Hands-on with Azure Key Vault

When building applications, managing sensitive information like passwords, API keys, and certificates securely is critical. Azure Key Vault provides a simple yet powerful way to centralize secrets management, reduce exposure, and enforce security best practices. In this post, we’ll walk step by step through creating an Azure Key Vault and storing your first secret.

---

What is Azure Key Vault?

Azure Key Vault is a cloud-based service for securely storing and managing secrets, encryption keys, and certificates. It helps developers and administrators:

• Keep sensitive information away from application code.
• Control access with role-based access control (RBAC) and policies.
• Integrate with Azure services, DevOps pipelines, and applications seamlessly.

---

Prerequisites

Before you start, make sure you have:

• An active Azure subscription.
• Key Vault Contributor role to create a key vault.
• Access to the Azure portal (https://portal.azure.com).
• (Optional) The Azure CLI installed if you prefer command-line operations.

---

Step 1: Create a Key Vault in the Azure Portal

1. Log in to the Azure portal.
2. In the top search bar, type Key Vaults and select it from the results.
3. Click + Create to start the Key Vault creation wizard.
4. Fill in or select the following in the Basics tab:
5. Subscription: Select your active Azure subscription.
6. Resource Group: Choose an existing resource group or create a new one.
7. Key Vault Name: Enter a globally unique name (alphanumeric, no spaces).
8. Region: Select East US.
9. Pricing tier: Choose Standard.
10. Days to retain deleted vaults: 90.
11. Purge protection: Disabled.
12. Fill in or select the following in the Access configuration tab:
13. Permission model: Select Azure role-based access control (RBAC) (recommended).
14. Tip: Later, assign the required RBAC role (for example, Key Vault Secrets User) to your user or application identity under Access control (IAM).
15. Resource access: Leave all options (VM deployment, ARM template deployment, Disk Encryption) unselected unless you specifically need them.
16. Fill in or select the following in the Networking tab:
17. Enable public access: Yes.
18. Public Access → Allow access from: All networks.
19. Review + Create: Validate your settings
20. Click Create. Deployment usually completes in a few seconds.

---

Step 2: Assign RBAC Role (Permissions)

Before you can add or read secrets, you must assign yourself the correct role.

1. Navigate to your Key Vault in the Azure portal.
2. In the left menu, select Access control (IAM).
3. Click + Add role assignment.
4. For this walkthrough, assign Key Vault Administrator as it gives you full control. But for production, use one of the following:
   • Key Vault Secrets Officer → create/update/delete secrets.
   • Key Vault Secrets User → read secrets only.
5. Assign the role to your user account (for local testing).
6. Wait a few minutes for the assignment to take effect.

✅ Best practice: In production, assign only the role required by your application or user (Principle of Least Privilege).

---

Step 2: Add a Secret

On the Create a secret page, fill in or select the following:

1. Upload options: Manual.
2. Name: For example, DbPassword.
3. Secret value: Enter the secret string, e.g., MySecurePass123!.
4. Content type (optional): Add a description or format hint if needed.
5. Set activation date: (Optional) — choose a date when the secret becomes valid.
6. Set expiration date: (Optional) — choose a date when the secret should expire.
7. Enabled: Select Yes (default) to make the secret available.
8. Tags: (Optional) — add tags to help organize and identify secrets.

Click Create.

---

Step 3: Retrieve the Secret (Azure Portal)

1. Go back to the Secrets section of your Key Vault.
2. Select the secret name (e.g., DbPassword).
3. Under Current Version, click to show the secret value.

This is useful for manual testing, but most apps will access secrets programmatically.

---

Step 4: Retrieve the Secret (Azure CLI)

If you like command-line tools, try:

# Log in if not already
az login

# Get the secret
az keyvault secret show \
  --vault-name MyVaultName \
  --name DbPassword \
  --query value \
  -o tsv

This will return the stored value securely.

---

Step 5: Use Key Vault in Applications

Applications can access secrets using:

• Managed Identities (recommended): No credentials are hardcoded, Azure handles identity automatically.
• SDKs and REST APIs: Use libraries like Azure.Security.KeyVault.Secrets for .NET, Python, or Java.

Example in C# (.NET):

var client = new SecretClient(
    new Uri("https://<YourVaultName>.vault.azure.net/"),
    new DefaultAzureCredential());

KeyVaultSecret secret = await client.GetSecretAsync("DbPassword");
string secretValue = secret.Value;

---

Best Practices

• Use RBAC over access policies for finer control and scalability.
• Turn on soft delete and purge protection for better recovery.
• Avoid hardcoding secrets in code or config files.
• Automate with ARM/Bicep/Terraform to standardize vault creation across environments.

---

Wrapping Up

You’ve now created your first Azure Key Vault, stored a secret, and learned how to retrieve it. This is the foundation for securing sensitive information in the cloud. In upcoming posts, we’ll look at how to integrate Key Vault with applications and CI/CD pipelines, so you can secure secrets at scale.

---

Bonus: Secrets vs. Keys vs. Certificates in Azure Key Vault

Azure Key Vault can store and manage three major object types:

1. Secrets

• Arbitrary strings such as API keys, connection strings, passwords, or endpoints.
• Best for values your app needs to read as-is.
• Example: A Computer Vision subscription key or endpoint URL.

2. Keys

• Cryptographic keys (RSA, EC, etc.) used for encryption, signing, or key wrapping.
• You don’t usually retrieve the private key — instead, you call Key Vault to perform crypto operations without ever exposing the key.
• Example: Signing a JWT, encrypting/decrypting sensitive data, or managing keys for disk encryption.

3. Certificates

• X.509 certificates, typically backed by keys inside Key Vault.
• Used for TLS/SSL, service authentication, or client certificates.
• Example: Managing SSL certificates for a web app with a custom domain.

---

🔒 When to use Keys or Certificates instead

• Keys → When you need Azure to handle encryption, decryption, or signing (e.g., database encryption, token signing).
• Certificates → When you need secure lifecycle management of TLS/SSL certs (e.g., web apps, service-to-service authentication).