Letsencrypt/Cert Manager workflow for apps served through Istio VirtualService/Gateway

Question

Is there a common (or any) workflow to issue and renew LE certificates for apps configured in an Istio VirtualService & Gateway? The Istio docs only cover an Ingress use case, and I don't think it covers handling renewals.

My real world use case is about making this work with a wildcard cert and custom applications, but for the sake of simplicity, I want to figure this out using the Prometheus service installed with the Istio demo. The VirtualService and Gateway are necessary for my real world use case.

Here is how I am currently serving Prometheus over https with a self-signed cert. I am running Istio version 1.5.2 on GKE K8s version 1.15.11. Cert Manager is installed as well.

So how would I adapt this to use Cert Manager for issuing and renewing an LE cert for prom.example.com?

---
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: prometheus-gateway
  #namespace: istio-system
spec:
  selector:
    istio: ingressgateway
  servers:
    - port:
        number: 443
        name: http-prom
        protocol: HTTPS
      hosts:
        - "prom.example.com"
      tls:
        mode: SIMPLE # enables HTTPS on this port
        serverCertificate: /etc/istio/ingressgateway-certs/tls.crt
        privateKey: /etc/istio/ingressgateway-certs/tls.key
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: prometheus-vs
spec:
  hosts:
    - "prom.example.com"
  gateways:
    - prometheus-gateway
  http:
    - match:
        - port: 443
      route:
        - destination:
            host: prometheus
            port:
              number: 9090

Answer 1

TL;DR

Configure cert-manager with DNS domain verification to issue certificate, renewal is handled automatically.

Few notes on the example in Istio docs that hopefully will clarify the workflow:

• cert-manager knows nothing about Istio, it is key role is to issue and renew certificate then save them to a secret object in kubernetes.

  • LE ACME verification is typically done with DNS e.g. AWS Route53

  • Issued Certificate secret will be in a specific k8s namespace and not visible outside that.

• Istio knows nothing about cert-manager, all what it needs is the issued certificate secrets which is configured in the gateway with SDS. This means two things:

  • The name of the SDS secret must match the one cert-manager produces (this is the only link between them)

  • The secret must be in the same namespace where the Istio gateway will be.

• Finally, your VirtualServices just need a gateway that is configured properly as above. The good news is, VirtualService can link to gateway in any namespace if you used the full qualified name.

So you can have your gateway(s) in the same namespace where you issue the Certificate object to avoid copying secrets around, then your VirtualServices can be in any namespace just use the full gateway name.