Repository navigation
Add support for creating property sources from volume-mounted Kubernetes ConfigMaps and Secrets #19990
Description
Activity
- added this to the milestone
on Jan 30, 2020 I think it is out of scope for Boot to get involved with the lifecycle of changing a secret value. AFAIK, Boot does not handle the case of a change in a configmap that is loaded by
ConfigFileApplicationListener. ( #19909 ) There are several tools and approaches to handle this (kustomize with secret/configmap generators) or a custom controller (https://github.com/stakater/Reloader ) that end up restarting the pod. Watching the filesystem where the secrets are mounted doesn't feel like the right solution either, as it would end up competing with these other more well known approaches. I think the scope of this issue should be reading the secrets mounted on the filesystem in one or more directories under a common root, e.g./secretsEach filename is the property key and the contents are the value. Perhaps a class such asKubernetesSecretFileApplicationListenerthat contains that logic to create the property sources from the secrets mounted on the filesystem. Mounting secrets on the filesystem is considered the best practice (vs. using environment variables)
This issue addresses the case where configmaps are not mounted as as an
application.properties(or yml) file. For secrets, we need to consider things like if the secret changes, what happens to configuration that has been created using that secret.