Fragt man einen erfahrenen, weitsichtigen Ingenieur, was er über cert-manager denkt und warum ihn alle nutzen, wird der Spezialist tief durchatmen, vertraulich umarmen und müde sagen: „Alle nutzen ihn, weil es keine vernünftige Alternative gibt. Unsere Mäuse weinen, stechen sich, leben aber weiterhin mit diesem Kaktus. Warum lieben wir ihn? Weil er funktioniert. Warum mögen wir ihn nicht? Weil ständig neue Versionen erscheinen, die neue Funktionen nutzen. Und wir müssen den Cluster immer wieder aktualisieren. Alte Versionen hören auf zu funktionieren, weil es eine Verschwörung gibt und großes mysteriöses Schamanentum.“
Doch die Entwickler versichern, dass mit cert-manager 1.0 alles anders wird.
Wollen wir das glauben?
Cert-manager ist der „native“ Controller für die Verwaltung von Kubernetes-Zertifikaten. Damit können Zertifikate aus verschiedenen Quellen ausgestellt werden: Let’s Encrypt, HashiCorp Vault, Venafi, Schlüsselpaaren für Signaturen und selbstsignierten. Er ermöglicht es auch, die Schlüssel während ihrer Gültigkeitsdauer aktuell zu halten und versucht, die Zertifikate rechtzeitig vor Ablauf automatisch zu erneuern. Cert-manager basiert auf kube-lego und hat auch einige Techniken aus anderen ähnlichen Projekten, wie kube-cert-manager, verwendet.
Hinweise zur Veröffentlichung
Mit Version 1.0 setzen wir ein Zeichen des Vertrauens für drei Jahre Entwicklung des Projekts cert-manager. In dieser Zeit hat er sich in Bezug auf Funktionalität und Stabilität erheblich weiterentwickelt, am meisten jedoch in Bezug auf die Gemeinschaft. Heute sehen wir, wie viele Menschen ihn zum Schutz ihrer Kubernetes-Cluster verwenden und ihn in verschiedene Teile des Ökosystems integrieren. In den letzten 16 Veröffentlichungen wurden viele Fehler behoben. Was kaputtgehen musste, wurde kaputtgemacht. Mehrere Versuche zur Arbeit mit der API haben ihre Interaktion mit den Benutzern verbessert. Wir haben 1500 Probleme auf GitHub mit noch mehr Pull-Requests von 253 Mitgliedern der Gemeinschaft gelöst.
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 großer Dank an alle, die uns in diesen drei Jahren geholfen haben, cert-manager zu entwickeln! Möge Version 1.0 der Beginn vieler künftiger großer Errungenschaften sein.
Die Veröffentlichung 1.0 ist eine stabile Veröffentlichung mit mehrere priorisierten Bereichen:
v1API;Team
kubectl cert-manager status, zur Unterstützung bei der Problemanalyse;Nutzung der neuesten stabilen Kubernetes-APIs;
Verbessertes Logging;
Verbesserungen bei ACME.
Bitte lesen Sie vor dem Update die Aktualisierungsnotizen.
API v1
Version v0.16 funktionierte mit API v1beta1. Dies brachte einige strukturelle Änderungen mit sich und verbesserte die Dokumentation der API-Felder. Die Version 1.0 basiert darauf mit Hilfe der API v1. Diese API ist unsere erste stabile, gleichzeitig hatten wir bereits Kompatibilität zugesichert, aber mit der API v1 versprechen wir, die Kompatibilität für Jahre aufrechtzuerhalten.
Die vorgenommenen Änderungen (Hinweis: Unsere Konvertierungswerkzeuge kümmern sich um alles für Sie):
Zertifikat:
emailSANsheißt jetztemailAddressesuriSANs—uris
Diese Änderungen schaffen Kompatibilität mit anderen SAN (subject alt names, Anm. des Übersetzers), sowie mit der Go API. Wir entfernen diesen Begriff aus unserer API.
Aktualisierung
Wenn Sie Kubernetes 1.16+ verwenden – die konvertierenden Webhooks ermöglichen es Ihnen, gleichzeitig 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 Manifeste auf API v1zu aktualisieren, da die vorherigen Versionen bald als veraltet gekennzeichnet werden. Benutzer legacy der cert-manager-Version haben weiterhin nur Zugang zu v1, die Schritte zur Aktualisierung finden Sie .
Team kubectl cert-manager status
Mit den neuen Verbesserungen in unserer Erweiterung für kubectl ist es einfacher geworden, Probleme im Zusammenhang mit der Ausstellung von Zertifikaten zu untersuchen. kubectl cert-manager status gibt jetzt viel mehr Informationen darüber, was mit den Zertifikaten passiert, und zeigt auch den Ausstellungsprozess des Zertifikats an.
Nach der Installation der Erweiterung können Sie kubectl cert-manager status certificate, was die Suche nach dem Zertifikat mit dem angegebenen Namen sowie allen zugehörigen Ressourcen wie CertificateRequest, Secret, Issuer sowie Order und Challenges im Fall der Nutzung von Zertifikaten von ACME zur Folge hat.
Beispiel zum Debuggen 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: False, Grund: ExistsNicht, Nachricht: Zertifikat ausstellen, da das Secret nicht existiert
Ausgestellt: True, Grund: ExistsNicht, Nachricht: Zertifikat ausstellen, da das Secret nicht existiert
DNS Namen:
- example.com
Ereignisse:
Typ Grund Alter Von Nachricht
---- ------ ---- ---- -------
Normal Ausstellend 18m cert-manager Zertifikat wird ausgestellt, da das Secret nicht existiert
Normal Generiert 18m cert-manager Neue private Schlüssel im temporären Secret-Ressource "acme-certificate-tr8b2" gespeichert
Normal Angefordert 18m cert-manager Neu CertificateRequest-Ressource "acme-certificate-qp5dm" erstellt
Aussteller:
Name: acme-issuer
Typ: Aussteller
Bedingungen:
Bereit: True, Grund: ACMEAccountRegistered, 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: False, Grund: Ausstehend, Nachricht: Warten auf die Ausstellung des Zertifikats aus der Bestellung default/acme-certificate-qp5dm-1319513028: "pending"
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, Identifikator: example.com, Anfangszustand: ausstehend, Wildcard: false
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-Dienstkontos: Secret "clouddns-accoun" nicht gefunden, Verarbeitung: true, Präsentiert: false
Der Befehl kann auch dazu beitragen, mehr über den Inhalt des Zertifikats zu erfahren. Beispiel für Details zu einem von Letsencrypt ausgestellten Zertifikat:
$ kubectl cert-manager status certificate example
Name: example
[...]
Secret:
Name: example
Aussteller Land: US
Aussteller Organisation: Let's Encrypt
Aussteller Allgemeiner Name: Let's Encrypt Authority X3
Schlüsselverwendung: Digitale Signatur, Schlüsselverschlüsselung
Erweiterte Schlüsselverwendungen: Serverauthentifizierung, Clientauthentifizierung
Öffentlicher Schlüsselalgorithmus: RSA
Signaturalgorithmus: SHA256-RSA
Subject Key ID: 65081d98a9870764590829b88c53240571997862
Authority Key ID: a84a6a63047dddbae6d139b7a64565eff3a8eca1
Seriennummer: 0462ffaa887ea17797e0057ca81d7ba2a6fb
Ereignisse:
Nicht vor: 2020-06-02T04:29:56+02:00
Nicht nach: 2020-08-31T04:29:56+02:00
Erneuerungszeit: 2020-08-01T04:29:56+02:00
[...]
Verwendung der neuesten stabilen Kubernetes APIs
Cert-manager war einer der ersten, der Kubernetes CRDs implementierte. Dies sowie unsere Unterstützung für Kubernetes-Versionen bis 1.11 führten dazu, dass wir veraltete apiextensions.k8s.io/v1beta1 für unsere CRDs sowie admissionregistration.k8s.io/v1beta1 für unsere Webhooks. Diese sind jetzt veraltet und werden in Kubernetes seit Version 1.22 entfernt. Mit unserer 1.0 bieten wir nun vollständige 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 Benutzer früherer Versionen bieten wir weiterhin Unterstützung an. 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. Außerdem überprüfen wir jedes Log, das wir schreiben, um ihm die entsprechende Stufe zuzuweisen. Dabei haben wir uns an orientiert. Es gibt fünf (in Wirklichkeit sechs, Anm. des Übersetzers) Logging-Stufen, beginnend mit Fehler (Stufe 0), die nur wichtige Fehler ausgibt, und endend mit Trace (Stufe 5), die hilft, genau zu erkennen, was passiert. Mit dieser Änderung haben wir die Anzahl der Logs reduziert, falls Sie keine Debugging-Informationen beim Arbeiten mit cert-manager benötigen.
Hinweis: Standardmäßig arbeitet cert-manager auf Stufe 2 (Info), Sie können dies überschreiben, indem Sie global.logLevel im Helm-Chart angeben.
Hinweis: Logs anzusehen, ist das letzte Mittel bei der Fehlersuche. Für weitere Informationen lesen Sie bitte unser .
N.B. vom Herausgeber: Um mehr über die Funktionsweise von Kubernetes zu erfahren, wertvolle Tipps von erfahrenen Praktikern zu erhalten sowie qualifizierte Unterstützung durch den technischen Support zu bekommen, können Sie an den Online-Intensivkursen teilnehmen , die vom 28. bis 30. September stattfinden, und , die vom 14. bis 16. Oktober stattfinden.
Verbesserungen von ACME
Die häufigste Anwendung von cert-manager hängt wahrscheinlich mit der Ausstellung von Zertifikaten von Let’s Encrypt unter Verwendung von ACME zusammen. Version 1.0 zeichnet sich durch die Verwendung von Rückmeldungen aus der Community aus, um zwei kleine, aber wichtige Verbesserungen in unserem ACME-Issuer hinzuzufügen.
Deaktivierung der Erstellung von Kontoschlüsseln
Wenn Sie ACME-Zertifikate in großem Umfang verwenden, verwenden Sie wahrscheinlich dasselbe Konto auf mehreren Clustern, sodass Ihre Zertifikatsausstellungslimits für alle gelten. Dies war bereits möglich in cert-manager, indem das in privateKeySecretRefangegebene Secret kopiert wurde. Diese Verwendung war jedoch ziemlich fehlerhaft, da cert-manager versuchte, hilfreich zu sein und fröhlich einen neuen Kontoschlüssel erstellte, wenn er keinen fand. Daher haben wir disableAccountKeyGenerationhinzugefügt, um Sie vor solchem Verhalten zu schützen, wenn Sie diesen Parameter auf true setzen — cert-manager wird keinen Schlüssel erstellen und Sie darauf hinweisen, dass Ihnen kein Kontoschlüssel zur Verfügung gestellt 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 seinem eigenen Root-Zertifizierungszentrum ISRG Root. Zertifikate mit Kreuzsignaturen werden durch Identrust. Diese Änderung erfordert keine Anpassungen in den Einstellungen des cert-managers. Alle aktualisierten oder neuen Zertifikate, die nach diesem Datum ausgestellt werden, verwenden das neue Root-CA.
Let’s Encrypt signiert bereits Zertifikate mit diesem CA und bietet sie als „alternative Zertifikatskette“ über ACME an. In dieser Version des cert-managers besteht 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 CA-Zertifikat verfügbar ist, das der Anfrage entspricht, wird Ihnen das Zertifikat ausgestellt. Beachten Sie, dass dies die bevorzugte Option ist; wenn nichts gefunden wird, wird ein Standardzertifikat ausgestellt. Dies garantiert, dass Sie Ihr Zertifikat dennoch nach der Entfernung der alternativen Kette auf der Seite des ACME-Issuers aktualisieren.
Bereits heute können Zertifikate, die signiert sind von ISRG Root, so bezogen werden:
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 es vorziehen, die Kette IdenTrust zu verwenden, stellen 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 dieses Root-Zertifizierungszentrum bald veraltet sein wird. Let’s Encrypt wird diese Kette bis zum 29. September 2021 aktiv halten.
Quelle: habr.com
