🥇A apărut cert-manager 1.0

Dacă ai întreba un inginer experimentat și înțelept ce părere are despre cert-manager și de ce toată lumea îl folosește, specialistul ar suspina, te-ar îmbrățișa de încredere și ar spune obosit: „Toată lumea îl folosește pentru că nu există alternative rezonabile. Șoarecii noștri plâng, se înțeapă, dar continuă să trăiască cu acest cactus. De ce îl iubim? Pentru că funcționează. De ce nu îl iubim? Pentru că apar constant noi versiuni care folosesc funcții noi. Și trebuie să actualizăm clusterele din nou și din nou. Iar versiunile vechi încetează să mai funcționeze, pentru că există o conspirație și o mare vrăjitorie misterioasă.”

Dar dezvoltatorii asigură că odată cu cert-manager 1.0 totul se va schimba.

Să credem?

Cert-manager este un controler nativ de gestionare a certificatelor Kubernetes. Cu ajutorul său, poți emite certificate din diverse surse: Let’s Encrypt, HashiCorp Vault, Venafi, perechi de chei pentru semnare și certificate auto-semante. De asemenea, permite menținerea cheilor actualizate în funcție de perioada de valabilitate, precum și încearcă să actualizeze automat certificatele într-un timp stabilit înainte de expirare. Cert-manager se bazează pe kube-lego și a folosit, de asemenea, unele tehnici din alte proiecte similare, cum ar fi kube-cert-manager.

Note de lansare

Cu versiunea 1.0, punem un semn de încredere după trei ani de dezvoltare a proiectului cert-manager. În această perioadă, acesta a evoluat semnificativ în ceea ce privește funcționalitatea și stabilitatea, dar cel mai mult - în comunitate. Astăzi vedem cum mulți oameni îl folosesc pentru a-și proteja clusterele Kubernetes și efectuează implementări în diverse părți ale ecosistemului. În ultimele 16 lansări au fost remediate o mulțime de erori. Iar ceea ce trebuia să fie stricat - a fost stricat. Câteva încercări de lucru cu API-ul au îmbunătățit interacțiunea acestuia cu utilizatorii. Am rezolvat 1500 de probleme pe GitHub, cu un număr și mai mare de cereri de fuziune de la 253 de membri ai comunității.

Prin lansarea 1.0, declarăm oficial că cert-manager este un proiect matur. Promitem, de asemenea, să menținem compatibilitatea API-ului nostru. v1.

Mii de mulțumiri tuturor celor care ne-au ajutat să facem cert-manager în acești trei ani! Să fie versiunea 1.0 prima din numeroasele mari realizări viitoare.

Lansarea 1.0 este o lansare stabilă cu câteva direcții prioritare:

v1 API;
Comanda kubectl cert-manager status, pentru a ajuta la analiza problemelor;
Utilizarea celor mai recente API-uri stabile Kubernetes;
Jurnalizare îmbunătățită;
Îmbunătățiri ACME.

Înainte de actualizare, citiți cu atenție notele de actualizare.

API v1

Versiunea v0.16 a funcționat cu API v1beta1. Acesta a adăugat anumite modificări structurale, precum și îmbunătățiri ale documentației pentru câmpurile API. Versiunea 1.0 se bazează pe toate acestea prin intermediul API v1. Acest API este prima noastră versiune stabilă, în timp ce am oferit deja garanții de compatibilitate, dar cu API v1 promitem să menținem compatibilitatea pentru anii următori.

Modificările aduse (mențiune: instrumentele noastre de conversie se vor ocupa de tot pentru dvs.):

Certificat:

emailSANs acum se numește emailAddresses
uriSANs — uris

Aceste modificări adaugă compatibilitate cu alte SAN (subject alt names, nota traducătorului), precum și cu Go API. Eliminăm acest termen din API-ul nostru.

Actualizare

Dacă utilizați Kubernetes 1.16+ — webhooks-urile de conversie vă vor permite să lucrați simultan și fără probleme cu versiunile API v1alpha2, v1alpha3, v1beta1 și v1. Cu ajutorul lor, veți putea utiliza noua versiune API fără a modifica sau a redezvolta resursele dvs. vechi. Recomandăm cu insistență să actualizați manifestele la API v1, deoarece versiunile anterioare vor fi declarate în curând ca învechite. Utilizatorii legacy versiunii cert-manager vor avea în continuare acces doar la v1, pașii pentru actualizare pot fi găsiți aici.

Echipa kubectl cert-manager status

