itzg / kita

An easy-to-deploy and easy-to-use ACME client service for Kubernetes Ingress instances

An easy-to-deploy and easy-to-use ACME client service for Kubernetes Ingress instances.

Kubernetes Ingress TLS using ACME

Why not cert-manager?

Keeping my cert-manager configuration correct was an ongoing struggle. Ultimately, I ran into an issue where cert-manager didn't set the ingressClassName correctly on the solver, no matter what I told it. I had a cert that was about to expire within a week...so I wrote this application.

Installation

Configuration

Apply the kita config map by applying the starter config, replacing SET_TO_TRUE with true and CONFIGURE_EMAIL with your email address:

kubectl create --edit -f https://raw.githubusercontent.com/itzg/kita/main/config-starter.yml

Install

kubectl apply -f https://raw.githubusercontent.com/itzg/kita/main/install.yml

Upgrading

If the kita deployment's image is the default latest, then restarting the deployment will pick up the newest image:

kubectl rollout restart deployment/kita

Otherwise, change the image tag on the deployment and re-apply.

Usage

Add the label acme.itzg.github.io/issuer to your ingresses with its value set to one kita.issuers keys in the config map created above.

For example:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  labels:
    acme.itzg.github.io/issuer: letsencrypt-prod
  name: app
spec:
  ingressClassName: public
  rules:
  - host: app.example.com
    http:
      paths:
      - backend:
          service:
            name: app
            port:
              name: http
        path: /
        pathType: Prefix
  tls:
  - hosts:
    - app.example.com
    secretName: app-tls

kita's Issues

Perform self-check on hostname being resolvable

...but make it opt-in since some home network ISP routers do not support hairpin routing

Retrieval of ACME directories at startup sometimes fails with DNS resolution error

This might be specific to my microk8s installation, but wanted to note for investigating later:

Caused by: java.net.UnknownHostException: Failed to resolve 'acme-v02.api.letsencrypt.org' after 4 queries
        at io.netty.resolver.dns.DnsResolveContext.finishResolve(DnsResolveContext.java:1047) ~[netty-resolver-dns-4.1.77.Final.jar:4.1.77.Final]
        at io.netty.resolver.dns.DnsResolveContext.tryToFinishResolve(DnsResolveContext.java:1000) ~[netty-resolver-dns-4.1.77.Final.jar:4.1.77.Final]
        at io.netty.resolver.dns.DnsResolveContext.query(DnsResolveContext.java:418) ~[netty-resolver-dns-4.1.77.Final.jar:4.1.77.Final]
        at io.netty.resolver.dns.DnsResolveContext.tryToFinishResolve(DnsResolveContext.java:971) ~[netty-resolver-dns-4.1.77.Final.jar:4.1.77.Final]
        at io.netty.resolver.dns.DnsResolveContext.access$700(DnsResolveContext.java:66) ~[netty-resolver-dns-4.1.77.Final.jar:4.1.77.Final]
        at io.netty.resolver.dns.DnsResolveContext$2.operationComplete(DnsResolveContext.java:471) ~[netty-resolver-dns-4.1.77.Final.jar:4.1.77.Final]

Might need to asynchronously retrieve directories slightly later after startup.

Wrap ingresses to reconcile in flux

Wrap this iteration in a flux

kita/src/main/java/app/services/ApplicationIngressesService.java

Lines 105 to 107 in aa95497

	for (final Ingress ingress : ingresses.getItems()) {
	reconcileIngressTls(ingress);
	}

When ingress is deleted, delete the associated TLS secret