all Technical posts

Integrating Arcus Security in a Non-Invasive Manner

One of the issues with integrating Arcus into your projects is that it has the reputation of being 'invasive', or 'breaking current functionality'. This post will show you how Arcus can make your application more secure, without bulldozing your code base.

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:

Separating sensitive secrets from application configuration

The trick is to find the secrets in your application configuration and treat them differently. We have a whole section in our feature documentation describing why Arcus recommends this as a safer, cleaner, and more maintainable alternative. It is important to realize that Arcus does not act as a ‘nice to have’ at this point, but brings real value to the table, which is both critical and necessary (learn more about the dangers of solely using application configuration here).

The Azure Blob storage account key is the main secret in this example. Ideally, configuration and secrets reside in separate places. This example begins from a scenario where they are both stored in the same place, but that does not mean that they should reside in the same place in your application code. Treating secrets as secrets and not public configuration data is a big selling point here. It means that we mentally work more carefully when we retrieve secret information and when we retrieve common data.

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.


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

Hi there,
how can we help?

Got a project in mind?

Connect with us

Let's talk

Let's talk

Thanks, we'll be in touch soon!

Call us

Thanks, we've sent the link to your inbox

Invalid email address


Your download should start shortly!

Stay in Touch - Subscribe to Our Newsletter

Keep up to date with industry trends, events and the latest customer stories

Invalid email address


Great you’re on the list!