Add support for creating property sources from volume-mounted Kubernetes ConfigMaps and Secrets

[mbhave]

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.

[markpollack]

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. /secrets Each filename is the property key and the contents are the value. Perhaps a class such as KubernetesSecretFileApplicationListener that 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)