Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hashicorp Vault #4753

Open
los93sol opened this issue Jul 2, 2024 · 5 comments
Open

Hashicorp Vault #4753

los93sol opened this issue Jul 2, 2024 · 5 comments
Labels
area-integrations Issues pertaining to Aspire Integrations packages feature A single user-facing feature. Can be grouped under an epic.

Comments

@los93sol
Copy link

los93sol commented Jul 2, 2024

Are there plans to add support for Hashicorp Vault? I started looking at it recently and it seems exceedingly difficult for Aspire to deploy and end up using it. You need some type of init/unseal operation that can run once the container is up, then there's several different auth options available, in Kubernetes it's trivial enough to use Kubernetes auth for it, but in a local dev scenario it seems like a jwt implementation is probably what's required there since Kubernetes auth won't work there. Then there's a whole other topic of ideally, it would be nice to let Vault autorotate things like db credentials, redis credentials, etc. and orchestrate that with the application. Has there been any discussion about more advanced scenarios like this?

@los93sol
Copy link
Author

los93sol commented Jul 8, 2024

I'm currently working on this and running into some interesting scenarios. The client I've selected is VaultSharp since it appears to be the most actively maintained and is feature rich.

The first issue I'm encountering is that since Vault requires it to be initialized after it is stood up, I cannot find a way to get service discovery working properly. I'm currently utilizing IDistributedApplicationLifecycleHook and using the API to determine if Vault should be initialized and/or unsealed and handling it so further configuration can occur. I'm able to find the consuming projects easily enough with the AppModel, but using EnvironmentCallbackAnnotations to insert the relevant configuration does not appear to make it to the project (assuming this is because the project has already started). Is there any guidance on how to handle this type of scenario?

@los93sol
Copy link
Author

@davidfowl With Vault it is initialized on the first start, and I need to update the environment variables for the project after it has spun up and configured Vault, but I cannot find a way to update the environment variables since the project has already started. What is the recommended approach to deal with this type of scenario? Sort of stuck with any further development until I have a viable path forward.

@crisweber2600
Copy link

@los93sol Is there a GitHub repo you're working on developing this in? Otherwise I was about to start working on this from scratch.

@los93sol
Copy link
Author

Hoping to have a PR soon. Would love to collab on it as Vault has its quirks that we’ve had to work out ways to cope with. Currently it can stand up, initialize, and configure one or more instances of Vault and consuming apps can request the parts of the config they want. Currently that’s unseal keys, root token, and app role. In the process of trying to figure out how to leverage the UserSecretStore stuff to persist these values. Let me know if there’s any specific things you’d be looking for as there’s a ton of options and I’m working towards an implementation for the needs I know about.

@los93sol
Copy link
Author

If anyone has suggestions on how to persist values generated at config time to user secrets I’d be interested. Looks like a new ParameterDefault and extension method are probably the best bet from what I can tell. It’s tricky because in this scenario it’s Vault that creates the values I need to persist so they can’t be generated by the framework itself like the existing implementations do.

@davidfowl davidfowl added area-integrations Issues pertaining to Aspire Integrations packages feature A single user-facing feature. Can be grouped under an epic. and removed area-deployment labels Sep 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-integrations Issues pertaining to Aspire Integrations packages feature A single user-facing feature. Can be grouped under an epic.
Projects
None yet
Development

No branches or pull requests

4 participants