🥇Cert-manager 1.0 ist da

Fragt man einen erfahrenen, klugen Ingenieur, was er von cert-manager hält und warum ihn jeder nutzt, dann wird der Spezialist seufzen, ihn vertrauensvoll umarmen und müde sagen: „Jeder nutzt es, weil es keine vernünftigen Alternativen gibt.“ Unsere Mäuse weinen, stechen, leben aber weiterhin mit diesem Kaktus. Warum lieben wir? Weil es funktioniert. Warum lieben wir nicht? Denn es kommen ständig neue Versionen heraus, die neue Funktionen nutzen. Und Sie müssen den Cluster immer wieder aktualisieren. Und die alten Versionen funktionieren nicht mehr, weil es eine Verschwörung und einen großen mysteriösen Schamanismus gibt.

Aber das behaupten die Entwickler Zertifikatsmanager 1.0 Alles wird sich verändern.

Glaube es?

Cert-Manager ist der native Kubernetes-Zertifikatverwaltungscontroller. Es kann Zertifikate aus verschiedenen Quellen ausstellen: Let's Encrypt, HashiCorp Vault, Venafi, signierende Schlüsselpaare und selbstsignierte. Außerdem können Sie Schlüssel anhand der Ablaufzeit auf dem neuesten Stand halten und versuchen, Zertifikate zu einem bestimmten Zeitpunkt vor ihrem Ablauf automatisch zu erneuern. Cert-Manager basiert auf Kube-Lego und hat auch einige Tricks aus anderen ähnlichen Projekten wie Kube-Cert-Manager verwendet.

Versionshinweise

Mit der Version 1.0 setzen wir ein Zeichen des Vertrauens für die dreijährige Entwicklung des Cert-Manager-Projekts. In dieser Zeit hat es sich hinsichtlich Funktionalität und Stabilität erheblich weiterentwickelt, vor allem aber in der Community. Heutzutage sehen wir, dass viele Menschen es verwenden, um ihre Kubernetes-Cluster zu sichern und es in verschiedenen Teilen des Ökosystems bereitzustellen. In den letzten 16 Versionen wurden viele Fehler behoben. Und was gebrochen werden musste, ist kaputt. Mehrere Besuche zur Arbeit mit der API haben die Interaktion mit Benutzern verbessert. Wir haben 1500 Probleme auf GitHub mit weiteren Pull-Anfragen von 253 Community-Mitgliedern gelöst.

Mit der Veröffentlichung von 1.0 erklären wir offiziell, dass cert-manager ein ausgereiftes Projekt ist. Wir versprechen außerdem, unsere API kompatibel zu halten v1.

Vielen Dank an alle, die uns in all den drei Jahren dabei geholfen haben, Cert-Manager zu werden! Lassen Sie Version 1.0 die erste von vielen großen Dingen sein, die noch kommen werden.

Release 1.0 ist eine stabile Version mit mehreren Prioritätsbereichen:

v1 FEUER;
Team kubectl cert-manager status, um bei der Problemanalyse zu helfen;
Verwendung der neuesten stabilen Kubernetes-APIs;
Verbesserte Protokollierung;
ACME-Verbesserungen.

Lesen Sie vor dem Upgrade unbedingt die Upgrade-Hinweise.

API v1

Version v0.16 funktionierte mit der API v1beta1. Dadurch wurden einige strukturelle Änderungen vorgenommen und auch die API-Felddokumentation verbessert. Version 1.0 baut darauf mit einer API auf v1. Diese API ist unsere erste stabile, gleichzeitig haben wir bereits Kompatibilitätsgarantien gegeben, allerdings mit der API v1 Wir versprechen, die Kompatibilität auch in den kommenden Jahren aufrechtzuerhalten.

Vorgenommene Änderungen (Hinweis: Unsere Konvertierungstools erledigen alles für Sie):

Zertifikat:

emailSANs jetzt genannt emailAddresses
uriSANs - uris

Diese Änderungen erhöhen die Kompatibilität mit anderen SANs (Subjekt-Alt-Namen, ca. Übersetzer) sowie mit der Go-API. Wir entfernen diesen Begriff aus unserer API.

Aktualisieren

Wenn Sie Kubernetes 1.16+ verwenden, können Sie durch die Konvertierung von Webhooks gleichzeitig und nahtlos mit API-Versionen arbeiten v1alpha2, v1alpha3, v1beta1 и v1. Damit können Sie die neue Version der API nutzen, ohne Ihre alten Ressourcen zu ändern oder neu bereitzustellen. Wir empfehlen dringend, Ihre Manifeste auf die API zu aktualisieren v1, da frühere Versionen bald veraltet sein werden. Benutzer legacy Versionen von Cert-Manager haben weiterhin nur Zugriff auf v1finden Sie Upgrade-Schritte hier.

