For most Spring Boot applications on Kubernetes, mount Secret keys as files and import their directory with Spring Boot’s configtree: support. This avoids placing secret values in application.yml or environment variables, and does not require Spring Cloud Kubernetes for basic Secret delivery. Choose an optional import only if the application can safely start without those credentials; otherwise, let startup fail when the mount is missing.
How the configuration flow works
A Kubernetes Secret supplies confidential values to a Pod. When you mount it as a volume, each Secret key becomes a file. Spring Boot’s configuration-tree import reads files in the mounted directory and exposes their filenames as property names, so the application can consume them through Spring’s Environment or bind them to @ConfigurationProperties.
The Secret is an input mechanism, not a complete secrecy guarantee. Kubernetes documents that Secrets are stored unencrypted in the API server’s underlying data store, etcd, by default. Access controls and storage protection still matter.
Mount a Secret and import it in Spring Boot
1. Create a Secret
For example, a Secret can contain keys named after Spring properties. This illustrative manifest uses sample values only; do not commit real credentials to source control.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errors#1 Best Overall
apiVersion: v1
kind: Secret
metadata:
name: app-db-credentials
type: Opaque
stringData:
spring.datasource.username: app_user
spring.datasource.password: replace-with-a-real-secretApply a manifest using your normal deployment workflow, or create the Secret with kubectl or Kustomize. Avoid putting actual credential values in a tracked manifest. Keep ordinary, non-secret settings in a ConfigMap and confidential values in a Secret.
2. Mount it in the Deployment
Mount the Secret at a stable directory inside the application container. The following fragment shows the relevant parts of a Deployment; merge them into your existing Pod template and container definition.
spec:
template:
spec:
containers:
- name: app
volumeMounts:
- name: db-credentials
mountPath: /etc/config/myapp
readOnly: true
volumes:
- name: db-credentials
secret:
secretName: app-db-credentialsThe key names in the Secret become filenames under /etc/config/myapp, including the dotted names in this example.
3. Import the mounted directory
In the application’s application.properties, set:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Rank #3
spring.config.import=optional:configtree:/etc/config/myapp/Use optional: only if starting without the Secret is valid for that application. If database credentials are required, omit the prefix:
spring.config.import=configtree:/etc/config/myapp/Without optional:, a missing configuration-tree location prevents startup instead of silently leaving required properties unset.
4. Bind or read the properties
Because the mounted filenames are spring.datasource.username and spring.datasource.password, Spring Boot can resolve them as configuration properties. You can use the Spring Environment or bind related settings with @ConfigurationProperties. Do not print credential values in logs or expose them through diagnostics.
Choose the delivery method deliberately
| Method | Exposure surface | Startup and rotation considerations | When it fits |
|---|---|---|---|
Mounted Secret files with configtree: |
Files are available to processes in the container with access to the mount. | A required import can fail startup if the directory is missing. A changed Secret does not guarantee already-bound bean values update; plan a reread, refresh, or restart as appropriate. | The usual choice for confidential settings in a Spring Boot workload. |
| Secret values in environment variables | Values are injected into the container environment; Spring Boot warns that environment variables have drawbacks when a value is meant to remain secret. | Do not assume a changed Secret changes the environment of an already-running process or refreshes bound values. | Use only when the deployment or application specifically requires this interface and its exposure trade-offs are acceptable. |
| Spring Cloud Kubernetes API-based Secret access | Requires Kubernetes API access and appropriate authorization from the workload. | Reload or monitoring behavior must be configured; API access to Secrets may be restricted and is disabled by default for security reasons. | When Kubernetes-backed property sources, Secret lookup by name or labels, reload behavior, discovery, or Configuration Watcher are needed. |
For basic delivery, Spring Cloud Kubernetes is not a requirement. Spring Boot can read a mounted Secret using configtree: without fetching it through the Kubernetes API.
Best Value
Plan for rotation and reload
Updating a Secret is not the same as updating the value currently held by an application bean. A mounted value may become available through the filesystem, but an object that read and retained the old value does not necessarily reread it. The effective behavior depends on the mount, the client library, and the bean’s scope.
- Decide whether rotation takes effect after a controlled Pod restart, an application refresh, or an explicit reread by the component that uses the credential.
- Verify that the database or other client can adopt the new credential without requiring a new process.
- If using Spring Cloud Kubernetes reload or Secret monitoring, configure those features deliberately. Configuration Watcher can notify an application’s
/actuator/refreshendpoint when the required setup is in place. - Test the complete rotation path, including what happens if the replacement credential is invalid or the refresh notification is missed.
Protect the Secret and its access path
Apply controls at the cluster, namespace, workload, and container levels. Kubernetes warns that a user able to create a Pod or Deployment in a namespace can indirectly gain access to Secrets in that namespace, so reviewing direct Secret permissions alone is not enough.
Quick Recap
- Enable encryption at rest for Secrets in the API server’s data store.
- Use least-privilege RBAC, and review who can create or modify workloads in the Secret’s namespace.
- Limit which containers and processes can access the mounted directory; mount only the values the workload needs.
- Consider an external Secret store provider, such as the Secrets Store CSI Driver, when its integration and operational model better fit your environment.
- Keep credentials out of application configuration committed to source control, logs, and diagnostic output.
Common configuration mistakes
- Import path does not match the mount path: the directory in
spring.config.importmust be the directory where the Secret files appear inside the container. - Unexpected optional startup:
optional:deliberately allows the app to continue when the import is absent. Remove it when credentials are mandatory. - Assuming rotation refreshes beans: plan and verify the application-level reload or restart behavior rather than relying on the Secret update alone.
- Granting broad namespace permissions: deployment creation can provide indirect access to Secrets, so workload permissions belong in the same review as RBAC rules for reading Secrets.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