Cu noile îmbunătățiri din extensia noastră la kubectl a devenit mai simplu să explorați problemele legate de emiterea certificatelor. kubectl cert-manager status acum oferă mult mai multe informații despre ce se întâmplă cu certificatele și arată, de asemenea, etapa de emitere a certificatului.

După instalarea extensiei, puteți rula kubectl cert-manager status certificate, ceea ce va căuta certificatul cu numele specificat și orice resurse asociate, cum ar fi CertificateRequest, Secret, Issuer, precum și Order și Challenges în cazul utilizării certificatelor de la ACME.

Exemplu de depanare a unui certificat care nu este încă gata:

$ kubectl cert-manager status certificate acme-certificate

Nume: acme-certificate
Spațiu de nume: default
Creat la: 2020-08-21T16:44:13+02:00
Condiții:
  Gata: False, Motiv: DoesNotExist, Mesaj: Certificatul se emite deoarece Secretul nu există
  Emitere: True, Motiv: DoesNotExist, Mesaj: Certificatul se emite deoarece Secretul nu există
Nume DNS:
- example.com
Evenimente:
  Tip    Motiv     Vârstă   Din          Mesaj
  ----    ------     ----  ----          -------
  Normal  Emitere    18m   cert-manager  Certificatul se emite deoarece Secretul nu există
  Normal  Generat  18m   cert-manager  Cheia privată nouă a fost stocată în resursa Secret provizorie "acme-certificate-tr8b2"
  Normal  Cerut  18m   cert-manager  A creat noua resursă CertificateRequest "acme-certificate-qp5dm"
Emitent:
  Nume: acme-issuer
  Tip: Emitent
  Condiții:
    Gata: True, Motiv: ACMEAccountRegistered, Mesaj: Contul ACME a fost înregistrat cu serverul ACME
eroare la găsirea Secretului "acme-tls": secrets "acme-tls" nu a fost găsit
Nu înainte: 
Nu după: 
Timp de reînnoire: 
CertificateRequest:
  Nume: acme-certificate-qp5dm
  Spațiu de nume: default
  Condiții:
    Gata: False, Motiv: Pendinte, Mesaj: Așteptând emiterea certificatului din comanda default/acme-certificate-qp5dm-1319513028: "pendinte"
  Evenimente:
    Tip    Motiv        Vârstă   Din          Mesaj
    ----    ------        ----  ----          -------
    Normal  ComandăCreată  18m   cert-manager  A creat resursa Comandă default/acme-certificate-qp5dm-1319513028
Comandă:
  Nume: acme-certificate-qp5dm-1319513028
  Stare: pendinte, Motiv:
  Autorizări:
    URL: https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/97777571, Identificator: example.com, Stare inițială: pendinte, Wildcard: false
Challanges:
- Nume: acme-certificate-qp5dm-1319513028-1825664779, Tip: DNS-01, Token: J-lOZ39yNDQLZTtP_ZyrYojDqjutMAJOxCL1AkOEZWw, Cheie: U_W3gGV2KWgIUonlO2me3rvvEOTrfTb-L5s0V1TJMCw, Stare: pendinte, Motiv: eroare la obținerea contului de serviciu clouddns: secret "clouddns-accoun" nu a fost găsit, Procesare: true, Prezentat: false

Comanda poate ajuta de asemenea să afle mai multe despre conținutul certificatului. Exemplu de detaliere pentru un certificat emis de Letsencrypt:

$ kubectl cert-manager status certificate example
Nume: example
[...]
Secret:
  Nume: example
  Țara emitentului: SUA
  Organizația emitentului: Let's Encrypt
  Numele comun al emitentului: Let's Encrypt Authority X3
  Utilizarea cheii: Semnătură digitală, Criptare cheie
  Utilizările cheii extinse: Autentificare server, Autentificare client
  Algoritmul cheii publice: RSA
  Algoritmul semnăturii: SHA256-RSA
  ID-ul cheii subiectului: 65081d98a9870764590829b88c53240571997862
  ID-ul cheii autorității: a84a6a63047dddbae6d139b7a64565eff3a8eca1
  Numărul de serie: 0462ffaa887ea17797e0057ca81d7ba2a6fb
  Evenimente:  
Nu înainte: 2020-06-02T04:29:56+02:00
Nu după: 2020-08-31T04:29:56+02:00
Timp de reînnoire: 2020-08-01T04:29:56+02:00
[...]

Utilizarea celor mai recente API stabile Kubernetes

