Open thequailman opened 7 months ago
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.
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. :-)
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.