Vault authentication uses non-existing token instead of spring.cloud.config.server.vault.authentication

[tstenner]

Describe the bug

For composite vault sources, a basic config server with spring cloud 4.2 used the authentication configuration in spring.cloud.config.server.vault for composite vault sources.
The same code updated to spring boot 3.5 / spring cloud starter 2025.0 + spring cloud 4.3 falls back to token authentication and fails because no token is configured (Missing required header in HttpServletRequest: X-Config-Token).
This might be related to 1a34bbe, but neither the documentation nor the release notes mention anything about it.

Sample configuration:

spring:
  profiles:
    active: composite
  cloud:
    config:
      server:
        bootstrap: false
        composite:
          - type: native
            search-locations: local
          - type: vault  # no authentication, should be inherited from spring.cloud.config.server.vault
            # works with spring cloud 4.2 but not with 5.0
            host: vault-host
            port: 443
            scheme: https
            kvVersion: 2
            backend: vault/backend/another/path
        vault:
          host: vault-host
          port: 443
          scheme: https
          kvVersion: 2
          backend: vault/backend/path
          authentication: KUBERNETES
          kubernetes:
            role: config-server-role
            kubernetes-path: kubernetes

[ryanjbaxter]

Why not include the vault authentication configuration in the composite?

[tstenner]

That works (already tested it), but it's a breaking change we would have to communicate to our users.
If it's intended, it should be noted in the release notes. If not, I could prepare a MR to restore the old behavior in the next few weeks.

[ryanjbaxter]

Does it work as you expect in 4.3.x or is it broken there as well?

[tstenner]

I just checked and it's already omitting the authentication config with spring cloud starter 2025.0 (i.e. spring boot 3.5 + spring cloud 4.3).

[ryanjbaxter]

Ok then we would gladly accept a pr to restore the behavior in the 4.3.x branch to restore the behavior. But we will leave the existing behavior in the 5.0.x branch since we believe that is the correct behavior