TL;DR
TLS for Kubernetes does not necessarily end at the Ingress. Central TLS termination at the ayedo Edge Cloud simplifies certificate management, WAF integration, and traffic control. However, additional encryption up to the cluster protects further network segments. The right decision depends on trust boundaries, operating model, compliance, and desired fault isolation.
Introduction
A publicly accessible Kubernetes endpoint requires more than just a certificate at the Ingress. The critical factor is where the TLS connection ends and which path still needs protection afterward. If TLS is terminated solely at the edge, the backend typically receives HTTP or another unencrypted forwarding within the infrastructure. This can be operationally efficient but shifts the trust boundary. A second TLS path up to the Kubernetes service increases both protection and complexity. Therefore, for TLS for Kubernetes, the question is not "Edge or Ingress?" but rather the clear assignment of responsibility, certificate lifecycle, and network trust.
1. TLS Termination at the Edge as a Central Architecture
With TLS termination at the edge, the ayedo Edge Cloud receives the public HTTPS connection. The certificate for the external hostname is managed there, and the encrypted data stream is decrypted at the edge. Subsequently, the edge can forward the traffic to a Kubernetes backend based on hostnames, paths, and other rules.
This approach centralizes a key operational task. Certificates do not need to be deployed in every Kubernetes cluster, namespace, or Ingress controller. Rotation, assignment of multiple domains, and public accessibility are handled at an upstream point. Simultaneously, the Edge Cloud can apply functions such as WAF, DDoS protection, and load balancing on the already decrypted HTTP/HTTPS traffic.
The consequence is a clear trust boundary: The network between the edge and backend must be considered sufficiently trustworthy or secured separately. Particularly with multiple providers, distributed clusters, or administratively separated platforms, this assumption should be documented and regularly reviewed.
2. Encryption up to the Kubernetes Backend
An additional TLS connection from the edge location to the Kubernetes backend reduces the unencrypted trust zone. The traffic remains encrypted even on the segment between edge and cluster. This is relevant when network paths run over shared infrastructure, clusters are operated outside one's own network domain, or internal security policies require end-to-end protection.
However, this creates a second certificate responsibility. The backend requires a certificate whose hostname matches the connection or whose verification is specifically configured. Additionally, trust stores, certificate rotation, and error diagnosis must be considered. A public certificate is not always necessary for this; for the internal path, a custom trusted certificate chain can be used, provided all involved components validate it correctly.
It is important to distinguish terms: TLS termination at the edge does not automatically mean that the backend path must be unencrypted. Between client and edge, as well as between edge and backend, two separate TLS sessions can exist. This is not a technical end-to-end connection in the cryptographic sense because the edge can terminate and process the traffic. However, it is an encrypted connection over both network segments.
3. Certificate Management Across Multiple Endpoints
Kubernetes applications often publish multiple endpoints: different domains, APIs, tenants, or environments. Therefore, certificate management must align with the routing model. A certificate can cover multiple DNS names via Subject Alternative Names, while separate certificates can more clearly isolate responsibilities and rotation. Key factors are SNI, host header, and the mapping between public name, edge configuration, and Kubernetes Ingress.
With central termination, the management of public certificates lies at the edge. The Ingress then only needs the configuration for the internal forwarding path. If certificates are additionally used in the cluster, their validity and rotation must function independently. An error in an internal certificate chain should not become visible only when the public certificate expires.
For platform teams, this means: Certificate management is not an isolated Kubernetes task. DNS, edge routing, Ingress rules, secret distribution, and monitoring form a common operational chain. The ayedo Edge Cloud can serve as a provider-independent public entry point in front of Kubernetes clusters operated on one's own or by other providers. This prevents each cluster from having to fully replicate its public TLS and traffic architecture separately.
4. Responsibility Boundaries and Operational Implications
The most important architectural decision is the division of responsibilities. The Edge Cloud takes over the public entry, TLS termination, protection, and forwarding. Kubernetes typically handles service discovery, Ingress rules within the cluster, and the application itself. This separation reduces coupling but does not replace clear documentation of data flows.
For operations, at least four error scenarios must be distinguishable: an expired edge certificate, an unreachable backend, an error in internal TLS verification, and incorrect routing for hostname or SNI. Traffic and usage statistics at the edge can support the analysis of public data streams. Health checks and failover are relevant when multiple backends or clusters serve as targets.
Backend cloaking complements this model: Public clients do not need to know the actual Kubernetes endpoints. This keeps cluster addresses and internal topology out of the public DNS and routing model. The Edge Cloud thus not only provides a certificate function but also forms a controlled boundary between the internet and compute infrastructure.
Practical Scenario: API with Separate Trust Boundaries
A company operates an API in its own Kubernetes cluster and publishes it under api.example.org. The TLS connection from the client ends at the ayedo Edge Cloud. There, WAF rules, DDoS protection, and routing are applied. For a protected internal network path, a second TLS connection to the Ingress is then established.
The public certificate rotation remains at the edge. The cluster only manages the certificate for the internal connection and its trust chain. In a less isolated environment, forwarding could occur unencrypted if the network path is controlled. However, the decision should be made consciously based on data classification, provider boundaries, and operational effort—not out of habit.
FAQ
Does the Kubernetes Ingress always need its own public certificate?
No. With TLS termination at the edge, the Ingress does not need a public certificate. However, for an additional encrypted backend path, a suitable internal certificate and trust configuration are required.
Is TLS passthrough synonymous with TLS termination?
No. With passthrough, the TLS connection remains intact up to the backend. With termination, the edge decrypts the traffic and can inspect, route, and secure it.
How many certificates are needed for multiple Kubernetes clusters?
This depends on domains, trust boundaries, and the chosen termination. A public certificate at the edge can serve multiple backends; internal TLS paths may each require their own certificates.
Conclusion
TLS for Kubernetes is an architectural question, not merely an Ingress configuration. Central TLS termination at the edge reduces certificate and operational effort and creates a unified public entry point. Additional encryption up to the backend protects further network segments but requires more certificate and trust management. The ayedo Edge Cloud positions these tasks ahead of the compute infrastructure, enabling a deliberate separation of public traffic, edge responsibility, and Kubernetes operations.