ACME DNS Challenge with the Edge Cloud in Kubernetes

TL;DR

The ACME DNS-01 Challenge enables TLS certificates for Kubernetes services without making the backend accessible from the internet. Key factors include separate DNS permissions, a unique domain assignment, and the question of where TLS is terminated. Behind the ayedo Edge Cloud, this termination point is at the public edge, not necessarily within the cluster.

A TLS certificate is often considered a Kubernetes problem, although with an upstream edge architecture, multiple systems are involved: the ACME client component, the authoritative DNS zone, the edge configuration, and the Kubernetes backend. Mixing these responsibilities can lead to unnecessary permissions, unclear operational processes, and difficult-to-trace failures in case of errors.

The central architectural decision is therefore not only how a certificate is issued. It must also be determined which component controls the domain, where the proof of domain ownership is stored, and at which point the encrypted connection is terminated.

1. DNS-01 Instead of Public Accessibility

In the ACME DNS Challenge, an ACME client proves control over a domain by placing a TXT record under _acme-challenge. The certificate authority queries this record via DNS. Unlike HTTP-01, no web server in the Kubernetes cluster needs to be accessible from the internet.

This is relevant for internal or shielded backends. A service can be published exclusively via the ayedo Edge Cloud, while its actual Kubernetes address is not publicly routed. The edge handles the public entry and forwards successful traffic to the backend. This reduces the attack surface and prevents the certificate issuance from requiring a direct internet connection to the cluster.

However, DNS-01 shifts the security requirement to the DNS level. Anyone who can change TXT records in the relevant zone can fundamentally influence domain validations. This permission should therefore not be granted indiscriminately for the entire DNS account. It is better to limit rights to the required zone or a controlled namespace.

2. Cleanly Limit DNS Permissions

For issuing TLS certificates in Kubernetes , the ACME client needs access to DNS management. This access should be separated from the company’s other credentials. In particular, a certificate component should not automatically be able to change nameservers, MX records, or productive routing entries when only _acme-challenge is needed.

Practically, this means a clear separation of responsibilities: The ACME client may set and remove the validation record. The assignment of the public domain to the edge cloud remains separate from this. Credentials should also not end up as unprotected configuration values in manifests or version control. In Kubernetes, such credentials belong in appropriate secret mechanisms with limited access and traceable rotation.

Organizationally, the separation is also important. DNS administrators do not necessarily need cluster administration rights, and the platform team should not automatically require full control over all company domains. A limited permission model reduces the risk of erroneous changes and facilitates audits, incident response, and handovers between network, security, and platform teams.

3. Domain Assignment Between DNS, Edge, and Cluster

The DNS-01 Challenge only confirms control over the domain. It does not automatically define which Kubernetes service is later accessible. For this, a consistent assignment between hostname, edge configuration, and backend is needed.

A typical path is: api.example.de publicly points to the ayedo Edge Cloud. There, a service is configured for this hostname, including backend target and health checks. The backend can be under a non-public address. The edge cloud thus forms the controlled public entry, while backend cloaking prevents internal accessibility from being derived from the public DNS and traffic model.

For operations, wildcards and individual hostnames must also be consciously distinguished. A certificate for *.example.de does not automatically cover the apex domain example.de. When domains are distributed across multiple clusters, providers, or environments, it must be clear which platform manages the respective zone or validation namespace. Otherwise, a valid DNS proof may exist, even though the traffic reaches the wrong edge or backend configuration.

4. Plan TLS Termination at the Edge

The DNS-01 Challenge answers the question of how the certificate authority verifies domain ownership. TLS termination, on the other hand, answers where the encrypted client connection ends. In an edge architecture, this point is often before the Kubernetes cluster. The ayedo Edge Cloud can terminate TLS at the edge and then forward the decrypted traffic to the configured backend.

This leads to an important operational rule: The issued certificate must be available at the termination point. A certificate that only exists as a Kubernetes secret in the cluster does not automatically protect the connection between client and edge. Issuance, storage, renewal, and provision of the certificate must therefore be considered as a coherent process.

The connection between edge and backend is to be evaluated separately. Depending on the protection needs, TLS can be used again there; this is an architectural decision and not an automatic consequence of the DNS-01 Challenge. It is crucial to explicitly document the trust boundaries: client to edge, edge to backend, and ACME client to DNS management. This allows processes, responsibilities, and error patterns to be clearly assigned.

Practical Scenario: Kubernetes Service Without Public Backend

A company operates api.example.de in its own Kubernetes cluster with any provider. The backend has no public IP and only accepts traffic from the edge. The domain points to the ayedo Edge Cloud; there, hostname, TLS termination, backend target, and health checks are configured.

For certificate issuance, an ACME component performs the DNS-01 Challenge. It only receives permission to manage the required _acme-challenge record. After successful validation, the certificate is provided at the intended TLS termination point. If the backend fails, the edge can recognize the state through health checks and apply appropriate failover behavior. The certificate check remains independent of the direct accessibility of the cluster.

FAQ

Does ACME DNS-01 require a publicly accessible Kubernetes service?

No. The certificate authority checks the TXT record in DNS. The Kubernetes service does not need to be directly accessible from the internet for this.

Where must the TLS certificate be stored?

Where TLS is terminated. For TLS termination at the edge, the certificate must be available to the edge; a Kubernetes secret alone is not automatically sufficient.

Can DNS-01 be used for multiple Kubernetes clusters?

Yes, provided domain assignment and responsibilities are clearly regulated. Especially with shared DNS zones, validation rights and hostnames must be cleanly separated by environment.

Conclusion

ACME DNS Challenge and Kubernetes form only part of the certificate architecture. For shielded backends, DNS-01 is suitable because domain validation works without direct internet access to the cluster. The actual operational effort lies in limited DNS rights, consistent domain assignment, and the provision of the certificate at the correct TLS termination. The ayedo Edge Cloud serves as the public, centrally controlled termination point before the backends—regardless of where Kubernetes is operated.