Configuring Secrets Priority in propertySources

[arjavdongaonkar]

In the current setup, Kubernetes Secrets appear at the bottom of the propertySources list in the API response.

Example response:

"propertySources": [
  { "name": "vault:application" },
  { "name": "secret:ab-service-secrets" }
]

This ordering means that values from Kubernetes Secrets have lower precedence than other configuration sources. However, in many cases, it would be preferable for Kubernetes Secrets to take priority, allowing other configurations to resolve their values using Secrets.

Questions

1. Is there a way to configure the order of propertySources so that Kubernetes Secrets appear at the top of the list?
2. If not, would it be possible to introduce an option to adjust the precedence of Kubernetes Secrets dynamically?

Use Case
Having Kubernetes Secrets at the top of the list ensures that they override other configurations, making them the primary source of truth for sensitive values. This aligns with best practices for managing secrets in Kubernetes-based environments.

Looking forward to your insights on this!

[wind57]

is this still about config server? I think it is, but it's not clear... can you please make that explicit? thank you

[arjavdongaonkar]

Sure, I have my Spring Cloud Kubernetes Config Server running in a k8s cluster on port 8888 with the following setup:

• Spring Cloud Kubernetes Config Server version: 3.2.0
• kubernetes is included in the list of active profiles.
• Secrets are enabled using:

  spring.cloud.kubernetes.secrets.enableApi=true

• The pod has correct role bindings to access Kubernetes Secrets.
• Vanilla Spring Cloud Config Server version (when working normally): 4.2.0

When I try to access secrets using the following curl command:

curl --location 'http://localhost:8888/ab-service/ab-service,secrets'

I get the following API response:

"propertySources": [
  {
    "name": "vault:application",
    "source": {
      "TOKEN_A": "some_token_1",
      "TOKEN_B": "${TOKEN_E}_some_token",
      "TOKEN_C": "some_api_key"
    }
  },
  {
    "name": "secret:ab-service-secrets",
    "source": {
      "TOKEN_D": "some_token_2",
      "TOKEN_E": "some_token_3"
    }
  }
]

In this setup:

• TOKEN_E is stored in Kubernetes Secrets (secret:ab-service-secrets).
• TOKEN_B depends on TOKEN_E (TOKEN_B = ${TOKEN_E}_some_token).

Since Kubernetes Secrets appear below Vault in the propertySources array, the system fails to resolve TOKEN_E while evaluating TOKEN_B.

• If Kubernetes Secrets were at the top, TOKEN_E would be available for resolving TOKEN_B.
• This behavior works correctly in vanilla Spring Cloud Config Server, where the order can be explicitly controlled using spring.profiles.active as composite and defining the spring.cloud.config.server.composite structure.

In Vanilla Spring Cloud Config Server, we can explicitly define:

spring:
  cloud:
    config:
      server:
        composite:
          - type: vault
          - type: git

This setup ensures that Vault values are resolved first, allowing Git configurations to reference secrets from Vault.

I have created this new issue as suggested by @ryanjbaxter here

[ryanjbaxter]

We will need to look into this. We might need to do some work to make something like this to work:

spring:
  cloud:
    config:
      server:
        composite:
          - type: kubernetes
          - type: vault

[arjavdongaonkar]

Yes, I can see we are using CompositeUtils.getFactoryName to allow composite types to inject the repository into propertySources.
Would simply adding a KubernetesRepositoryFactory bean in codebase be sufficient, or do we need to make any additional changes?
Am I on the right track with this approach?

[arjavdongaonkar]

Hey @ryanjbaxter
I’ve raised a PR to introduce support for kubernetes as a composite config source. The changes include:

• Added KubernetesEnvironmentRepositoryFactory to enable composite repository support.
• Updated KubernetesConfigServerAutoConfiguration to provide the factory bean.

This allows users to define Kubernetes as a composite type like:

spring:
  cloud:
    config:
      server:
        composite:
          - type: kubernetes
          - type: vault

Can you please take a look?

P.S. Please ignore the weird commit msg :)