0

I have mounted one volume which contains DB password inside pod. If I do:

kubectl  exec -it my-app -- cat /mnt/secrets-store/dbpassword

It prints the db password value.

In my spring boot app, db password property is defined as spring.datasource.password in application.properties file. What configuration is required so that value for property spring.datasource.password is read from mounted secret.

priyam
  • 74
  • 7

3 Answers3

0

I guess in your case you can simply specify the location of the additional properties file. There is a dedicated section in offical documentation about it.

Simply put, you add --spring.config.additional-location=/path/to/config/file as an argument to your java executable and you should be good to go.

Just beware that, best to my knowledge, this feature was introduced in spring-boot version somewhere near 2.1.13 (At least I managed to find release docs, so I guess I am right). So also you need to make sure spring-boot version is appropriate.

Mikhail2048
  • 1,715
  • 1
  • 9
  • 26
0

I think you cannot use Kubernetes's secret in application.properties directly, not to my knowledge at least. In your case I think you can insert it as an environment variables

env:
- name: DB_PASSWORD
  valueFrom:
    secretKeyRef:
      name: db_credentials
      key: password

After inserting it as environment variables then you can use it in your application.properties just like another placeholder

spring.datasource.password=${DB_PASSWORD}
Aleson
  • 332
  • 2
  • 9
  • There is no need to use environment variable substitution inside the `application.properties`. The env variables already override the ones on `application.properties` – Spyros Palaiokostas Jul 18 '23 at 07:42
  • i didn't substitute anything, his question was how to use the **kubernetes's secret** value in his `application.properties` so i told him to inject it into the environment variables and then use it – Aleson Jul 18 '23 at 10:15
0

Spring Boot provides options to read the application properties from multiple sources and allows sensible overriding.

Here is the order that the application properties are considered.

As you can see, the OS environment variables override the Application properties packaged inside your jar (application.properties and YAML variants).

Also, when you use environment variables rather than system properties, most operating systems disallow period-separated key names, but you can use underscores instead (for example, SPRING_CONFIG_NAME instead of spring.config.name). This is possible because Spring allows for relaxed-binding

In your case, creating a SPRING_DATASOURCE_PASSWORD env variable in the pod would suffice and it would override the dummy that is defined on application.properties

Spyros Palaiokostas
  • 330
  • 1
  • 9