I’ve got a large codebase of .NET that runs on Windows servers - on-prem, not much in the way of config management or orchestration. Currently, they pull encrypted secrets (partner logins, keys, other certificates) from a database, and use a private key in an installed certificate to decrypt for use by the programs.
We’re hoping to move that to Hashicorp Vault. We’re planning on using the Vault Agent for its autoauth but I’m wondering how best to retrieve the actual secrets. The tutorials on using .NET with Vault are to either use a library, or the agent. We’re not planning on using the most popular library, VaultSharp, as it has a dependency conflict with something else in our solution.
I’m testing the agent now, and the tutorial talks about using Consul templates to place the secrets on the filesystem, and those templates are expected to be referenced in the Agent config file. That seems troublesome for us - not all servers need all secrets, and I’d rather not worry about changing the Vault agent config file and restarting the agent if a server gets a different role or environment assigned to it (thus needing new/different secrets).
Should I investigate using a different library (or just hit the Vault API myself in our code), simply using the token that the Agent puts on the local file sink? Should I shell out to the vault agent executable and get the secret?
If you’re deploying your final app in kubernetes then that’s easy you can retrieve and turn your secrets into environment variables (source the secret file). Now you can just read the secrets as they were environment variables.
If you’re in a VM, you can either just make HTTP calls to the agent (127.0.0.1:8200) or you can have the agent create a property file for you that your application can read.
Last option is to actually use a library and make “vault” http calls, but that’s more work as you mentioned and ties you to that library unless you abstract it.
on Windows servers - on-prem, not much in the way of config management or orchestration.
If you’re in a VM,
We’re mostly on bare metal, why would being in a VM make a difference?
you can either just make HTTP calls to the agent (127.0.0.1:8200)
This is something I wasn’t able to find much documentation about. How does the agent authenticate the calling code? I didn’t see anything in vault agent docs about how this is secured, just details about how caching works, and how to configure the address for the agent’s listener.
or you can have the agent create a property file for you that your application can read.
That’s literally the case I wanted to avoid when I wrote this:
That seems troublesome for us - not all servers need all secrets, and I’d rather not worry about changing the Vault agent config file and restarting the agent if a server gets a different role or environment assigned to it (thus needing new/different secrets).
Found more details on how to authenticate to the agent using caching and proxying. The documentation seems to assume you already know what you’re doing, but this tutorial actually stepped through it much better, at least for me.