Ich habe die folgende Ingress-Manifestdatei:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
namespace: fsm
name: fsm
labels:
app: fsm
annotations:
kubernetes.io/ingress.class: nginx
nginx.ingress.kubernetes.io/rewrite-target: /$2
cert-manager.io/issuer: "letsencrypt-staging"
spec:
tls:
- hosts:
- k8s-cluster.int
secretName: quickstart-example-tls
rules:
- host: k8s-cluster.int
http:
paths:
- path: /fsm(/|$)(.*)
backend:
serviceName: fsm
servicePort: 8081
Ich arbeite mit VMware mit Vsphere. Ich habe keine Domäne wiewww.google.com, nur ein DNS-Name, nämlich k8s-cluster, und die Domäne .int (innerhalb meines Unternehmens). Wenn ich versuche, das Zertifikat zu generieren, erhalte ich diesen Fehler:
"msg"="error waiting for authorization" "error"="acme: authorization error for k8s-cluster.int: 400 urn:ietf:params:acme:error:dns: DNS problem: NXDOMAIN looking up A for k8s-cluster.int - check that a DNS record exists for this domain" "dnsName"="k8s-cluster.int" "resource_kind"="Challenge" "resource_name"="quickstart-example-tls-w7vj9-4141989927-3312743172" "resource_namespace"="fsm" "resource_version"="v1" "type"="HTTP-01"
Kann dieses Problem auftreten, weil sich k8s-cluster.int in einem Intranet befindet? Wenn ich k8s-cluster.int curle
<html>
<head><title>308 Permanent Redirect</title></head>
<body>
<center><h1>308 Permanent Redirect</h1></center>
<hr><center>nginx/1.19.1</center>
</body>
</html>
Ich denke also, dass das DNS funktioniert.
Antwort1
Sie haben versucht, ACME zu verwenden. Let’s Encrypt verwendet dies. Das ACME-Protokoll ist im Grunde eine automatisierte DNS-Domänenvalidierung und gibt Ihnen ein „domänenvalidiertes“ Zertifikat. Es prüft, ob DNS-Einträge mit angeforderten Namen tatsächlich auf den anfordernden Server verweisen (oder unter der Kontrolle des anfordernden Servers stehen), was „beweist“, dass der Server über ein solches Zertifikat verfügen darf.
Dies bedeutet, dass die Domänenvalidierung nur für Domänennamen möglich ist, die sich im globalen DNS-Baum befinden. Sie verwenden ein „.int“-Suffix, das im globalen DNS-Baum nicht vorhanden ist (oder es existiert, aber Ihr Name existiert nicht oder gehört Ihnen nicht). Dies ist nicht das, was mit ACME „domänenvalidiert“ werden könnte.
Daher können Sie für diesen Namen keine Zertifikate mit ACME generieren. Tut mir leid.
Sie haben folgende Möglichkeiten:
- Instanziieren Sie Ihre eigene „interne“ Zertifizierungsstelle, lassen Sie deren Stammzertifikate auf allen beteiligten Rechnern als vertrauenswürdig einstufen und generieren Sie dann Zertifikate damit. Dies könnten beispielsweise MS AD-Zertifizierungsdienste sein. Dies erfordert einige Arbeit für die Instanziierung und Unterstützung der Zertifizierungsstelle, aber Sie können weiterhin „.int“ verwenden.
- Verwenden Sie eine Subdomäne einer global registrierten Domäne, ändern Sie also Ihr „.int“-Suffix in etwas wie „.int.example.com“, wobei example.com Ihre gekaufte und delegierte Domäne ist. Dann könnten Sie beispielsweise einen Reverse-Proxy einrichten und alle Ihre „internen“ Namen auf die öffentliche Adresse dieses Proxys im globalen DNS verweisen, um ACME für Ihre „internen“ Hosts verwenden zu können.
Nach langjähriger Erfahrung als Netzwerktechniker bin ich bei dieser zweiten Alternative gelandet. Ich verwende nie „getrennte private interne“ Namen wie „.int“, „.local“, „.lan“ usw. für interne Dienste, selbst wenn ich weiß, dass ich sie nicht mit der „Außenwelt“ verbinden werde, selbst wenn sie physisch vom Internet getrennt sind. Ich verwende immer etwas, das von meinen eigenen globalen Domänennamen abstammt. Das hat mir viel Arbeit erspart. Und wenn ich manchmal auf ein Netzwerk stoße, in dem diese „getrennten“ Namen verwendet werden, gibt es fast immer einige schmutzige Macken, um obskure Probleme zu lösen, die bei der Verwendung globaler Namen nicht erforderlich wären.