kubectl cert-manager status-Befehl

Mit neuen Verbesserungen in unserer Erweiterung zu kubectl Es wurde einfacher, die Probleme im Zusammenhang mit der Nichtausstellung von Zertifikaten zu untersuchen. kubectl cert-manager status Bietet jetzt viel mehr Informationen darüber, was mit den Zertifikaten passiert, und zeigt auch die Phase der Zertifikatsausstellung an.

Nach der Installation der Erweiterung können Sie sie ausführen kubectl cert-manager status certificate <имя-сертификата>, das das Zertifikat mit dem angegebenen Namen und allen zugehörigen Ressourcen wie CertificateRequest, Secret, Issuer und Order and Challenges sucht, wenn Zertifikate von ACME verwendet werden.

Ein Beispiel für das Debuggen eines Zertifikats, das noch nicht fertig ist:

$ kubectl cert-manager status certificate acme-certificate

Name: acme-certificate
Namespace: default
Created at: 2020-08-21T16:44:13+02:00
Conditions:
  Ready: False, Reason: DoesNotExist, Message: Issuing certificate as Secret does not exist
  Issuing: True, Reason: DoesNotExist, Message: Issuing certificate as Secret does not exist
DNS Names:
- example.com
Events:
  Type    Reason     Age   From          Message
  ----    ------     ----  ----          -------
  Normal  Issuing    18m   cert-manager  Issuing certificate as Secret does not exist
  Normal  Generated  18m   cert-manager  Stored new private key in temporary Secret resource "acme-certificate-tr8b2"
  Normal  Requested  18m   cert-manager  Created new CertificateRequest resource "acme-certificate-qp5dm"
Issuer:
  Name: acme-issuer
  Kind: Issuer
  Conditions:
    Ready: True, Reason: ACMEAccountRegistered, Message: The ACME account was registered with the ACME server
error when finding Secret "acme-tls": secrets "acme-tls" not found
Not Before: <none>
Not After: <none>
Renewal Time: <none>
CertificateRequest:
  Name: acme-certificate-qp5dm
  Namespace: default
  Conditions:
    Ready: False, Reason: Pending, Message: Waiting on certificate issuance from order default/acme-certificate-qp5dm-1319513028: "pending"
  Events:
    Type    Reason        Age   From          Message
    ----    ------        ----  ----          -------
    Normal  OrderCreated  18m   cert-manager  Created Order resource default/acme-certificate-qp5dm-1319513028
Order:
  Name: acme-certificate-qp5dm-1319513028
  State: pending, Reason:
  Authorizations:
    URL: https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/97777571, Identifier: example.com, Initial State: pending, Wildcard: false
Challenges:
- Name: acme-certificate-qp5dm-1319513028-1825664779, Type: DNS-01, Token: J-lOZ39yNDQLZTtP_ZyrYojDqjutMAJOxCL1AkOEZWw, Key: U_W3gGV2KWgIUonlO2me3rvvEOTrfTb-L5s0V1TJMCw, State: pending, Reason: error getting clouddns service account: secret "clouddns-accoun" not found, Processing: true, Presented: false

Der Befehl kann Ihnen auch dabei helfen, mehr über den Inhalt des Zertifikats zu erfahren. Detailliertes Beispiel für ein von Letsencrypt ausgestelltes Zertifikat:

$ 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: Digital Signature, Key Encipherment
  Extended Key Usages: Server Authentication, Client Authentication
  Public Key Algorithm: RSA
  Signature Algorithm: SHA256-RSA
  Subject Key ID: 65081d98a9870764590829b88c53240571997862
  Authority Key ID: a84a6a63047dddbae6d139b7a64565eff3a8eca1
  Serial Number: 0462ffaa887ea17797e0057ca81d7ba2a6fb
  Events:  <none>
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, der Kubernetes CRDs implementierte. Dies und unsere Unterstützung für Kubernetes-Versionen bis 1.11 bedeuteten, dass wir das Legacy unterstützen mussten apiextensions.k8s.io/v1beta1 auch für unsere CRDs admissionregistration.k8s.io/v1beta1 für unsere Webhooks. Sie sind nun veraltet und werden in Kubernetes ab Version 1.22 entfernt. Mit unserer Version 1.0 bieten wir nun vollen Support apiextensions.k8s.io/v1 и admissionregistration.k8s.io/v1 für Kubernetes 1.16 (wo sie hinzugefügt wurden) und neuer. Für Nutzer früherer Versionen bieten wir weiterhin Support an v1beta1 in unserer legacy Versionen.

