Support TLS authentication to HashiCorp Vault secrets

[csterwa]

We have a customer that recently attempted to use mTLS configuration for their HashiCorp Vault when using it as a backend for Spring Cloud Services (SCS) Config Server. Here is what they provided as information about the attempted configuration:

Here is a link to cert auth at Vault:

https://www.vaultproject.io/docs/auth/cert.html

The bottom of the page has the link to the API.

I have gone through most of the process but am having MTLS issues as our dev vault instance currently has a self-signed cert.  Disabling the check also essentially disables the MTLS handshake.  The internal Vault team is going through the process right now to install a real cert.  They say they can successfully get tokens from Cert auth.

We don't currently support this option that I know of (please let me know if I'm incorrect?). Could we add configuration options that would setup the mTLS handshake and then Config Server would be able to access the Vault API once authorized?

[habuma]

For clarity's sake, I do not believe this is mTLS, but just TLS. (I've only scanned the docs, so I could be mistaken.)

And, as I understand it, once authenticated via the /login API endpoint, the client still receives a token that must be presented on every request to Vault, similar to how it's done now. The gotcha is that the client isn't aware of Vault's existence except for being configured with that token. The client only knows about config-server through whom it passes a token. If the client is unaware of Vault, then how would the client make such a request to Vault's /login endpoint to obtain a token?

This can be addressed in one of three ways, as I see it:

• The client be made aware of Vault. In this case, the client would go straight to Vault for authentication, bypassing config server. At this point, however, I start wondering why even have config server in the middle for configuring secrets...why not have the client go straight to Vault for everything. (Yes, I see some benefit, but it becomes very weak once the client actually knows about Vault.)
• The config server exposes a /login endpoint that proxies to Vault for authentication. In this case, the client only knows about the config server and the config server knows about Vault. This seems to be beyond the scope of what config server should do, however.
• The config server itself is configured with a certificate and uses it to obtain a token that it hands off to Vault for authentication. But then the config server is now the owner of the token and all clients of that config server would have access to the same secrets as each other. This is quite different to how it works now, where each client could (and probably should) be given their own tokens, each with its own access rules and potential to be revoked independent of the other clients' tokens.

None of these are ideal, although I'd probably argue for the first one if pressed to make a choice. In that case, it'd probably be implemented as some client-side bits to handle the authentication and retrieve the token rather than by having the token statically configured in spring.cloud.config.token.

But as I said, this is based on a cursory reading of the documentation...I spent more time writing up this comment than reading the docs...so I could be missing something.

[scottfrederick]

@csterwa @habuma

https://github.com/spring-cloud/spring-cloud-config/pull/1526 adds support for many additional Vault authentication methods, including TLS certificate validation (docs updates in https://github.com/spring-cloud/spring-cloud-config/pull/1524). Note that all of these new validation methods are configured only in Config Server. Only token auth supports passing credentials from a Config Client to a Config Server (via the pre-existing X-Config-Token header).

This is closest to the third option above:

• The config server itself is configured with a certificate and uses it to obtain a token that it hands off to Vault for authentication. But then the config server is now the owner of the token and all clients of that config server would have access to the same secrets as each other. This is quite different to how it works now, where each client could (and probably should) be given their own tokens, each with its own access rules and potential to be revoked independent of the other clients' tokens.