Azure Key Vault
Tags: azure, cybersecurity, cloud, architecture
Published: 2024-02-28 01:05:36

When building our cloud solutions, we constantly face security-related questions. "Where should I store my database credentials?" "How can I implement my certificate to establish secure communication?" "How should I store the key used to encrypt my files in a blob storage?" These are some questions that arise. To answer these questions, the response is the same: by using **Azure Key Vault**.

---

## What is it used for?

In the introduction, I mentioned some functions for which Azure Key Vault can be used, but in this section, we'll describe them in more detail.


![Azure Key Vault capabilities](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/uz4j7b90r1vsmijxme6c.png)

Vaults (not restricted only to Azure Key Vault, but also solutions like Hashicorp Vault) are used to securely store and access sensitive credentials and protect access to them.

Azure Key Vault is mainly used with 3 types of resources: **keys**, **secrets**, and **certificates**.

**Keys** - are used to encrypt data in other services (e.g., storage accounts, Cosmos DB, SQL Database, etc.);

**Secrets** - can be various things such as passwords, API Keys, and other information that should have protected public access;

**Certificates** - used to establish secure communications and authentications; we can manage the lifecycle of objects within the vault.

The objects mentioned above and managed by the Key Vault can have their lifecycle controlled by the resource (within existing limitations). Certificates can be created and deleted, keys can be created, rotated, and deleted, secrets can be updated, and so forth.

> We understand the basic resources of Azure Key Vault, but now, what is it used for?


![Application using Azure Key Vault](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ysic18bvynhi9tjay1jx.png)

The diagram above shows the most common use case scenario for Azure Key Vault. We see an application consuming not only a **secret** stored in the vault (used to access a database) but also consuming a **certificate** (used for TLS communication establishment).


![Storage Account using Azure Key Vault](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/sfhf365l7ip9r7xzv46h.png)

In the second scenario shown above, we see an Azure Storage Account consuming a **key** stored in Azure Key Vault to encrypt the existing blobs within it.

These are two of the most common usage scenarios for the vault, but they are not limited to these. You can use a vault as you see fit, as long as the proposed solution meets your demand.

---

## Architecture
Being a PaaS (Platform as a Service), we have nothing to manage regarding Key Vault infrastructure, but its functions are segregated so that we have a management panel and a panel for accessing the data contained in the vault.


![Azure Key Vault's management and data planes](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/fvrdepslwvd3vplm0zjy.png)

This division between the **management plane** and the **data plane** is not visible to end users (developers, architects, engineers, etc.), but it is highly influential when we think about access control (the subject of the next section).

The architecture designed for Azure Key Vault allows us to have greater control and security over our data and who accesses it.

---

## Access Control
Still on the theme that concluded the last section, the access control model for Azure Key Vault is slightly different from what we are used to finding in other resources.

As designed, it is possible to separate the use of vault managers and consumers, thus establishing more effective granular control of the responsibilities of each of the actors.

The **management plane** is responsible for managing all aspects of the vault's operation, such as its properties, access permissions, secret configurations, keys, and certificates. The **data plane** enables access to valuable information in the resource, such as the values of secrets, keys, and certificates stored.


![Azure Key Vault's planes capabilities](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/jlg40mha4cfixfcdub34.png)

As we can see in the simple diagram above, the granularity of permissions existing in the **data plane** allows greater control over what an identity can do on a particular type of object. This granularity does not exist in the RBAC of the **management plane**, as it implements much of the existing roles in other Azure resources (e.g., contributor, reader, admin, etc.).

This model allows applications to receive only the necessary accesses to perform operations on the object in question. It is not necessary to provide the application with visibility into other things in the vault, much less the vault itself. Access is made directly to the necessary resource, without passing through any other "barrier."

---

Vault solutions are extremely useful when we are building our cloud solutions. Solutions like Hashicorp Vault, AWS KMS, and Azure Key Vault offer ways to keep access to information secure, following best practices in cloud solution architecture.

I hope you enjoyed the text and that in some way I have been able to help you understand the functionalities of the vault as well as the ways in which it can be used in your solutions.

See you soon!