spring-cloud / spring-cloud-vault

Configuration Integration with HashiCorp Vault
http://cloud.spring.io/spring-cloud-vault/
Apache License 2.0
272 stars 151 forks source link

Provide custom path/name for fallback vault token file #617

Closed vsingal-p closed 2 years ago

vsingal-p commented 2 years ago

In #609 support was added to fetch token via the token file as fallback if token is not provided as property. However, the location of fallback file is hardcoded within spring-cloud-vault.

We have a requirement to use a custom path and name for the token file. We have multiple environments, and due to some constraint the paths in them are different.

Can we have something like this in which we can provide the fallback location?

spring:
    cloud:
       vault:
           token-file: "some/location/token-file-name"
mp911de commented 2 years ago

Please implement your own authentication scheme.

Picking up the token file as a fallback and on presence in its default location is a convenience functionality. We do not want to enhance configuration options any further.

vsingal-p commented 2 years ago

But given this package is using using ConfigData API to load properties, it is not possible to tap the startup process and load token via file which can be used by spring cloud vault

mp911de commented 2 years ago

It is possible to register a custom ClientAuthentication by calling ConfigurableBootstrapContext.register(ClientAuthentication.class, () -> your client authentication) through a BootstrapRegistryInitializer as in

SpringApplication application = new SpringApplication(…);
application.addBootstrapRegistryInitializer(registry -> registry.register(…));

It's a bit more difficult to get hold of property values within a BootstrapRegistryInitializer but that's a question rather for Spring Boot.

vsingal-p commented 2 years ago

Okay, we could try that But if we are allowing token to be read from a fallback file, why is customising the location of that file an issue?

The default fallback works for unix based OS, like macOS, but it won't work for Windows anyway. So I think there's a strong reason to have the flexibility to define location of that file

mp911de commented 2 years ago

Because it introduces new configuration elements.

vsingal-p commented 2 years ago

A configuration around the same token based auth. If we are allowing token to be read from file, the location of that file should not be an issue IMO. Plus this introduces development gap. A developer working on an application on MacOS, cannot share the same with a developer using Windows without one of them having certain hacks.

mp911de commented 2 years ago

The longer reply is that now we start with a path, the next one wants to read the token from a remote server or an URL and another one wants to get the token from a service. We have to draw a line somewhere as we do not want to introduce insecure elements into Spring Vault/Spring Cloud Vault.

Feel free to fork this project and introduce the necessary changes in a development line that suits your needs.

A developer working on an application on MacOS, cannot share the same with a developer using Windows without one of them having certain hacks.

It's not our goal to compensate for operating system differences.

vsingal-p commented 2 years ago

Thanks for the clarification @mp911de 👍