[bitnami/mongodb] Mongodb Replicaset existingSecrets doesn't work with cert-manager

[rrileyca]

Name and Version

bitnami/mongodb 13.9.4

What architecture are you using?

amd64

What steps will reproduce the bug?

When setting values.yaml with the following values:

tls:
  enabled: true
  autoGenerated: false
  replicaset:
    existingSecrets:
      - mongodb-tls-0
      - mongodb-tls-1
      - mongodb-tls-2

Each secret must have a field ca.crt, as documented in the values.yaml comment. However, the Jetstack cert-manager (arguably a very common if not "standard" kubernetes application) does not produce such a field. Without the ability to inject the field manually in the helm chart, there is no integration capability out of the box.

Are you using any custom parameters or values?

values:

tls:
  enabled: true
  autoGenerated: false
  replicaset:
    existingSecrets:
      - mongodb-tls-0
      - mongodb-tls-1
      - mongodb-tls-2

What is the expected behavior?

Either the helm chart can deploy without a ca.crt, or it would provide a way to inject one.

What do you see instead?

The Pods fail to Init.

Running the command:

kubectl logs mongodb-0 -n mongodb -c generate-tls-certs 

I see the output:

cp: cannot stat '/certs-0/ca.crt': No such file or directory
chmod: cannot access '/certs/mongodb-ca-cert': No such file or directory

Additional information

No response

[rrileyca]

I actually did something similar to the Kafka chart, see here: #9422

[jotamartos]

Hi @rrileyca,

Thank you for taking the time to report this issue. Would you like to contribute again by creating a PR to solve the issue? As you are familiar with the solution and the repo, you will be able to make the necessary changes to make this work. The Bitnami team will be happy to review it and provide feedback. As always, you can find here the contributing guidelines.

Thanks

[rrileyca]

Hi @jotamartos,

I'm actually kind of confused as to how this chart would support any PKI certificates in ReplicaSet architecture. There are several problems:

1. A given MongoDB host requires that the rs.conf().memebers array contain a host name that is resolvable to itself ("itself" means on of the IP addresses on the host). In the case of a Kubernetes Pod, that means the value in the ReplicaSet configuration needs to be in the /etc/hosts file. I don't know where this occurs - but currently only the headless svc name is added to the hosts file. I don't see a way around this, unless there is a way to resolve a k8s fabric IP address for the container somehow.
2. The headless Service can't be used with PKI. I define (at least for this explanation) PKI to be public key infrastructure, meaning a Certificate Authority accessible on the Internet. The domain svc.cluster.local will never be signed by a PKI CA as you cannot prove ownership of that domain.

A potential solution here might be to add the FQDN when .values.externalAccess is set into the hosts file, but it's not clear to me where this should occur. Where is the headless service added to the hosts file?

What I have described above is a separate-but-related issue. If Bitnami can give me direction on the above comments, I will put in a separate issue and PR to fix that.

[dtrts]

Hi @rrileyca - It looks like we have been on a very similar journey.

Your points about how the domains through the chart do not integrate well with a TLS certificate provided by the cert-manager has also been causing us trouble.

I have described my approaches to some of these issues here: #16719
I have a PR open to help ease the initialization of the databases here: bitnami/containers#34297

As you've said we have been adding an FQDN to the hosts file using the hostsAlias: value.
Unfortunately I haven't yet found a way to add the node specific domain to the hosts file through the chart, so have resorted to using a localhost.external-domain-name.com as the hostAlias and ensuring our certificate words for that address.

---

I still believe taking the same approach as the kafka chart would be super valuable.

I am also working with a certificate which is missing the ca.crt attribute. I've resorted to setting tls.enabled: false and then reimplementing TLS through additional values and scripts, all to get around the fact that the init container will fail.

[dtrts]

I have created a PR to match the kafka changes: #16731

I was wondering if we should also consider an option to use /etc/ssl/certs/ca-certificates.crt as the CA file.
It was a valid workaround for our issues since it worked for our cert issuer
(NOTE: It does not work for letsencrypt staging environments since that root is not distributed as widely)

I have a few more experiments to run but will be running out of time this week, let me know if this provides any progress.