Add the ability to create listeners which are tied to a specific mount #796
Comments
|
I had mentioned this on Matrix, but for the benefit of people here... Sometimes we also want to bind specific paths within a mount to listeners as well. For instance, many TLS implementations do not support fetching AIA info (OCSP, CRLs, CA info) over HTTPS endpoints, and so require a HTTP endpoint. However, if anyone has a misconfigured client defaulting to HTTP (for secrets/PKI management), we don't want to take privileged API operations over the HTTP endpoint. So we'd want to only selectively allow paths within a mount from a listener. I think some combination of these two approaches would thus be useful: an ability to mark a mount as bidrectionally exclusive to a given listener (perhaps, even rooting the mount there regardless of its path and not allowing any other requests on that listener), or, have a generic listener that selectively routes requests to the "theoretical" mount path. Some thoughts! This probably needs an RFC so we understand and agree on behavior before implementing. :-) |
In order to limit the exposed (attack) surface of OpenBao it would be nice if one had the ability to create a listener which is tied to a specific mount.
This allows one to for example create a listener which only exposes a specific OIDC mount which should be accessible from the Internet. This way only a fraction of OpenBao would be exposed to the Internet without having a reverse proxy terminate the TLS (a solution which has a different set of pro's and con's). It could also be used to limit the exposure of OpenBao API to other containers and VM's.
Overall it opens up a variety of options which makes OpenBao more flexible to deploy.
The text was updated successfully, but these errors were encountered: