embedding openbao as a library

[jmls]

TL/DR; Can I use openbao as a library in a separate go project ?

I am a complete noob at go, and I thought that I'd teach myself it by working on / changing my favourite go program Vault. Or, now, openBao ;)

The first task I wanted to do was to learn fibre, and thought that it would be an interesting side-project to replace the http endpoints in openabo with a fibre-based version instead

However, and isn't this always the way, scope creep crept in and because I am not entirely familiar with the language too many questions started to be unanswered.

My first thought was to create a new http server using fibre, and then calling the openbao cli , but didn't sit too well with me.

A second thought was to create a sort of "openbao proxy" where my app would expose the http endpoints using fibre and then sending onto the local openbao server (which is listening on 127.0.0.1 only)

Then something else caught my attention where it was intimated that a go package could be imported into a project and re-used

So, after a long preamble, I get to my TL/DR; Can I use openbao as a library in a separate go project ?

Sorry if it's a stupid question but didn't want to go down too many rabbit holes :)

[cipherboy]

Hello @jmls

Like upstream, we do not support importing all of OpenBao (core) as a library. You can however import sdk and api; at the moment, we do not have tags pushed as we have not done any releases, so you'll need a hack similar to this:

https://github.com/openbao/go-kms-wrapping/pull/1/files#diff-0566c2b9bc3022f8cbcac5ae663e0ff61e280009224821231750be362d5ac9aeR8

SDK does include a testing module, if you wish to develop a plugin and test against OpenBao, though I imagine this is broken at the moment.

Hope this helps.

[cipherboy]

@jmls api/v2.0.1 and sdk/v2.0.1 were pushed as tags today, so you should be able to use the Dockerized setup now from your own projects. :-)

Edit: api/v2.0.0 and sdk/v2.0.0 tags were removed due to the v2 version number causing problems as the api and sdk modules were not updated to publish as such. This has been fixed. In the mean time, the SDK was also updated to account for the new registry location (see #427) so using Docker tests should work better.