Verbesserte Protokollierung

In dieser Version haben wir die Protokollierungsbibliothek auf aktualisiert klog/v2, verwendet in Kubernetes 1.19. Wir überprüfen auch jede von uns verfasste Zeitschrift, um sicherzustellen, dass sie der entsprechenden Stufe zugeordnet ist. Davon haben wir uns leiten lassen Anleitung von Kubernetes. Es gibt fünf (eigentlich sechs, ca. Übersetzer) Protokollierungsstufen ab Error (Stufe 0), die nur wichtige Fehler ausgibt, und endet mit Trace (Stufe 5), die Ihnen hilft, genau zu wissen, was vor sich geht. Mit dieser Änderung haben wir die Anzahl der Protokolle reduziert, wenn Sie beim Ausführen von cert-manager keine Debug-Informationen benötigen.

Tipp: cert-manager läuft standardmäßig auf Level 2 (Info), können Sie dies mit überschreiben global.logLevel in Helmchart.

Hinweis: Das Anzeigen der Protokolle ist der letzte Ausweg bei der Fehlerbehebung. Weitere Informationen finden Sie in unserem Führung.

Anmerkung des Herausgebers:: Um mehr darüber zu erfahren, wie alles unter der Haube von Kubernetes funktioniert, wertvolle Ratschläge von praktizierenden Lehrern sowie hochwertige technische Unterstützung zu erhalten, können Sie an Online-Intensivkursen teilnehmen Kubernetes-Basis, die vom 28. bis 30. September stattfinden wird, und Kubernetes Megadie vom 14. bis 16. Oktober stattfinden wird.

ACME-Verbesserungen

Die häufigste Verwendung von cert-manager hängt wahrscheinlich mit der Ausstellung von Zertifikaten von Let's Encrypt mithilfe von ACME zusammen. Version 1.0 zeichnet sich dadurch aus, dass sie das Feedback der Community nutzt, um zwei kleine, aber wichtige Verbesserungen an unserem ACME-Herausgeber vorzunehmen.

Deaktivieren Sie die Generierung von Kontoschlüsseln

Wenn Sie ACME-Zertifikate in großen Mengen verwenden, verwenden Sie wahrscheinlich dasselbe Konto auf mehreren Clustern, sodass Ihre Zertifikatsausstellungsbeschränkungen für alle Cluster gelten. Dies war im Cert-Manager bereits beim Kopieren des in angegebenen Geheimnisses möglich privateKeySecretRef. Dieser Anwendungsfall war ziemlich fehlerhaft, da der Zertifikatsmanager versuchte, hilfreich zu sein und gerne einen neuen Kontoschlüssel erstellte, wenn er keinen fand. Deshalb haben wir hinzugefügt disableAccountKeyGenerationum Sie vor diesem Verhalten zu schützen, wenn Sie diese Option auf setzen true - Der Zertifikatsmanager generiert keinen Schlüssel und warnt Sie, dass kein Kontoschlü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 wird sich bewegen zu Ihrer eigenen Root-CA ISRG Root. Gegensignierte Zertifikate werden durch ersetzt Identrust. Diese Änderung erfordert keine Änderungen an den Cert-Manager-Einstellungen. Alle aktualisierten oder neuen Zertifikate, die nach diesem Datum ausgestellt werden, verwenden die neue Stammzertifizierungsstelle.

Let's Encrypt signiert bereits Zertifikate mit dieser CA und bietet sie als „alternative Zertifikatskette“ über ACME an. In dieser Version des Cert-Managers ist es möglich, den Zugriff auf diese Ketten in den Ausstellereinstellungen festzulegen. Im Parameter preferredChain Sie können den Namen der verwendeten CA angeben, mit der das Zertifikat ausgestellt wird. Liegt ein zur Anfrage passendes CA-Zertifikat vor, stellt diese Ihnen ein Zertifikat aus. Bitte beachten Sie, dass dies die bevorzugte Option ist. Wenn nichts gefunden wird, wird ein Standardzertifikat ausgestellt. Dadurch wird sichergestellt, dass Sie Ihr Zertifikat auch nach dem Löschen der alternativen Kette auf der Seite des ACME-Ausstellers erneuern.

Bereits heute können Sie von uns unterzeichnete Zertifikate erhalten ISRG Root, So:

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 lieber die Kette verlassen möchten IdenTrust - Setzen Sie diese Option 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 Stammzertifizierungsstelle bald veraltet ist. Let's Encrypt wird diese Kette bis zum 29. September 2021 aktiv halten.

Source: habr.com

Cert-Manager 1.0 veröffentlicht