Add support for cert-manager Issuer

[monrax]

See: https://cert-manager.io/docs/configuration/acme/http01/

[alix-graylog]

I believe this should already be supported. Assuming the cluster has an ingress class (ie ingres-nginx ) and an Issuer or ClusterIssuer configured to work with the ingress class. Then a user just needs to configure the Graylog Helm chart to utilize an ingress with the selected ingress class.
The cloud team uses ACM and AWS LB Controller so this wasn't explicitly tested in EKS. However I did test this in my bare metal k8s homelab using Lets Encrypt as the Issuer. There should be minimal differences in how these applications work in a cloud Kubernetes environment and bare metal.
Happy to provide some example configurations if that helps!

[williamtrelawny]

Can this be closed given @alix-graylog's response? A config example for users using cert-manager would be a great addition though if it's not too much work!

[monrax]

hey, @williamtrelawny! Unfortunately, no.

I really like that cert-manger now supports ingressClassName, and it's a better pattern than risking conflicts with other applications that also use issuers. However, I just tried it and it didn't work for me due to two things:

• A typo in ingress/graylog.yaml: there's no ingress.tls defined in values.yaml.
• The cert-manager.io/[cluster-]issuer annotation being required in the ingress resource in addition to the class name.

Just pushed a few minor changes to the feat/issuers branch that: 1. address the typo, and 2. add the ability to set the name of an existing cert-manager issuer (or cluster issuer), or let our chart provision an issuer specific for the ingress resource in our chart when no issuers can be found. That way we can avoid any issuer conflicts, from our side at least.

Additions to values.yaml

ingress:
  # new: enable/disable all ingress resources
  enabled: false
  # new: common ingress configuration
  config:
    tls:
      issuer:
        # set existing issuer (or cluster issuer) name for the ingress annotation
        existingName:
        # enable our own issuer if no existingName is specified, and no other issuers are found
        autoissue:
          enabled: false
          # use let's encrypt staging env by default (see: https://letsencrypt.org/docs/staging-environment/)
          staging: true
    # new: custom default backend
    defaultBackend:
      enabled: true
  web:
    # existing fields
  forwarder:
    # existing fields

Please take a look at it and let me know what you think @alix-graylog

[alix-graylog]

I took. a look. at feat/issuers. The part around creating a cert issuer feels like something I would typically expect cluster administrator to manage, but I don't see the harm in bringing it in I suppose.
The bug fix the ingress would be great to have. I didn't run into that issue because we use amazon cert-manger, which in my case terminates at the aws load balancer and not at the ingress.

While testing this out I found another bug with the ingress. I added a separate issue and PR to fix that.
Issue: #36
PR: #35

[alix-graylog]

Another thing we might want to think about, if Cert Manager changes the api for the cluster issuer, we may end up in a scenario where we need to support multiple versions, or specify which versions we will support like this. Just some food for thought thought.