Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for kubernetes secret style certificates #3018

Closed
taxilian opened this issue Jan 26, 2022 · 3 comments · Fixed by #3344
Closed

Add support for kubernetes secret style certificates #3018

taxilian opened this issue Jan 26, 2022 · 3 comments · Fixed by #3344

Comments

@taxilian
Copy link

Is your feature request related to a problem? Please describe.

I'm in the process of setting up a stack with wildduck, haraka, and zone-mta for a new mail server on a kubernetes cluster; it's going quite well, but I ran into a snag when I went to set up certificates to use with haraka TLS. Kubernetes has cert-manager which can handle getting letsencrypt certificates for domains which I have been doing; those are stored as a "tls" type secret in kubernetes -- it's just a standard, nothing really special.

The challenge is that the simplest way to map those into a container -- the least extra configuration needed -- puts each "secret" in a directory with "tls.crt" and "tls.key"; however I try to use those I can't use more than one certificate pair at a time without adding some kind of special handler.

Describe the solution you'd like
I'd like to see one or both of two options (ideally both):

  1. In the "certificates" directory if there are any directories found containing exactly one .crt and one .key file (or maybe specifically named tls.crt and tls.key it should load them the same way it would load if it found a pem file with both in the certificates directory
  2. If you specify multiple keys and certs using key[]= and cert[]= it should support having each be a different domain using SNI -- to be honest I expected that to be the functionality when I read the documentation, I'm not sure why else you'd need to have multiple, but from what I can see in the code it doesn't support that and when I tried it (before reading the code) it didn't work.

Describe alternatives you've considered

Right now I'm only using a single TLS certificate for a single domain; the best option I can think of to make this work on a longer term basis is to write something which will detect when the LE certificate secret is updated and create an additional certificate (or possibly add a key to that secret) for the .pem file with both in it, then map those .pem files into the container. This isn't ideal and would be a pain, but it should work.

It would also help if haraka could detect when the certificate files changed and update, but I can work around that by ensuring the pod gets restarted at least every month or so.

Additional context

It might even make sense to just go ahead and support it on a more specific level, e.g. kubernetes-specific flags; in that case you could pull them from environment variables or just have a "kubernetes secrets" path for the root of where you mounted them all or something. For more information about tls secrets in kuberenetes see https://kubernetes.io/docs/concepts/configuration/secret/#tls-secrets

I'd be willing to help with this, but I'm not familiar with the codebase and dont' know how you'd want it implemented.

@dcharbonnier
Copy link
Contributor

@taxilian try this dcharbonnier@9a5a5a9 if it's ok I will make a PR

@msimerson
Copy link
Member

In the "certificates" directory if there are any directories found containing exactly one .crt and one .key file (or maybe specifically named tls.crt and tls.key it should load them the same way it would load if it found a pem file with both in the certificates directory

This seems quite reasonable to me.

It would also help if haraka could detect when the certificate files changed and update

Also, seems quite reasonable as well.

PRs welcome.

@msimerson
Copy link
Member

psst. Have a look at #3344

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants