Secret Volumes (With Demo) And Empty Volumes In Azure Container Instances

Secret Volumes

Azure Container Instances support secret volumes and the secret volumes allow you to store sensitive data. That sensitive data could be your SSH keys or it could be your database credentials.
One great thing about this is that this data is stored in a RAM-backed file system. So, there is no fear of them being written to non-volatile storage.
On top of that, Azure CLI supports the configuration of secret volumes with the help of two arguments.
The --secrets key=value argument allows you to specify your secrets in a key=value format.
The other argument which --secrets-mount-path /mnt/ktsecrets specifies wherein the container the secrets volume should be mounted. Here is my case, it would be mounted to ktsecrets.
Generally, you will find one file per secret in that path where the file would be named after the secret name and the contents of the file would be the value of the secret.

Let us go ahead and see the demo for secret volumes where we will see how easy it is for our container to access secrets stored in a secret volume.

We are going to store a single secret into a volume and then our container will access the secret.

First of all, login to your Azure account using the az login command and select your preferred subscription (if you have more than one).
Then, create a resource group and put it in your nearest datacenter.
Now, we will create a container group and use the az container create command, specifying the container group and the resource group it is in.

We will use a very small Docker image i.e. alpine Linux that will help us to quickly start this up.

The restart policy would be set to never and we are going to configure a secret that has the name PASSWORD and the value 'A very big secret!'

We are also going to mount the secret at the /mnt/ketsecrets path. In that folder, there is going to be a file with the name PASSWORD and the content 'A very big secret!'.

To check that this worked, we are just going to set a command line for our container to use cat to print out the contents of that file.
In a real-time application, this secret might contain something like a database connection string and so your code would go and read this file and use that when it's connecting to the database.

Once we have created the container, it won't take very long to get running because the image which we took is very small and it will complete very quickly.
We will use the az container logs command to see what is written to the log output. And we would be able to see the value of our secret.

In a real-world scenario, however, you, of course, won't write secrets into a log file. This was just a demonstration of how easy it is to use these secret volumes so you can ensure that your secrets are never actually written to non-volatile storage.

Empty Volumes

You can also mount empty volumes in an Azure Container. It might seem a little awkward to you and you might wonder why would you mount an empty volume which is not actually backed by something like an Azure File Share.
But the thing is, an empty volume can be accessed by any container within a container group and so it allows them to have a way of sharing files between them. It enables a pattern of container usage known as the sidecar pattern.
A sidecar pattern is something where one container is used to add additional functionality to another.
Supposing that in our container group we have got a container that is expecting to find configuration stored in a YAML file in a particular location and another container in the same container group knows how to call a configuration service that gets that configuration and creates the YAML file.
So, by using a shared empty volume, one container can write into it and the other container can read out of it.
You would not use an empty volume to store actual application data contents like a database because it will not live beyond the lifetime of your container group.

However, there are some drawbacks of empty volumes,

Empty volumes are currently not supported by Azure CLI so you need to use ARM templates to create them.
They are not supported by Windows Containers.
You can visit the ACI documentation site here to check out what are the current limitations of ACI.

As mentioned above, Windows doesn't support any of the volume types and there are various quotas restricting things like how many container groups you can have in your subscription and also how fast you can create them.
But one good thing is that you have the power to request that these limits are increased for your subscription as they are a little bit on the low side at this moment.
However, these limits will become a bit more generous over time as the ACI services are growing very rapidly among the users.

3 Comments

Join the conversation! Your thoughts help the community grow.

granada Coder8y ago
This was great. The sidecar stuff was a great extra too. Thank you. One question. How does the ~application code~ read the secret values? The "environment variable" stuff is easy to read with dotNetCore or Java. I'm at a loss for how to read the secret values described here. Thank you.
Hadshana Kamalanathan8y ago
Thank you for sharing.........
Viknaraj Manogararajah8y ago
Nice Article, Thank you for sharing.........