Hi.
According to documentation, when using spring.cloud.config.server.git.search.paths: [ "foo", "bar*" ]
the server searches for config files in the top level and in the
foo/
sub-directory (...).
Is it possible to setup Config Server with Git Backend in such a way, that it will look ONLY in foo/
and not in top level and not in any other subdirectories of Git repo? And if so, than how can I achieve that?
Best regards, Piotr
Comment From: ryanjbaxter
Searching is different than using them, as long as there is no file named application
or contains the application name in the top level it won't use them. That implies that if the top level is empty you wont have that problem either.
But no there is no way to prevent the config server from searching for files in the top level.
Comment From: realny
Hello, @ryanjbaxter
Thank you for your reply. I was considering a setup with a single Git repo that would keep both Spring apps configs as well as manifests for deploying apps to target platform, like Docker Swarm or k8s. This approach would allow me to have matching configurations for both Docker/Kubernetes services (especially image versions) and Spring apps within a single commit.
If I were to have /platform-manifest/
and /spring-configs/
in the same Git repo I would want to be sure that files residing in /platform-manifest/
couldn't be fetched using Config Server API. That was the reason for my question.
Best regards, Piotr
Comment From: ryanjbaxter
If you set search-paths
to spring-configs
it should completely ignore platform-manifest
Comment From: realny
It seems that one can abuse Config Server API to reach content of platform-manifest
.
Consider following config:
spring.cloud.config.server.git.search.paths: [ "spring-configs" ]
and following contents of git repo:
repo:
├── platform-manifests/
│ └── docker-compose-apps.yml
It seems GET /platform-manifest/default/main/platform-manifest/docker-compose-apps.yml
would return platform-manifests/docker-compose-apps.yml
file utilising Config Server's mechanism of serving plain text.
Could config like that would be considered reliable workaround:
@Configuration
@EnableWebSecurity
public class SecurityConfig {
private static final String DISALLOWED_PATHS = "/platform-manifest/**";
@Bean
public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
http
.csrf(AbstractHttpConfigurer::disable)
.authorizeHttpRequests(authorize -> authorize
.requestMatchers(DISALLOWED_PATHS).denyAll()
.anyRequest().authenticated()
)
.httpBasic(Customizer.withDefaults());
return http.build();
}
}
Comment From: ryanjbaxter
Yes, but serving the file is different from the documentation you referenced above with is relevant to a different API.
In this case you would want to secure the API with Spring Security if you want to disable unauthorized access.