Developer feedback wanted!

[nagyesta]

Looking for feedback, please make your voice heard!

[aiceball]

Hi,

I've been trying out lowkey-vault to test an AKV-bound service, and it's about 90% fitting to the use case, very convenient, so first of all thank you for your work!

One issue I do have, however, is that to my understanding the vault is defined ONLY through the keyvault URI used. If I have a container on the same docker network communicating with lowkey-vault, the vault I'll be hitting will be based on the internal network name I gave that container, i.e. akv. If I try to write content to the lowkey-vault from a local python-client, however, the address is different, because I am communicating with lowkey-vault from outside the docker network:

graph
    Python-client -- https://localhost:8443 --> Docker-Lowkey-Vault
    Docker-Service -- https://akv:8443 --> Docker-Lowkey-Vault

I wonder if some sort of vault aliasing feature can be added on the management API layer, either at creation time:

POST /management/vault

{
  "baseUri": "https://bbv:8443",
  "aliasUri": "https://localhost:8443",
  "recoveryLevel": "CustomizedRecoverable+Purgeable",
  "recoverableDays": 42,
  "created": 1641092645,
  "deleted": 1641092645
}

or an additional modification point:

PUT /management/vault/{baseUri}

{
 "aliasUri": "https://{newUri}:8443"
}

What this would enable is an access to the same keyvault from multiple networks, i.e. a local network, an internal docker network, an ngrok tunnel, etc.

I am using the Azure Python library to communicate with the Lowkey-Vault if that information is relevant.

[nagyesta]

Hi @aiceball ,
first of all, thank you for taking the time and filling out this survey! Also, thank you for providing such detailed instructions about your improvement idea! I love it, will create an issue based on this and figure out how to make it work!

[nagyesta]

Created #298 to cover this.

[conblem]

We are using lowkey-vault for local testing of our .netcore api's. Some of our devs use M1 MacBooks and docker has to resort back to amd64 emulation on these devices, because there are no native images. The startup time of our whole stack depends on first having a running lowkey-vault instance. At the moment this is really slow for our engineers using ARM machines. We would really appreciate a ARM build of your project.

[nagyesta]

Hi @conblem ,
thank you for using Lowkey Vault as well as taking the time to provide valuable feedback! I have to read up on the topic, because I have only known that M1 Macs exist, but never used them (or written any code specifically for them). I assume this should be a problem other projects had to figure out as well, so I am positive there must be a solution. As I am not able to test the thing, would you be willing to provide feedback on the work in progress solution if I manage to figure out something that is supposed to work?
Anyway, I will create an issue in the backlog to be able to track this and will give it a try when I can. In the meantime, if pure Java is an option for you, you could maybe try running the app jar and see whether that is any faster. Hopefully the JDK is already supporting M1.
Thanks again!

[nagyesta]

You can track #343 for more details.

[abtris]

Hi, great tool. I tried use by https://github.com/nagyesta/lowkey-vault-example-go/ and find that example isn't compatible with latest version (nagyesta/lowkey-vault-example-go#100). Can I just upgrade docker images to your latest version to make it working?

[nagyesta]

Hi @abtris ,
thank you for your feedback! Created a new ticket to track this issue. Please find it here: #697