OpenTofu / Terraform provider planned to be officially supported?

[dragetd]

A big strength of a secret management engine beyond simple password managers is the IaC approach of managing them. So generating infrastructure and putting the secrets into the secret store via tofu for example.

Vault had a provider that would allow this. I am pretty sure some OpenBAO provider will eventually pop up, but are there any plans to make it officially part of the project? (With implications like some time in the future releases waiting on each other to ensure compatibility or even inclusion in tests etc.)?

[cipherboy]

\o hey @dragetd -- we had discussed this a bit in #339 but I think the general points still stand: until upstream is unwilling to merge net-new features to the provider and/or OpenBao diverges too far in new functionality, my gut says we should probably keep encouraging collaboration with them on some of this common infra & tooling.

That said, if that doesn't occur or we find we've added enough new functionality that we think we could take advantage of, I'm happy to entertain blessing a fork.

What's your thoughts?

[dragetd]

Oh, actually it did not occur to me that the vault provider might just work, as the API is still in place!
Silly me. So I guess I can continue kind of 'mostly anything right now' and just throw it against OpenBAO instead of Vault.

Yes, unless the feature-set diverges noticeably, there is not really a point in investing that work right now. Focus should be on polishing it up as it's own project.

I'll see what happens if I spin up openbao instead of my vault and throw my tofu against it. More food for my infrastructure. xD

[cipherboy]

Enough to make one hungry! :D good luck, and let us know if you encounter anything!

[ttiborgh]

Hi @dragetd, @cipherboy! We plan to install OpenBao into our environment with the Vault provider of Terraform. We are curious if you guys have experienced any strange behaviour when installing OpenBao with Terraform? Are there any issues you are aware of? We would like to make sure to be prepared for any issues or blockers in advance. :)

[andreaso]

@ttiborgh: I'm currently using the Terraform Vault provider together with a small/simple OpenBao instance, and so far I haven't had any issues.

[LordGaav]

One thing that might be an issue: the new CEL functionality in the PKI engine doesn't seem to be reachable using the Terraform provider.

[jficz]

We're encountering bugs in the upstream provider quite often which sit there for years without much interest from Hashi and we have some feature requests with PRs which are completely ignored. We're actually considering a soft internal fork with the bug fixes and features implemented as some are quite serious.

We'd be more than happy to submit our PRs to a fork which actually works with their community.

[cipherboy]

@jficz Do you have thoughts on fork maintenance?

I'm kinda wondering if we want a new format, repo with patches and a renamer utility, that auto-generates the destination repo.

Are there patterns for lightweight forks for source repos I wonder? Especially when we want to follow upstream? 🤔

[jficz]

Not really, it heavily depends on what the fork's goal would be imho. In our internal case it's just about a few relatively simple fixes for a few annoying things so we would probably go with rolling rebase.

But if the fork was to be an "Official Bao Provider" then it would be more complex - as I understand there are a few different paths to choose from:

1. entirely new provider based on some kind of automated api generator
2. a "wrapper" on top of upstream provider
3. a soft / hard fork

I agree with a couple of comments in the issue that option 1 would probably be a bad idea for various reasons - mostly migration from current setups and the fact that the tooling appears not to be maintained.

The wrapper approach would be interesting but then I think a line would have to be drawn between what would be wrapped and what not. The obvious would be to just add bao-specific stuff and keep the upstream provider for everything else. That would mean we probably could not do things like fixing bugs that upstream ignores or adding features to existing resources which are not bao-specific (basically the two issues I linked above) but it would also mean easier maintenance in the long term with higher initial costs.

A soft fork seems like the easiest way to start at least - we wouldn't have to reinvent anything, just patch in/out things the community wants to. Lower initial costs with the risk of higher maintenance overhead in the future.

Both wrapper and soft forks are ultimately bets on what happens in the future both with the community requirements and upstream source. And I'm not sure I'm qualified comment on a betting strategy :)