HTTP interface for plugins

[thequailman]

The current OpenBao plugin architecture is very unwieldy in the face of containerization--registering plugins and updating them to new versions is not user friendly, and it limits the adoption of plugins. Instead, I think a better plugin model would be similar to Kubernetes CRDs extensions--have the plugins listen as HTTP/HTTPS endpoints that have an API interface that OpenBao communicates directly with. These plugins could run on separate machines/separate containers, and OpenBao would just register the endpoint.

[bnevis-i]

In addition, that all of the plugins are statically linked means memory and on-disk footprint is very large, which in a constrained environment make Vault the largest component in a system. Think more like Apache loadable modules than giant monolith.

[cipherboy]

Right now I think we use GRPC for plugins iirc, this hasn't changed in OpenBao. There can already be external plugins (e.g., https://github.com/remilapeyre/vault-acme), but I don't think these are versioned well. In particular, as long as the plugin intercommunication backend doesn't change, it Should Work (TM), but sometimes plugin vendors are slow to update...

Perhaps building a better ecosystem for plugin authors to write against (rather than just Go) might be best to get started? Versioning I think will come in good time, but I think in general, it is good to start with a known working collection (core + plugins versioned together) than getting too far separate from each other.

But yes, duly noted that the size of the binary is large. :-)