Closed chadlwilson closed 9 months ago
A good alternative in this case is a community fork of the project, to avoid to restart from zero
@henryx that's also an option for this plugin to use if a trustworthy one emerges. But this is a sensitive area given it deals with secrets. Quite a bit of time has passed as well - and I'm not aware of any forks emerging as winners so far?
To be fair, within the context of this plugin's usage, using Spring Vault would not be entirely starting from zero (but I have not evaluated the pros/cons of this).
@chadlwilson in my case, for example, I don't use Spring or Quarkus (that has it's own plugin too). So, it remains me only two choices:
Second scenario is also the current method used internally from the library to communicate with Vault. Last, is obvious that a library like this is more sensivite, and is the reason that I agree with you when you say it should be last resort, but at this point I don't view other ways
You don't typically need to use Spring as a framework to use pieces within it as a library, although it is a big lib and drags some dependencies with it.
There's a maintained fork which @12345ieee helped us switch to in https://github.com/gocd/gocd-vault-secret-plugin/commit/adb2aa3a96ed6c796b49be27d178a7b9fd743c71
This driver seems dead/EOL now as noted at https://github.com/BetterCloud/vault-java-driver/pull/245#issuecomment-954066376.
We probably need to move it to another solution. Possibly https://spring.io/projects/spring-vault depending on the spring overhead to use use the
VaultTemplate
directly?