Ingresses that serve their hosts without TLS

Plain HTTP between clients and the cluster

The Ingress documentation describes TLS as opt-in: you secure an Ingress by referencing a Secret that contains a TLS private key and certificate, under keys named tls.crt and tls.key. The Ingress resource supports a single TLS port, 443, and terminates TLS at the ingress point. When several hosts share the TLS section, they are multiplexed on that port using SNI, provided the controller supports it.

Leave the section out and the controller serves the hosts over HTTP. Logins, API tokens and cookies then travel unencrypted between the client and the load balancer, where anyone on the network path can read or alter them. Note that even with TLS configured, the documentation says traffic from the ingress point to the Service and its pods is plaintext.

Listing Ingresses with no TLS section

kubectl get ingress -A -o json | jq -r '
  .items[]
  | select(((.spec.tls // []) | length) == 0)
  | "\(.metadata.namespace)/\(.metadata.name) hosts=\([.spec.rules[]?.host] | join(","))"'

A TLS flag per Ingress

ZopNight records whether each Ingress has TLS configured and fires when it does not. An Ingress for which that fact was not collected is skipped rather than assumed insecure. The check runs on every evaluation with no threshold or delay, and adding a TLS section clears it on the next pass.

Ingresses deliberately left on HTTP

Certificate automation needs plain HTTP for a moment. During an ACME HTTP-01 challenge, cert-manager creates temporary resources to answer the certificate authority, and ZopNight skips Ingresses whose name starts with cm-acme-http-solver- for that reason. An Ingress that has TLS but never received an address is a separate problem, reported by Ingress has no address.

Exposure rather than spend

This high-severity security finding carries no savings figure. The risk is credential theft and session hijacking on public endpoints, plus compliance findings for unencrypted transport.

Turning on TLS

1. Obtain a certificate for the Ingress hosts, manually or through an automated issuer such as cert-manager.
2. Store it as a TLS Secret in the Ingress namespace: kubectl create secret tls <secret-name> --cert=path/to/tls.crt --key=path/to/tls.key.
3. Add a tls block to the Ingress listing the hosts and secretName, then apply it.
4. Test HTTPS for each host and check the certificate chain.
5. Configure your controller to redirect HTTP to HTTPS; the setting is controller-specific.