Existing (Azure Functions) application
There is a misconception that Arcus is not available in Azure Functions. For the sake of this exercise, we will show you how an existing Azure Function HTTP trigger can be altered to use Arcus Security to retrieve its secrets.
Let’s first start with the basics: we have an Azure Functions HTTP trigger application that reads environment variables and connects to an Azure Blob storage. In fast development cycles, all the necessary information (both secrets and configuration) is currently presented to the application in environment variables.
This Azure Blob storage client is injected into our Azure Function HTTP trigger:
Seamless secret retrieval with Arcus Security
To introduce the Arcus secret store from the Arcus Security in this Azure Functions example, we only need a single package: Arcus.Security.Core. This package contains the secret store and some common built-in secret providers.
After this package is installed, we can initialize the secret store with environment variables and retrieve the Azure Blob storage account key from it:
👀 Notice that the Azure Functions HTTP trigger does not have to change: it is only the retrieval of secrets that has to be adapted. At this point, one may wonder why we initialize both the application configuration and the secret store with the same source (environment variables). This is a good thing, meaning that we’re starting to think of our input as different types. Both the Arcus environment secret provider and the Microsoft environment variable configuration source can retrieve only a portion of the environment variables by specifying a prefix. This could be a great way to make the distinction between application configuration and sensitive secrets right from the start.
Conclusion
This post demonstrated a way to integrate the Arcus secret store into an existing application without being invasive in the actual application code. It is by design that the example uses Azure Blob storage. This is an Azure technology we do not necessarily work upon in Arcus (like we do with Service Bus or Event Hubs). It is proof that Arcus can be used in any number of scenarios and should not be limited by the technologies described in our feature documentation.
This example shows how we can separate application configuration from sensitive secrets. This is an important step in making our application more secure and safer to use during future development. Treating secrets as secrets is a mentality shift that could bring great value, forcing you to think about your inputs differently. Not all inputs are public data and should be treated accordingly.
🏅Furthermore, we should place the secrets in a secure place (like Azure Key vault) instead of storing secrets and application configuration in the same place. Since the ISecretProvider is now being used for secret retrieval, changing it from environment variables to Azure Key vault is fairly easy and does not require any application code change.
🚩 See our feature documentation to learn more about the Arcus secret store. We also have a user guide that will gently guide you through the process of using Azure Key vault in the Arcus secret store.
Thanks for considering Arcus!
The Arcus team
Subscribe to our RSS feed