As you might know, Azure Key Vault is a set of repositories one can use to store key/value pairs of secrets, certificates etc. in order to facilitate the maintenance of this information. Key Vault comes with “Keys” and “Secrets” but I’m only going to focus on the “Secrets” part. Storing secrets is an easy game as you can achieve this using the Azure Key Vault Cmdlets (https://msdn.microsoft.com/en-us/library/dn868052.aspx) that allow you to interact with the Vault. But once you’ve stored all the secrets, you need to make them available to applications.  Vault makes this possible by granting the SPN corresponding to the Azure AD App,  access to the Vault via theSet-AzureRmKeyVaultAccessPolicycmdlet.

So far so good but which approach should we adopt? There are several possibilities among which, granting access to Key Vault directly to the business Azure Active Directory App. While this approach works, it is not the most effective for the following reasons:

• Granting access directly to the business App will end-up in a chaos once you’ll have a lot of different apps. You’ll also need to grant each of this apps individual access to the Vault which will make the maintenance tedious.
• At Azure AD App level, one can create secrets and associate permissions to the Appbut you can’t restrict a given secret to a specific set of permissions. In order to access Key Vault, you must create a secret so that the App can use the ClientCredential flow, but since the secret you create isn’t restricted specifically to Key Vault, it also allows developers to access other resources, and therefore, they could as well bypass Key Vault to consume theses resources, and that’s not really what you intended.

Moreover, if, as I suggested in another blog post (http://www.silver-it.com/node/203), you extend the duration of the secret that allows you to access Key Vault, developers could simply consume the other resources (Exchange, AD etc.) with that very same secret, and this, during a longer time.

Therefore, for maintenance and security reasons, I recommend creating a dedicated Azure AD Application that has no permission other than accessing Key Vault. With that single App, you only need to register the app once for all with SetAzureRmKeyVaultAccessPolicy. For each and every business application that will need an access to the Vault, you create a corresponding secret in the dedicated App that you can revoke at any time without impacting the other business applications. You can specify a longer duration for each secret so that access to the Vault is guaranteed and you only distribute the ids of the secrets created in the Vault that hold the information that is relevant to each business app. By the way, I recommend using a non-predictive naming convention when creating secrets in the Vault, so the easiest is probably to use GUIDs. By combining the use of GUIDs + only granting the “Get” secret permission (not the list one), you should be safe enough and developers will unlikely be able to retrieve secrets from other applications, plus, they will have to connect to Key Vault first in order to retrieve secrets that give them access to the other resources.

Well, the latter is partially true as I already hear you saying : “once I know the name of the secret in the Vault, I can retrieve its value, store it somewhere and directly consume my resource next time”. Yes, technically this is feasible although code-reviews could help mitigate that problem, but don’t get me wrong here, I’m not trying to find a way that makes impossible to unveil secret values because as matter of fact, the business app MUST retrieve it to get tokens to resources, so hiding the secret is impossible but the benefits of this approach will be the following:

• You’ll have a centralized way of managing secrets and certificates expiration by renewing them directly in the Vault without changing their associated secret id.
• You’ll have a central Azure AD app from which you can add/revoke access to business applications. This facilitates a lot the maintenance.
• If developers go get a secret value and bypass the vault afterwards, their application will fail as soon as the secret expires and their only way to make it work again, is to retrieve the info from the Vault that will be up to date. So, it will be in the interest of any business application developers to work with the Vault.

Of course, you can also operate a segregation by creating multiple vaults but you could replicate the above model to each of these vaults.

About the Author: