Background
I'm currently developing a Helm Chart for my application. The chart has a dependency to bitnami/mongodb
. That chart creates the following secret:
---
# Source: mongodb/templates/secrets.yaml
apiVersion: v1
kind: Secret
metadata:
name: RELEASENAME-mongodb
namespace: default
labels:
app.kubernetes.io/name: mongodb
helm.sh/chart: mongodb-8.2.1
app.kubernetes.io/instance: RELEASENAME
app.kubernetes.io/managed-by: Helm
app.kubernetes.io/component: mongodb
type: Opaque
data:
mongodb-root-password: "ZHVtbXlwYXNzd29yZA=="
mongodb-password: "cGFzc3dvcmQ="
(helm template RELEASENAME bitnami/mongodb --set auth.rootPassword=dummypassword,auth.username=username,auth.password=password,auth.database=database
)
My application of course wants to make use of the provided MongoDB, however I need to provide more than just the password but also a username, database and a connection URI to it in order to be able to connect to the database.
Question
What's the best way to provide the entire configuration (username, password, database, connection URI) to my application container without duplicating the existing secret and also without distributing the configuration among multiple configuration sources (configmap, secret, environment) ?
Edit (concretization):
Since this question revolves around Helm Chart development, I'd like to have a self contained solution within my Chart instead of having to rely on patching / updating the deployment objects in the cluster once helm install
has run.
Thoughts / Remarks
Probably the simplest way is to provide everything via the environment. However the list will get longer and longer the more dependencies get added to my application. I've noticed that people seem to prefer config maps / secrets over plain environment configuration.
However I can't find a way to reference one secret from another secret in such a way as it is possible in the environment config via an EnvVarSource.
Next I thought about patching the existing secret to add the missing credentials somehow while the chart is still rendering, however I can't find a way to do that.
Finally I could provide the username, database and connection URI via a second secret or a config map (depending on whether you would consider those part of the credentials [ref]) and only provide the password via the environment. What I don't like about this approach is that I'd have to split up one logical configuration unit into multiple sources.