Long story short: the Hawaii emergency agency password was written on a Post-it note and made it onto a photo that went viral on the Internet. Not the kind of notoriety any of us are hoping for.

But we witness this type of risky behavior daily across many teams and organizations – passwords on Post-it notes stuck to desks and monitors, or, usernames and passwords shared on OneNote or sent via email as clear text. All it takes is for a photo to be posted on the Internet or someone’s computer getting compromised and before we know it, security breaches and data leaks make headlines.

So how do teams share secure information – passwords, API Keys, cryptographic keys, certificates – in applications deployed on the cloud? The answer many teams came up with in the past was to check-in this information into source control. But this approach is fraught with the same risks as storing this secure information on individual computers, except on a larger scale. Ever heard of malicious bots that scan public repositories for secrets checked-in with code?

Azure Key Vault is a software-as-a-service solution engineered with management of secrets as a primary goal. Azure Key Vault handles creation, storage, and sharing of secrets and keys and also provides certificate management. Unlike other Azure resources, where the data is stored in general storage, Azure Key Vault is backed by a Hardware Security Module (HSM).

Azure Key Vault not only makes it easy for secret management but also applies security at both the management plane and the data plane. Creation and deletion of the key vault, access control to the key vault and setting key vault properties are handled at the management plane level and keys, secrets, and certificates are created, retrieved and deleted in the data plane. Both management and data planes are secured with Azure Active Directory (Azure AD) authentication. In the management plane, Role-Based Access Control (RBAC) is used for authorization while the data plane uses access policies for authorization.

Azure Key Vault handles the following type of secrets:

  1. Keys: These are cryptographic keys in the format of JSON Web Key. Key Vaults support both soft keys and hard keys. Soft keys are processed by software but encrypted by a system key in an HSM. Hard keys are directly stored in an HSM.
  2. Secrets: Azure Key Vault stores secrets in the format of strings. One way to think about these secrets is secrets that are often stored in web.config or app.config files of ASP.NET apps like API keys, credentials, passwords and token symmetric keys. Secrets can be enabled to disabled at individual secret levels and set to be “good” for certain time intervals (if needed) as dictated by nbf and exp attributes which provides a lot of flexibility in controlling access to secrets.
  3. Certificates: Azure Key Vault stores self-signed or Certificate-Authority (CA) X509 certificates. A Key Vault certificate owner can implement secure storage and management of X509 certificates without interaction with private key material and manage the life-cycle of a certificate. Automatic renewal of certificates with selected issuers – Key Vault partner X509 certificate providers/certificate authorities is also supported.
  4. Storage Account Keys: Systems using Azure Storage can leverage Azure Key Vault to sync keys with a storage account that allows key exchange behind the scenes aka no keys in request-response type scenarios. Also, the Key Vault handles regeneration of keys periodically.

So consider the standard scenario: you have an Azure web app that connects to an Azure SQL database. How does the password storage and exchange look in this scenario?

Step 1: Add the database password to key vault (shown below). Bonus points: if you create the key vault with ARM template or Terraform and store the auto-generated password directly from your Azure DevOps pipeline into the key vault right after creation.

 

Step 2: Hookup your Azure DevOps pipeline to Azure Key Vault.

 

Step 3: Create your Azure SQL database using the password from the key vault. When this finishes executing you have an Azure SQL database with admin user password stored in key vault. The only people and applications accessing this password would have to be explicitly allowed (and audited) by the Azure Key Vault.

 

Step 4: Turn on Managed Service Identity (MSI) for your web application.

Step 5: Enable the web app to connect to the key vault using the MSI.

Step 6: Profit. No. Seriously. At this point, you have a web application that has access to a key vault containing the password to connect to the database.

If you made it this far, and want a TLDR; on this post let it be this:

Don’t be like this guy. Use Azure Key Vault to secure and distribute your keys, secrets, and certificates, preferably in an automated repeatable manner with Azure DevOps.

Whether your applications are on Azure or on-premises, you can leverage Azure Key Vault to enable greater security and having expert guidance never hurts. New Signature has the experts in-house to guide you along the way and provide help and training to ensure success.