Harden access to the config share in Azure

[mbarton]

NPDA currently follows our reference architecture for configuration in Azure. There is a storage account with a file share containing the .env file. We then point the container to it using the native Azure Container Apps support.

Azure Container Apps does not yet support accessing the storage account using an Azure managed identity: microsoft/azure-container-apps#850. As we were just using it for config, we decided access using static keys is OK as the data contained there is API keys for third party validation services etc. In particular, the session secret key is not in the .env file but injected as an Azure Container Apps secret.

Azure has flagged our usage of storage accounts as critical with two warnings:

• Storage accounts should restrict network access using virtual network rules
• Storage accounts should prevent shared key access

We can fix the first warning standalone by integrating a virtual network into our Azure Container Apps environment but in my experience that tends to cause knock on complexity accessing other resources like the database. I also don't think that warning makes sense if you have shared key access disabled, as that's ultimately the same access control mechanism that the Azure portal is using.

In particular, just restricting access to the storage account to a particular network breaks access from the Azure control panel unless you happen to be within that network. That is unacceptable for how we are structuring our applications - it is vitally important that the members of our team can access and debug our file shares regardless of where they are.

Looking in to this has also made me realise we probably need to disable shared key access entirely - as we now store uploaded CSV data in a separate share to the config. This is ultimately the same data we save in the database and as such needs to be subject to the same access control (Active Directory/managed identity authentication).

So potential way forward:

• Download the .env file at container startup, similarly to how we do in continuous integration
  • This should use the managed identity of the container, in the same way as we do for database access
• Store the CSV files as blobs in the database (Django BinaryField)
• We previously rejected this as it would be surprising to developers not familiar with the project
• Django strongly advises against doing this but their arguments apply to commonly accessed static files whereas we are storing the CSV for the record. It is unlikely to be accessed again, certainly not regularly and only by authorised users.
• Prevent shared key access and suppress the warning about virtual network rules

If Azure ever implement microsoft/azure-container-apps#850, we can move back to storing everything in file shares. I personally like Azure Container Apps and I think it is still a good fit for our usage, despite this issue.

[mbarton]

We could upload the CSV files to Azure using the file share API but that would probably tie us closer to the platform than we would like.

[mbarton]

We now just have config in the share and have marked the warnings as mitigated