Dacă întrebi un inginer cu experiență, înțelept ce părere are despre cert-manager și de ce îl folosește toată lumea, specialistul va ofta, îl va îmbrățișa confidențial și va spune obosit: „Toată lumea îl folosește, pentru că nu există alternative sănătoase. Șoarecii noștri plâng, se înțeapă, dar continuă să trăiască cu acest cactus. De ce iubim? Pentru că funcționează. De ce nu iubim? Pentru că sunt lansate în mod constant versiuni noi care folosesc funcții noi. Și trebuie să actualizați cluster-ul din nou și din nou. Și versiunile vechi nu mai funcționează, pentru că există o conspirație și un mare șamanism misterios.”
Dar dezvoltatorii susțin că cu cert-manager 1.0 totul se va schimba.
Vom crede?
Cert-manager este un controler nativ de gestionare a certificatelor Kubernetes. Poate fi folosit pentru a emite certificate din diverse surse: Let's Encrypt, HashiCorp Vault, Venafi, semnare și perechi de chei autosemnate. De asemenea, menține cheile la zi și încearcă să reînnoiască automat certificatele la un moment specificat înainte de expirare. Cert-manager se bazează pe kube-lego și a folosit și unele tehnici din alte proiecte similare, cum ar fi kube-cert-manager.
Note de lansare
Cu versiunea 1.0 punem un semn de încredere în cei trei ani de dezvoltare a proiectului cert-manager. În acest timp, s-a dezvoltat semnificativ în funcționalitate și stabilitate, dar mai ales în comunitate. Astăzi vedem mulți oameni care îl folosesc pentru a-și securiza clusterele Kubernetes, precum și pentru a-l implementa în diferite părți ale ecosistemului. O grămadă de erori au fost remediate în ultimele 16 versiuni. Și ceea ce ar fi trebuit să fie rupt a fost rupt. Mai multe vizite la API i-au îmbunătățit interacțiunea cu utilizatorii. Am rezolvat 1500 de probleme pe GitHub, cu și mai multe solicitări de extragere de la 253 de membri ai comunității.
Prin lansarea versiunii 1.0 declarăm oficial că cert-manager este un proiect matur. De asemenea, promitem să ne păstrăm compatibil API-ul v1.
Mulțumim tuturor celor care ne-au ajutat să creăm cert-manager în toți acești trei ani! Lăsați versiunea 1.0 să fie primul dintre multele lucruri grozave care vor veni.
Versiunea 1.0 este o versiune stabilă cu mai multe domenii prioritare:
-
v1API; -
Echipă
kubectl cert-manager status, pentru a ajuta la analiza problemelor; -
Utilizarea celor mai recente API-uri Kubernetes stabile;
-
Înregistrare îmbunătățită;
-
Îmbunătățiri ACME.
Asigurați-vă că citiți notele de actualizare înainte de a face upgrade.
API v1
Versiunea v0.16 a funcționat cu API v1beta1. Acest lucru a adăugat câteva modificări structurale și a îmbunătățit, de asemenea, documentația de câmp API. Versiunea 1.0 se bazează pe toate acestea cu un API v1. Acest API este primul nostru stabil, în același timp am dat deja garanții de compatibilitate, dar cu API-ul v1 Promitem să menținem compatibilitatea pentru anii următori.
Modificări efectuate (notă: instrumentele noastre de conversie se vor ocupa de totul pentru dvs.):
Certificat:
-
emailSANsnumit acumemailAddresses -
uriSANs-uris
Aceste modificări adaugă compatibilitate cu alte SAN-uri (nume alt subiect, aproximativ traducător), precum și cu API-ul Go. Eliminam acest termen din API-ul nostru.
actualizare
Dacă utilizați Kubernetes 1.16+ - conversia webhook-urilor vă va permite să lucrați cu versiunile API simultan și fără probleme v1alpha2, v1alpha3, v1beta1 и v1. Cu ele, puteți utiliza noua versiune a API-ului fără a modifica sau redistribui resursele vechi. Vă recomandăm insistent să faceți upgrade la API-ul manifestelor dvs v1, deoarece versiunile anterioare vor fi în curând depreciate. Utilizatori legacy versiunile de cert-manager vor avea în continuare acces doar la v1, pot fi găsiți pașii de actualizare .
Comanda de stare kubectl cert-manager
Cu noi îmbunătățiri în extensia noastră la kubectl A devenit mai ușor de investigat problemele asociate cu neeliberarea certificatelor. kubectl cert-manager status acum oferă mult mai multe informații despre ceea ce se întâmplă cu certificatele și arată, de asemenea, stadiul în care este eliberat certificatul.
După instalarea extensiei, puteți rula kubectl cert-manager status certificate <имя-сертификата>, care va căuta certificatul cu numele specificat și orice resurse asociate, cum ar fi CertificateRequest, Secret, Issuer și Order and Challenges în cazul certificatelor de la ACME.
Un exemplu de depanare a unui certificat care nu este încă gata:
$ 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
Echipa vă poate ajuta, de asemenea, să aflați mai multe despre conținutul certificatului. Exemple de detalii pentru un certificat emis de Letsencrypt:
$ 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
[...]
Profitați de cele mai recente API-uri stabile Kubernetes
Cert-manager a fost unul dintre primii care au implementat CRD-urile Kubernetes. Acest lucru, împreună cu suportul nostru pentru versiunile Kubernetes până la 1.11, a însemnat că trebuie să sprijinim moștenirea apiextensions.k8s.io/v1beta1 și pentru CRD-urile noastre admissionregistration.k8s.io/v1beta1 pentru webhook-urile noastre. Acestea sunt acum depreciate și vor fi eliminate în Kubernetes începând cu versiunea 1.22. Cu versiunea 1.0, oferim acum suport complet apiextensions.k8s.io/v1 и admissionregistration.k8s.io/v1 pentru Kubernetes 1.16 (unde au fost adăugate) și mai târziu. Pentru utilizatorii versiunilor anterioare, continuăm să oferim asistență v1beta1 în a noastră legacy versiuni.
Înregistrare îmbunătățită
În această versiune, am actualizat biblioteca de înregistrare la klog/v2, folosit în Kubernetes 1.19. De asemenea, revizuim fiecare revistă pe care o scriem pentru a ne asigura că i se atribuie nivelul corespunzător. Ne-am ghidat după asta . Sunt cinci (de fapt - șase, aproximativ traducător) niveluri de înregistrare începând de la Error (nivel 0), care tipărește numai erori importante și se termină cu Trace (nivelul 5), care vă va ajuta să aflați exact 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 rulați cert-manager.
Sfat: în mod implicit, cert-manager rulează la nivelul 2 (Info), puteți înlocui acest lucru folosind global.logLevel în graficul Helm.
Notă: Revizuirea jurnalelor este ultima soluție atunci când depanați. Pentru mai multe informații, consultați-ne .
NB editorului: Pentru a afla mai multe despre cum funcționează totul sub capota Kubernetes, pentru a primi sfaturi valoroase de la profesori practicanți, precum și asistență tehnică de înaltă calitate, puteți participa la cursuri intensive online , care va avea loc în perioada 28-30 septembrie, și , care va avea loc în perioada 14–16 octombrie.
Îmbunătățiri ACME
Cea mai frecventă utilizare a cert-manager este probabil legată de emiterea de certificate de la Let's Encrypt folosind ACME. Versiunea 1.0 este remarcabilă pentru utilizarea feedback-ului comunității pentru a adăuga două îmbunătățiri mici, dar importante, emitentului nostru ACME.
Dezactivați generarea cheii de cont
Dacă utilizați certificate ACME în volume mari, probabil că utilizați același cont pe mai multe clustere, astfel încât restricțiile de emitere a certificatelor se vor aplica tuturor acestora. Acest lucru a fost deja posibil în cert-manager la copierea secretului specificat în privateKeySecretRef. Acest caz de utilizare a fost destul de greșit, deoarece cert-manager a încercat să fie de ajutor și a creat cu bucurie o nouă cheie de cont dacă nu a găsit una. De aceea am adăugat disableAccountKeyGenerationpentru a vă proteja de acest comportament setând această opțiune la true - cert-manager nu va genera o cheie și vă va avertiza că nu i s-a dat o cheie de cont.
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
name: letsencrypt
spec:
acme:
privateKeySecretRef:
name: example-issuer-account-key
disableAccountKeyGeneration: false
Lanț preferat
29 septembrie Să criptăm către propria autoritate de certificare rădăcină ISRG Root. Certificatele cu semnătură încrucișată vor fi înlocuite cu Identrust. Această modificare nu necesită modificări ale setărilor certificat-manager, toate certificatele actualizate sau noi emise după această dată vor folosi noua CA rădăcină.
Let's Encrypt semnează deja certificate cu această CA și le oferă ca „lanț de certificate alternativ” prin ACME. Această versiune de cert-manager are capacitatea de a seta accesul la aceste lanțuri în setările emitentului. În parametru preferredChain Puteți specifica numele CA utilizat pentru eliberarea certificatului. Dacă este disponibil un certificat CA care se potrivește cu cererea, acesta vă va emite un certificat. Vă rugăm să rețineți că aceasta este opțiunea preferată, dacă nu se găsește nimic, se va emite un certificat implicit. Acest lucru vă va asigura că vă veți reînnoi în continuare certificatul după ștergerea lanțului alternativ din partea emitentului ACME.
Astăzi puteți primi certificate semnate ISRG Root, Asa de:
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ărăsiț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"
Vă rugăm să rețineți că acest CA rădăcină va fi în curând depreciat, Let's Encrypt va menține acest lanț activ până pe 29 septembrie 2021.
Sursa: www.habr.com
