For secrets, prefer mounted files read with Spring Boot's configtree import over plain environment variables. The Spring Boot docs say storing config values in environment variables has drawbacks, especially for secrets, and suggest mapping configuration into mounted data volumes, which Kubernetes supports for both ConfigMaps and Secrets.
The problem with environment variables
Environment variables are easy, which is why they are everywhere. But they are inherited by child processes, show up in some diagnostics and crash reports, and can be visible to other tooling on the host. They are also what the Actuator env endpoint reads, so a mistake there can show them. The Boot docs list the drawbacks without detail, so check your own platform's behaviour.
What configtree does
The documentation describes two common volume mount patterns. In one, a single file holds a full set of properties. In the other, many files are written into a directory tree, where each file name becomes the key and its contents become the value. For the second, you import with the configtree prefix:
spring.config.import=optional:configtree:/etc/config/
With a folder named myapp that contains files called username and password, the application can read myapp.username and myapp.password from the Environment in the usual way. The docs also show a wildcard form that imports each immediate child folder as its own tree, and say values can bind to String and byte array types.
| Source | Where the secret sits | Notes |
|---|---|---|
| Plain properties file in the jar | Inside the artifact | Avoid for secrets |
| Environment variable | Process environment | Easy, wider exposure |
| Configtree files | A mounted volume, one file per value | Lets the platform control file permissions |
Steps
- Search the repo and built artifact for passwords, tokens and keys in property files and profiles.
- Move each secret to your platform's secret store and mount it as files.
- Import with configtree, and mark the import optional only where the file is truly optional.
- Set file permissions on the mount so only the application user can read them.
- Keep the Actuator env endpoint unexposed, or leave values sanitized. See env values and show-values.
- Rotate any secret that has ever been in a repository or image layer.
Scanning for leaks
Secrets inside a jar or container layer persist even after you delete the source line. Scan built artifacts and images, not just source. Our guide to scanning a built jar explains the approach.
Safeguard scans dependencies, produces SBOMs and uses reachability analysis to show which findings your code can actually reach. You can run a free scan at gold.safeguard.sh/scan.
Quick check
Does configtree encrypt secrets?
No. It reads files. Protection comes from your platform's secret store and file permissions.
Does the optional prefix matter?
It lets the app start if the location is missing, which can hide a misconfiguration. Use it deliberately.
Sources
Last reviewed: 19 October 2026.
