Setting up ConsenSys's Quorum Key Manager on Azure
A while back I did an article on how to deploy EthSigner on Azure. Since then, ConsenSys was hard at work building a solution that’s based on the experience gained from developing EthSigner (and other products), which at its core, provides the same functionality, but with many more advanced features (such as enterprise-grade security and consolidated account and key management), and it’s called Quorum Key Manager (QKM).
In this article we will be covering the infrastructure and resources needed to deploy the QKM which include a PostgreSQL database, a file share for configuration files, a key vault and a mechanism for running the QKM container both for the migration process and the main service process.
Prerequisites
Will be using Terraform and its azurerm provider, so we will be needing the following installed on our workstation:
Example Repository
A complete example Terraform script, which creates a private network, an Azure Database for PostgreSQL, an Azure Key Vault, an Azure Files share, a managed identity and runs QKM’s containers on Azure Container Apps, is available in the following GitHub repository:
The script
For brevity, I will only cover the areas of the Terraform script that are unique to the deployment of QKM, such as generating and uploading the configuration files, configuring the Azure Containers App environment, and running the containers.
First thing, we will create three configuration files for QKM, which include nodes configuration, vaults configuration, stores configuration:
- Nodes configuration file, which has a template variable for the node URL:
- Vaults configuration file, which has template variables for the vault name, azure tenant ID, client ID and client secret (see the managed identity module in the example mentioned above for details on how to generate those credentials):
- And the stores configuration file, which is has no dynamic content, but does rely on the name of the value defined in the vaults configuration file:
Next, we need to upload those configuration files to an Azure Files share, which will be later mounted to our containers. To do that we will use the azurerm_storage_share_file resource, but because at the moment it only supports passing paths of files located in the local file system, we will need to create them (after the templates where populated with values, which some are sensitive) using local_file and then later delete them (because we don’t to keep any files with sensitive information lying around) using a little trick with the null_resource resource:
The creation of the virtual network, database and key vault won’t be discussed here, as they have no special treatment for this deployment, and are included in the example mentioned at the beginning of the article, so we will move to the creation of the Azure Container Apps environment.
At the writing of this article, there is no dedicated Terraform configuration element for creating any of the Azure Container Apps related resources, so we’ll be using the azapi_resource from the azure/azapi provider.
Note that as we require to mount the Azure File share to our containers, we need to define a storage in the environment, so the complete environment and storage definitions should be like the following:
And lastly define the containers, using an initContainers section for running the QKM container with migrations command (so it runs before the main QKM container is started) and the containers section for the main QKM service container (note that the volume is pointing to the name of the storage defined in the previous step):
Last part is to run terraform apply and wait for the script to complete before testing the QKM’s external endpoint.
Testing The Deployment
Because the application is defined with an HTTP ingress, the container will be exposed at 443 (standard HTTPS) and not the internal 8081, due to Azure Container Apps automatically mapping HTTP ingresses in that manner for us, so you only need the ingress’s FQDN to do a simple HTTPS test.
Conclusion
Exposing the Quorum Key Manager to the internet in this article is only done for demonstration purposes. In a real-world production environment, it will probably be only available to internal systems, or even just to the specific services that require it to function. Note that the Quorum Key Manager doesn’t have any nonce management logic, which is usually required in systems with lots of concurrent connections trying send transactions to the blockchain, so for that it will need to be combined with something like ConsenSys’s Codefi Orchestrate.
