[bitnami/redis] More flexibility needed for handling CA certificate

[tdg5]

Name and Version

bitnami/redis 20.2.1

What is the problem this feature will solve?

In order to use TLS, Redis needs

a CA certificate bundle file or path to be used as a trusted root when validating certificates [source]

redis-cli is a little more flexible in that it will:

If neither cacert nor cacertdir are specified, the default system-wide trusted root certs configuration will apply. [source (Disclaimer: these are valkey docs, but redis-cli --help says the same thing]

As such, bitnami/redis also insists upon being given a CA certificate.

This presents a problem when working with cert-manager which doesn't always include a ca.crt when issuing certificates:

Additionally, if the Certificate Authority is known, the corresponding CA certificate will be stored in the secret with key ca.crt. For example, with the ACME issuer, the CA is not known and ca.crt will not exist in acme-crt-secret. [source]

This leads to trouble with bitnami/redis because I'm left with two options:

1. Create a custom secret from the cert-manager secret that also includes a manually retrieved copy of the appropriate root certificate.
2. Hack a way around.

Option 1 doesn't work great for a CA like Let's Encrypt which issues certificates with a TTL of 90 days.
Option 2 is the route I've been forced to go, but the path forward is brittle and hacky.

I've created tdg5/bitnami-redis-ca-cert-shenanigans to document the working hack I've found and to demonstrate that it should be easier than this.

I'm happy to help contribute a solution, but I'd need some guidance on the right way to go about simplifying this problem.

What is the feature you are proposing to solve the problem?

I think the best option is to make the source of the CA certificate more configurable (e.g. don't require it to be a part of the TLS certificate). This would allow injecting custom root certificates and/or using trusted root certs already available in the docker image.

I don't love that this still requires mounting extra volumes to the pods (if the system doesn't have an acceptable root cert), but at least its a more explicitly supported path. At a minimum, it seems like forcing the CA certificate path to start with /opt/bitnami/redis/certs severely limits options and should be made more flexible.

Another less good option (IMHO) would be to make cacert an optional argument for uses of redis-cli since redis-cli will fallback to using the default system-wide trusted root certs. I've found that redis server will work if I tell it the CA is tls.crt, but redis-cli will not cooperate. This could allow for making the CA cert more generally optional. I worry though that this is not very explicit and maybe only solves a subset of awkwardness.

What alternatives have you considered?

Maybe I'm missing something, but it seems that the only alternative would be to craft a custom secret from the cert-manager certificate secret that also includes the CA, but that makes automation very difficult so it's not an option I'm willing to accept.