Cert-manager a fost unul dintre primele care au implementat CRD-uri Kubernetes. Acest lucru, precum și suportul nostru pentru versiunile Kubernetes până la 1.11, au determinat nevoia de a menține versiuni învechite apiextensions.k8s.io/v1beta1 pentru CRD-urile noastre, precum și admissionregistration.k8s.io/v1beta1 pentru webhooks-urile noastre. Acum acestea sunt învechite și vor fi eliminate în Kubernetes începând cu versiunea 1.22. Cu versiunea 1.0, oferim acum suport complet apiextensions.k8s.io/v1 și admissionregistration.k8s.io/v1 pentru Kubernetes 1.16 (unde au fost adăugate) și mai recent. Pentru utilizatorii versiunilor anterioare, continuăm să oferim suport v1beta1 în versiunea noastră, legacy disponibilă.

Îmbunătățirea jurnalizării

În această versiune, am actualizat biblioteca de jurnalizare la klog/v2, folosită în Kubernetes 1.19. De asemenea, verificăm fiecare jurnal pe care îl scriem pentru a-i atribui un nivel corespunzător. Ne-am bazat pe ghidul Kubernetes. Există cinci (de fapt — șase, nota traducătorului) niveluri de jurnalizare, începând cu Error (nivelul 0), care afișează doar erorile importante, și terminând cu Trace (nivelul 5), care ajută la înțelegerea exactă a ceea ce se întâmplă. Cu această modificare, am redus numărul de jurnale, dacă nu aveți nevoie de informații de depanare atunci când lucrați cu cert-manager.

Sfaturi: implicit, cert-manager funcționează pe nivelul 2 (Info), puteți să-l suprascrieți folosind global.logLevel în Helm chart.

Notă: vizionarea jurnalelor este ultima soluție în cazul problemelor. Pentru informații suplimentare, consultați ghid.

N.B. editorul: Pentru a înțelege mai bine cum funcționează totul sub capota Kubernetes, a obține sfaturi valoroase de la practicieni-instructori și asistență tehnică de calitate, puteți lua parte la intensivul online Kubernetes Baza, care va avea loc în perioada 28-30 septembrie, și Kubernetes Mega, care va avea loc în perioada 14–16 octombrie.

Îmbunătățiri ACME

Cea mai frecventă utilizare a cert-manager este asociată cu emiterea certificatelor de la Let’s Encrypt utilizând ACME. Versiunea 1.0 se remarcă prin utilizarea feedback-ului din comunitate pentru a adăuga două îmbunătățiri mici, dar importante la emitentul nostru ACME.

Dezactivarea generării cheii contului

Dacă utilizați certificatul ACME în cantități mari, este probabil să utilizați același cont pe mai multe clustere, astfel încât limitele dvs. pentru emiterea certificatelor să se aplice tuturor acestora. Aceasta era deja posibilă în cert-manager prin copierea secretului specificat în privateKeySecretRef. Acest mod de utilizare era destul de problematic, deoarece cert-manager încerca să fie util și crea un nou cont de utilizator dacă nu îl găsea. De aceea am adăugat disableAccountKeyGeneration, pentru a vă proteja de astfel de comportamente; dacă setați acest parametru la true , cert-manager nu va crea o cheie și vă va avertiza că nu a fost furnizată o cheie de cont.

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: letsencrypt
spec:
  acme:
    privateKeySecretRef:
      name: example-issuer-account-key
    disableAccountKeyGeneration: false

Cadrul preferat

29 septembrie Let’s Encrypt va trece la un centru de certificare rădăcină propriu ISRG Root. Certificatele cu semnături încrucișate vor fi înlocuite cu Identrust. Această modificare nu necesită ajustări în setările cert-manager, toate certificatele actualizate sau noi emise după această dată vor folosi noul CA rădăcină.

Let’s Encrypt deja semnează certificate folosind acest CA și le oferă ca „lanțuri alternative de certificate” prin ACME. În această versiune a cert-manager există opțiunea de a specifica accesul la aceste lanțuri în setările issuer. În parametrul preferredChain puteți specifica numele CA utilizat în emiterea certificatului. Dacă un certificat CA corespunzător cererii este disponibil, acesta va emite certificat. Rețineți că aceasta este opțiunea preferată; dacă nu se găsește nimic, va fi emis un certificat implicit. Acest lucru va garanta că veți actualiza oricum certificatul după eliminarea lanțului alternativ de către issuerul ACME.

Deja astăzi se pot obține certificate semnate ISRG Root, astfel:

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: letsencrypt
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    preferredChain: "ISRG Root X1"

Dacă preferați să păstrați lanțul IdenTrust – setați acest parametru la 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"

Rețineți că acest centru de certificare rădăcină va fi în curând obsolet, Let’s Encrypt va menține acest lanț activ până la 29 septembrie 2021.

Sursa: habr.com