Fragt man einen erfahrenen Ingenieur, was er von cert-manager hält und warum alle ihn nutzen, wird er tief durchatmen, vertraulich lächeln und müde sagen: „Alle nutzen ihn, weil es keine vernünftigen Alternativen gibt. Unsere Mäuse weinen, schmerzen, leben aber weiterhin mit diesem Kaktus. Warum mögen wir ihn? Weil er funktioniert. Warum mögen wir ihn nicht? Weil ständig neue Versionen herauskommen, die neue Funktionen nutzen. Und wir müssen das Cluster immer wieder aktualisieren. Alte Versionen hören auf zu funktionieren, denn es gibt eine Verschwörung und große geheimnisvolle Schamanenkünste.“
Aber die Entwickler versichern, dass mit cert-manager 1.0 alles anders wird.
Wollen wir daran glauben?
Cert-manager ist der „eigenständige“ Controller zur Verwaltung von Zertifikaten in Kubernetes. Mit ihm können Zertifikate aus verschiedenen Quellen ausgestellt werden: Let’s Encrypt, HashiCorp Vault, Venafi, sowie signierte Schlüsselpaare und selbstsignierte Zertifikate. Er sorgt zudem dafür, dass die Schlüssel aktuell bleiben und versucht, die Zertifikate automatisch vor Ablauf zu erneuern. Cert-manager basiert auf kube-lego und hat einige Techniken aus anderen ähnlichen Projekten wie kube-cert-manager übernommen.
Hinweise zur Veröffentlichung
Mit der Version 1.0 setzen wir ein Zeichen des Vertrauens für drei Jahre Entwicklungsarbeit am Projekt cert-manager. In dieser Zeit hat es sich erheblich in Bezug auf Funktionalität und Stabilität weiterentwickelt, aber am meisten durch die Community. Heute sehen wir, dass viele Menschen ihn zur Sicherung ihrer Kubernetes-Cluster nutzen und ihn auch in verschiedenen Teilen des Ökosystems implementieren. In den letzten 16 Versionen wurden viele Fehler behoben. Was kaputtgemacht werden musste, wurde auch kaputtgemacht. Mehrere Ansätze zur API-Integration haben die Benutzerinteraktion verbessert. Wir haben 1500 Probleme auf GitHub gelöst, mit noch mehr Pull-Requests von 253 Community-Mitgliedern.
Mit der Veröffentlichung von 1.0 erklären wir offiziell, dass cert-manager ein ausgereiftes Projekt ist. Wir versprechen auch, die Kompatibilität unserer API zu unterstützen. v1.
Ein riesiges Dankeschön an alle, die uns in diesen drei Jahren geholfen haben, cert-manager zu dem zu machen, was es ist! Möge Version 1.0 der erste Schritt zu vielen weiteren großen Erfolgen sein.
Die Version 1.0 ist eine stabile Veröffentlichung mit mehreren priorisierten Bereichen:
v1API;Der Befehl
kubectl cert-manager status, zur Unterstützung bei der Problemanalyse;Verwendung der neuesten stabilen Kubernetes-APIs;
Verbessertes Logging;
Verbesserungen bei ACME.
Bitte lesen Sie vor dem Update die Update-Hinweise.
API v1
Die Version v0.16 arbeitete mit dem API v1beta1. Diese brachte einige strukturelle Änderungen und verbesserte die Dokumentation der API-Felder. Die Version 1.0 basiert vollständig auf diesem API v1. Dieses API ist unser erstes stabiles, während wir bereits Kompatibilitätsgarantien gegeben haben, aber mit dem API v1 versprechen wir, die Kompatibilität für Jahre aufrechtzuerhalten.
Die vorgenommenen Änderungen (Hinweis: Unsere Konvertierungsmittel werden sich um alles für Sie kümmern):
Zertifikat:
emailSANsheißt jetztemailAddressesuriSANs—uris
Diese Änderungen fügen die Kompatibilität mit anderen SAN (Subject Alt Names, Anm. der Übersetzer), sowie mit dem Go API hinzu. Wir entfernen diesen Begriff aus unserem API.
Aktualisierung
Wenn Sie Kubernetes 1.16+ verwenden, werden konvertierende Webhooks es Ihnen ermöglichen, gleichzeitig und nahtlos mit den API-Versionen v1alpha2, v1alpha3, v1beta1 und v1. Damit können Sie die neue API-Version nutzen, ohne Ihre alten Ressourcen zu ändern oder neu bereitzustellen. Wir empfehlen dringend, die Manifestdateien auf das API v1zu aktualisieren, da die vorherigen Versionen bald als veraltet erklärt werden. Benutzer legacy der Version cert-manager haben weiterhin nur Zugang zu v1, die Schritte zur Aktualisierung finden Sie .
Befehl kubectl cert-manager status
Mit den neuen Verbesserungen in unserer Erweiterung wird es einfacher, Probleme im Zusammenhang mit der Zertifikatsausstellung zu untersuchen. kubectl der jetzt deutlich mehr Informationen darüber bereitstellt, was mit den Zertifikaten passiert, und auch den Ausstellungsprozess des Zertifikats anzeigt. kubectl cert-manager status Nach der Installation der Erweiterung können Sie
kubectl cert-manager status certificate , was dazu führt, dass das Zertifikat mit dem angegebenen Namen und allen zugehörigen Ressourcen wie CertificateRequest, Secret, Issuer sowie Order und Challenges im Falle der Verwendung von ACME-Zertifikaten gesucht wird.Beispiel zur Fehlersuche eines noch nicht ausgestellten Zertifikats:
Ein Beispiel für die Fehlersuche eines noch nicht bereitgestellten Zertifikats:
$ kubectl cert-manager status certificate acme-certificate
Name: acme-certificate
Namespace: default
Erstellt am: 2020-08-21T16:44:13+02:00
Bedingungen:
Bereit: Falsch, Grund: ExistiertNicht, Nachricht: Zertifikat kann nicht ausgestellt werden, da das Secret nicht existiert
Ausstellend: Wahr, Grund: ExistiertNicht, Nachricht: Zertifikat kann nicht ausgestellt werden, da das Secret nicht existiert
DNS-Namen:
- example.com
Ereignisse:
Typ Grund Alter Von Nachricht
---- ------ ---- ---- -------
Normal Ausstellend 18m cert-manager Zertifikat kann nicht ausgestellt werden, da das Secret nicht existiert
Normal Generiert 18m cert-manager Neues privates Schlüssel wurde in temporärem Secret-Ressource "acme-certificate-tr8b2" gespeichert
Normal Angefordert 18m cert-manager Neue CertificateRequest-Ressource "acme-certificate-qp5dm" erstellt
Aussteller:
Name: acme-issuer
Art: Aussteller
Bedingungen:
Bereit: Wahr, Grund: ACMEAccountRegistriert, Nachricht: Das ACME-Konto wurde beim ACME-Server registriert
Fehler beim Finden des Secrets "acme-tls": secrets "acme-tls" nicht gefunden
Nicht vor:
Nicht nach:
Erneuerungszeit:
CertificateRequest:
Name: acme-certificate-qp5dm
Namespace: default
Bedingungen:
Bereit: Falsch, Grund: Ausstehend, Nachricht: Warte auf Zertifikatsausstellung von Bestellung default/acme-certificate-qp5dm-1319513028: "ausstehend"
Ereignisse:
Typ Grund Alter Von Nachricht
---- ------ ---- ---- -------
Normal BestellungErstellt 18m cert-manager Bestellung Ressource default/acme-certificate-qp5dm-1319513028 erstellt
Bestellung:
Name: acme-certificate-qp5dm-1319513028
Zustand: ausstehend, Grund:
Genehmigungen:
URL: https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/97777571, Identifier: example.com, Anfangszustand: ausstehend, Wildcard: falsch
Herausforderungen:
- Name: acme-certificate-qp5dm-1319513028-1825664779, Typ: DNS-01, Token: J-lOZ39yNDQLZTtP_ZyrYojDqjutMAJOxCL1AkOEZWw, Schlüssel: U_W3gGV2KWgIUonlO2me3rvvEOTrfTb-L5s0V1TJMCw, Zustand: ausstehend, Grund: Fehler beim Abrufen des Clouddns-Dienstkonto: secret "clouddns-accoun" nicht gefunden, Verarbeitung: wahr, Präsentiert: falsch
Das Team kann Ihnen auch helfen, mehr über den Inhalt des Zertifikats zu erfahren. Beispiel für die Details eines Zertifikats, das von Letsencrypt ausgestellt wurde:
$ kubectl cert-manager status certificate example
Name: example
[...]
Secret:
Name: example
Issuer Country: US
Issuer Organisation: Let's Encrypt
Issuer Common Name: Let's Encrypt Authority X3
Key Usage: Digitale Signatur, Schlüsselverschlüsselung
Extended Key Usages: Serverauthentifizierung, Clientauthentifizierung
Public Key Algorithm: RSA
Signature Algorithm: SHA256-RSA
Subject Key ID: 65081d98a9870764590829b88c53240571997862
Authority Key ID: a84a6a63047dddbae6d139b7a64565eff3a8eca1
Serial Number: 0462ffaa887ea17797e0057ca81d7ba2a6fb
Events:
Not Before: 2020-06-02T04:29:56+02:00
Not After: 2020-08-31T04:29:56+02:00
Renewal Time: 2020-08-01T04:29:56+02:00
[...]
Verwendung der neuesten stabilen Kubernetes APIs
Cert-manager war einer der ersten, die Kubernetes CRDs implementiert haben. Dies sowie unsere Unterstützung für Kubernetes-Versionen bis 1.11 haben dazu geführt, dass wir veraltete apiextensions.k8s.io/v1beta1 für unsere CRDs sowie admissionregistration.k8s.io/v1beta1 für unsere Webhooks unterstützen mussten. Diese sind jetzt veraltet und werden in Kubernetes mit Version 1.22 entfernt. Mit unserer 1.0 bieten wir jetzt volle Unterstützung apiextensions.k8s.io/v1 und admissionregistration.k8s.io/v1 für Kubernetes 1.16 (wo sie hinzugefügt wurden) und neuer. Für Nutzer älterer Versionen bieten wir weiterhin Unterstützung v1beta1 in unserer legacy Version.
Verbessertes Logging
In dieser Version haben wir die Logging-Bibliothek auf klog/v2, die in Kubernetes 1.19 verwendet wird, aktualisiert. Zudem überprüfen wir jedes Log, das wir schreiben, um ihm das passende Level zuzuweisen. Dabei haben wir uns an orientiert. Es gibt fünf (in Wirklichkeit sechs, Anm. der Übersetzer) Logging-Stufen, beginnend mit Fehler (Stufe 0), die nur wichtige Fehler ausgibt, bis hin zu Trace (Stufe 5), die genau aufzeigt, was passiert. Mit dieser Änderung haben wir die Menge an Logs reduziert, wenn Sie keine Debug-Informationen beim Arbeiten mit cert-manager benötigen.
Hinweis: standardmäßig arbeitet cert-manager auf Stufe 2 (Info), Sie können dies über global.logLevel im Helm Chart überschreiben.
Anmerkung: Das Durchsehen von Logs ist das letzte Mittel zur Fehlersuche. Für weiterführende Informationen lesen Sie bitte unser .
N.B. Redaktion: Um mehr darüber zu erfahren, wie das Ganze im Hintergrund bei Kubernetes funktioniert, wertvolle Tipps von Praktikern zu erhalten und zudem qualitativ hochwertige Unterstützung vom technischen Support zu bekommen, können Sie an den Online-Intensiven teilnehmen , die vom 28. bis 30. September stattfinden, sowie , die vom 14. bis 16. Oktober stattfinden.
Verbesserungen ACME
Die häufigste Verwendung von cert-manager steht wahrscheinlich im Zusammenhang mit der Ausstellung von Zertifikaten von Let’s Encrypt unter Verwendung von ACME. Die Version 1.0 zeichnet sich durch das Feedback der Community aus, das zur Hinzufügung von zwei kleinen, aber wichtigen Verbesserungen in unserem ACME-Aussteller führte.
Deaktivierung der Erstellung des Kontoschlüssels
Wenn Sie ACME-Zertifikate in großem Umfang verwenden, nutzen Sie wahrscheinlich dasselbe Konto in mehreren Clustern, sodass Ihre Zertifikatausstellungslimits für alle gelten. Dies war bereits im cert-manager möglich, indem das angegebene Geheimnis in privateKeySecretRefkopiert wurde. Diese Verwendung war jedoch recht fehleranfällig, da cert-manager versuchte, hilfreich zu sein und fröhlich einen neuen Konto-Schlüssel anlegte, wenn er ihn nicht fand. Deshalb haben wir disableAccountKeyGeneration, hinzugefügt, um Sie vor diesem Verhalten zu schützen, wenn Sie diesen Parameter auf true setzen — cert-manager wird keinen Schlüssel erstellen und Ihnen mitteilen, dass kein Konto-Schlüssel bereitgestellt wurde.
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
name: letsencrypt
spec:
acme:
privateKeySecretRef:
name: example-issuer-account-key
disableAccountKeyGeneration: false
Bevorzugte Kette
29. September Let’s Encrypt zu einem eigenen Root-Zertifizierungszentrum ISRG Root. Zertifikate mit Cross-Signierungen werden ersetzt durch Identrust. Diese Änderung erfordert keine Anpassungen in den Einstellungen des cert-managers; alle aktualisierten oder neuen Zertifikate, die nach diesem Datum ausgestellt werden, nutzen den neuen Root-CA.
Let’s Encrypt signiert bereits Zertifikate mit diesem CA und bietet diese als "alternative Zertifikatskette" über ACME an. In dieser Version des cert-managers gibt es die Möglichkeit, den Zugriff auf diese Ketten in den Einstellungen des Issuers festzulegen. Im Parameter preferredChain kann der Name des verwendeten CA angegeben werden, über den das Zertifikat ausgestellt wird. Wenn ein passendes CA-Zertifikat verfügbar ist, wird Ihnen ein Zertifikat ausgestellt. Bitte beachten Sie, dass dies die bevorzugte Option ist; wenn nichts gefunden wird, wird ein Standardzertifikat ausgestellt. Dies gewährleistet, dass Sie dennoch Ihr Zertifikat aktualisieren, nachdem die alternative Kette auf Seiten des ACME-Issuers entfernt wurde.
Bereits heute können Zertifikate ausgestellt werden, die durch ISRG Root, beispielsweise:
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
name: letsencrypt
spec:
acme:
server: https://acme-v02.api.letsencrypt.org/directory
preferredChain: "ISRG Root X1"
Wenn Sie die Kette lieber beibehalten möchten, IdenTrust — setzen Sie diesen Parameter auf DST Root CA X3:
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
name: letsencrypt
spec:
acme:
server: https://acme-v02.api.letsencrypt.org/directory
preferredChain: "DST Root CA X3"
Bitte beachten Sie, dass diese Zertifizierungsstelle bald veraltet sein wird. Let’s Encrypt wird diese Kette bis zum 29. September 2021 aktiv halten.
Quelle: habr.com
