Support Kubernetes ConfigMap and Secrets as configuration/value sources

[maxandersen]

Description
Is #305 (comment) about mapping config map to a "magic destination" what we expect users to do for kubernetes deployments ?

Would it be better that quarkus-kubernetes extension or maybe a separate quarkus-kubernetes-config extension would have a configuration source that could be added in with a fairly high precedence order by default.

And then kubernetes-secrets would be available somehow to resolve values in any config source ?

[maxandersen]

approaches being discussed for this at smallrye/smallrye-config#215

[gastaldi]

From the mailing list, it would be nice to have a configuration source that

a) use token at /var/run/secrets/kubernetes.io/serviceaccount/token
b) use namespace from /var/run/secrets/kubernetes.io/serviceaccount/namespace
c) read all config-maps by default, possibly use labels to filter them.

[geoand]

approaches being discussed for this at smallrye/smallrye-config#215

This solution, when implemented, which be about much more than Kubernetes ConfigMaps. It will just make ConfigMaps retrieval very easy and completely integrated with the rest of the Quarkus way of doing things

[kenfinnigan]

If this results in not actually needing a ConfigSource that reads Kube ConfigMap, or reads anything else, that's fine, we just need to know so we don't expend effort in SmallRye if it isn't needed.

@radcortez, do you have any thoughts on this?

[radcortez]

The discussion around smallrye/smallrye-config#215 is more related to Quarkus than SmallRye. I believe we don't need anything in SmallRye to support what Quarkus is doing, but please let us know if we are missing something.

[geoand]

This should now be fairly easy to implement because we have the notion of a bootstrap configuration (see https://github.com/quarkusio/quarkus/blob/master/extensions/spring-cloud-config-client/runtime/src/main/java/io/quarkus/spring/cloud/config/client/runtime/SpringCloudConfigClientRecorder.java#L19).
Perhaps I'll take this up soon on some spare time.

[geoand]

I'll hopefully try and get a first version of this for 1.4

[geoand]

#8376 contains an implementation of this