Vault configuration reload (add/remove listeners)

[player1-fleetsmithsupport]

Hi,

I believe it's a next part of (https://github.com/hashicorp/vault/issues/415). Reload TLS certs is great but you need at least one TLS cert for start. What I would like to do is bootstrap vault just with a limited for localhost tls_disabled listener. Issue new cert, replace unsecure listener with a new one where TLS cert was issued from Vault and reload vault.

It's possible right now to unseal vault, get cert, restart vault and unseal again or bootstrap with some fake cert and replace them but it sounds like a hack. From security perspective I think if you can right now replace cert and reload vault it's not more danger compare to add/remove listener. In theory you could add unsecure listener so maybe it could be limited only for TLS listeners.

[jefferai]

It's not a security perspective that is causing this to not be implemented, merely a time/coding perspective :-)

[aphorise]

There's one thing I'd like to note on why this request is actually not feasible IMO and ought to be closed.

There are OS / process sandboxing rules when kernel drivers or changes are involved and where it will not be possible for existing processes to dynamically bind to adaptors or addresses that were not accessible to them at the time of their launch; there are OS routing related rules the same that can also not be dynamically updated beyond existing routes / adaptors.

This exactly why all L4-L7 type application including for example Load-Balancers (NGiNX / HAProxy) require that their process restart to be able to deal with any ACL change as far as bindings are concerned; the best that's offered in those cases is a session / thread transfer between restarts to minimize disconnections state as much as possible and in some cases additional frontend bindings are provisioned to allow for changes between A / B connections while another LB can manage the switch over (also another reason why we have so many LB's generally 😄)

Hey @player1-fleetsmithsupport - can you kindly state if this is still relevant for you? - I'm also keen to hear of your thoughts / understanding to what I've shared above.

[ghost]

@aphorise IIunderstand the challenge here, but the problem is still there. If I want to use certificates issued from Vault PKI, I need to start Vault with some fake certificates, issues proper one and reload Vault, the problem is those "fake" certificates still need to be from from somewhere. Maybe more proper approach would be something that Traefik does - if there are no certificates, the program issue self-signed certs and maybe those could be reloaded?

[aphorise]

@player1-fleetsmithsupport - do you have any link / docs / github repo further to the Traefilk approach you've mentioned? - I'm curious how or if they deal Kubernetes and other context?

From my limited knowledge configmap changes related to bind configuration normally entail a process restart and assuming the ability to dynamically bind based on configuration changes is not always guaranteed even if the process did have the ability to re-read configuration and then attempt changes.

Conceptually - it may be possible to have be a place holder for a default / initial new cert + next / future cert and the ability to co-present both or drop either over time without the need for a restart and using the current reload approach (kill -SIGHUP $(pidof vault)).

PS - Maybe the heading of this issue should read ... reload on certificate listerner changes

[ghost]

Let's close this, I don't have environment where this was an issue and I don't really use Vault anymore.