In my previous post about local development using the Azure Key Vault Emulator I briefly mentioned my own fork of the emulator to address some missing APIs. One thing I had planned to change in the emulator for a while was how the REST API endpoints exposed by the emulator are created. The old approach (from which I forked) manually crafted the REST APIs including the models needed. That’s been a thorn in my flesh from the first moment I saw it, and I knew that I wanted to fix that. After all, Microsoft has official Open API specs for the Azure Key Vault REST APIs, so why not use those?

Thus I embarked on the journey to throw out virtually all old code from the emulator and generate all REST API endpoints using code generation. There were a few obstacles to overcome first, though.

  1. Microsoft has separate Open API specs for keys vs secrets vs certificates. I could run code generation on each one of them, but that will result in duplicate models in some cases. Thus I need to merge the Open API specs properly.
  2. Some APIs are not properly defined in the Open API spec. For example, the Get Key API documentation claims that the key-version parameter in the URL is optional, but the Open API spec has it marked as required. Fortunately, the APIs that work like this are only few, so manually creating endpoints for those was acceptable.
  3. Different versions of the Open API spec use different approaches for operation tags, making it diffcult to find one way that works for all (or at least many) versions. I still haven’t solved this one, but it appears less important at this time anyway.

Beyond the above, I also realized that I needed a better way for persisting Key Vault objects, so I overhauled the whole store implementation. Unfortunately, the new implementation is incompatible with the old one, which is why I decided to release the new version of the emulator under a new major version, 2.

I figured I’d change quite a few other things that had bothered me too, and overhauled all the tests in the repo. Now, testing no longer requires running the emulator in a container while running the tests in a separate process. Instead, I take advantage of the AspNetCore Test Server which runs the server in-memory in the test host process. This allows for easily measuring test coverage as an indicator for the quality of the emulator.

I also implemented some more APIs, changed the generated container image to have default certificates for HTTPS endpoints in it, and got rid of all the Swagger stuff, of which I never understood why it would need to be there in the first place, given that the APIs were supposed to be the same as for a real Azure Key Vault.

The result is that new v2.* images of the emulator should be a whole lot easier to run. For example:

# Set user 1654 as primary owner of the .my-vault directory and all its contents
sudo chown 1654 -R .my-vault
# Run the container using the .my-vault directory to persist keys and secrets
docker container run --rm -it -p 11001:11001 \
   -v $PWD/.my-vault:/app/.vault \
   ghcr.io/rokeller/azure-keyvault-emulator:v2.0.0-rc2

Aside from all this, I will try to implement some more APIs. If you have some preference, or find issues, feel free to open a new issue in GitHub.