Vault as OIDC Provider for Boundary conflicts with HashiCorp guidance

Common advice from HashiCorp is do not expose Vault to the Public Internet, such as in the Production Hardening guide.

Boundary by its function of enabling remote access implies being accessible from the Public Internet.

Vault as an OIDC Provider has become GA, with several examples and references being touted by HashiCorp using it for authentication to Boundary. However, this would require Vault to be accessible from the Internet, thus breaking recommended practices.

I would be really keen for some clarification from HashiCorp on this perceived conflict, what is the recommend approach in this instance?

Some options/ideas I see are:

  • Yolo and expose “Prod” Vault directly to Internet, possibly with some WAF in front limiting access to the specific OIDC API path to limit blast radius.
  • Creating a new Vault “Proxy” containing only minimal stripped down code for OIDC that is public facing (DMZ) that relays the auth request to a backend Vault containing secrets.
  • Run two Vault clusters, one without secrets just for OIDC, another in the backend behind Boundary containing secrets.
  • Something else?

I had thought about using Boundary itself to provide anonymous unauthenticated access to Vault’s OIDC API, but target granularity is limited to a specified port.

Looking forward to recommendations on the best way to solve this Chicken and Egg problem.