You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When specifying a custom secret name using existingSecret in the Bitnami chart with the required values then causes several containers to fail to deploy as these are using a generated secret name even when the secret name is provided. I see in the sample values that this isn't supported but it really should be as this is the modern way to manage secrets in kubernetes.
It's not supported because we still have microservices that read database credentials from the config file (not ENV).
For example, here you can see we're generating configmap based on values, then that configmap will be mounted as a configuration file for grpc microservice.
As soon as all microservices support databases access credentials via ENV, the helm chart will be updated, and using existingSecret will become possible
When specifying a custom secret name using
existingSecret
in the Bitnami chart with the required values then causes several containers to fail to deploy as these are using a generated secret name even when the secret name is provided. I see in the sample values that this isn't supported but it really should be as this is the modern way to manage secrets in kubernetes.This is an example of a place that this needs to be updated: web-service-backend.yaml
This is another spot that breaks when using an existing secret: grpc.yaml
The text was updated successfully, but these errors were encountered: