Ak sa opýtate skúseného, múdreho inžiniera, čo si myslí o cert-manager a prečo ho všetci používajú, tak špecialista si vzdychne, dôverne vás objíme a unavene povie: „Všetci ho používajú, pretože neexistujú žiadne rozumné alternatívy. Naše myši plačú, bodajú sa, ale aj tak pokračujú v živote s týmto kaktusom. Prečo ho milujeme? Pretože to funguje. Prečo ho nemáme radi? Pretože neustále vychádzajú nové verzie, ktoré používajú nové funkcie. A musíme zakaždým aktualizovať klaster. A staré verzie prestávajú fungovať, pretože existuje sprisahanie a veľké tajomné šamanstvo.
Ale vývojári sa snažia presvedčiť, že s cert-manager 1.0 všetko sa zmení.
Veríme?

Cert-manager je 'nativní' kontrolór pre správu certifikátov Kubernetes. S jeho pomocou môžete vystaviť certifikáty z rôznych zdrojov: Let’s Encrypt, HashiCorp Vault, Venafi, páry kľúčov na podpis a samo-podpísané certifikáty. Rovnako umožňuje udržiavať kľúče aktuálne v čase platnosti a tiež sa snaží automaticky obnoviť certifikáty v stanovenom čase pred ich vypršaním. Cert-manager je založený na kube-lego a taktiež využíval niektoré techniky z iných podobných projektov, napríklad kube-cert-manager.
Poznámky k vydaniu
Verziou 1.0 vyjadrujeme dôveru po troch rokoch vývoja projektu cert-manager. Počas tejto doby sa výrazne zlepšila jeho funkcionalita a stabilita, ale najviac sa rozvinula komunita. Dnes vidíme, ako mnohí ľudia používajú cert-manager na ochranu svojich klastrov Kubernetes a tiež ho integrujú do rôznych častí ekosystému. V posledných 16 vydaniach bolo opravených množstvo chýb. A to, čo sa malo rozbiť, bolo rozbité. Niekoľko zásahov v práci s API zlepšilo jeho interakciu s používateľmi. Riešili sme 1500 problémov na GitHub s ešte väčším počtom požiadaviek na zlúčenie od 253 členov komunity.
Pri vydaní verzie 1.0 oficiálne oznamujeme, že cert-manager je zrelý projekt. Rovnako sa zaväzujeme udržovať kompatibilitu nášho API. v1.
Obrovská vďaka všetkým, ktorí nám pomáhali robiť cert-manager počas týchto troch rokov! Nech sa verzia 1.0 stane prvým z mnohých budúcich veľkých úspechov.
Vydanie 1.0 je stabilné vydanie s niekoľkými prioritnými oblastami:
v1API;Tím
kubectl cert-manager status, na pomoc pri analýze problémov;Použitie najnovších stabilných API Kubernetes;
Zlepšené logovanie;
Zlepšenia ACME.
Pred aktualizáciou si nezabudnite prečítať poznámky k aktualizácii.
API v1
Verzia v0.16 pracovala s API v1beta1. To prinieslo niektoré štrukturálne zmeny a taktiež zlepšilo dokumentáciu k poliam API. Verzia 1.0 na tom všetkom stojí s pomocou API v1. Toto API je naším prvým stabilným, zároveň sme už poskytli záruky kompatibility, ale s API v1 sľubujeme zachovať kompatibilitu na mnoho rokov dopredu.
Zmeny, ktoré boli vykonané (poznámka: naše prostriedky na konverziu sa postarajú o všetko za vás):
Certifikát:
emailSANsteraz sa nazývaemailAddressesuriSANs—uris
Tieto zmeny pridávajú kompatibilitu s ďalšími SAN (názvy alternatív subjektu, pozn. prekladateľa), a taktiež s Go API. Tento termín odstraňujeme z nášho API.
Update
Ak používate Kubernetes 1.16+ — konverzujúce webhooks vám umožnia pracovať bez problémov so všetkými verziami API v1alpha2, v1alpha3, v1beta1 a v1. S ich pomocou môžete používať novú verziu API bez zmeny alebo opätovného nasadenia vašich starých zdrojov. Dôrazne odporúčame aktualizovať manifesty na API v1, keďže predchádzajúce verzie budú čoskoro vyhlásené za zastarané. Používatelia legacy verzie cert-manager budú naďalej mať prístup iba k v1, kroky na aktualizáciu môžete nájsť .
Tím kubectl cert-manager status
S novými vylepšeniami v našom rozšírení k kubectl bolo jednoduchšie skúmať problémy súvisiace s nevydávaním certifikátov. kubectl cert-manager status teraz poskytuje oveľa viac informácií o tom, čo sa deje s certifikátmi, a taktiež ukazuje fázu vydávania certifikátu.
Po inštalácii rozšírenia môžete spustiť kubectl cert-manager status certificate, čo vedie k vyhľadaniu certifikátu s uvedeným názvom a akýchkoľvek súvisiacich zdrojov, ako sú CertificateRequest, Secret, Issuer a tiež Order a Challenges v prípade používania certifikátov od ACME.
Príklad ladenia ešte nevydaného certifikátu:
$ kubectl cert-manager status certificate acme-certificate
Názov: acme-certificate
Namespace: default
Vytvorené: 2020-08-21T16:44:13+02:00
Podmienky:
Pripravené: False, Dôvod: DoesNotExist, Správa: Vydanie certifikátu, pretože tajný kľúč neexistuje
Vydávanie: True, Dôvod: DoesNotExist, Správa: Vydanie certifikátu, pretože tajný kľúč neexistuje
DNS mená:
- example.com
Udalosti:
Typ Dôvod Vek Z Správa
---- ------ ---- ---- -------
Normálne Vydávanie 18m cert-manager Vydanie certifikátu, pretože tajný kľúč neexistuje
Normálne Vygenerované 18m cert-manager Uložil nový súkromný kľúč do dočasného tajného zdroja "acme-certificate-tr8b2"
Normálne Požiadal 18m cert-manager Vytvoril nový CertificateRequest zdroj "acme-certificate-qp5dm"
Vydavateľ:
Názov: acme-issuer
Typ: Vydavateľ
Podmienky:
Pripravené: True, Dôvod: ACMEAccountRegistered, Správa: ACME účet bol registrovaný s ACME serverom
Chyba pri hľadaní tajného kľúča "acme-tls": tajné kľúče "acme-tls" neboli nájdené
Nie skôr:
Nie neskôr:
Čas obnovy:
CertificateRequest:
Názov: acme-certificate-qp5dm
Namespace: default
Podmienky:
Pripravené: False, Dôvod: Čakajúce, Správa: Čakanie na vydanie certifikátu z objednávky default/acme-certificate-qp5dm-1319513028: "pending"
Udalosti:
Typ Dôvod Vek Z Správa
---- ------ ---- ---- -------
Normálne ObjednávkaVytvorená 18m cert-manager Vytvorené Objednávka zdroj default/acme-certificate-qp5dm-1319513028
Objednávka:
Názov: acme-certificate-qp5dm-1319513028
Stav: čakajúce, Dôvod:
Autorizácie:
URL: https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/97777571, Identifikátor: example.com, Počiatočný stav: čakajúce, Divoká: false
Výzvy:
- Názov: acme-certificate-qp5dm-1319513028-1825664779, Typ: DNS-01, Token: J-lOZ39yNDQLZTtP_ZyrYojDqjutMAJOxCL1AkOEZWw, Kľúč: U_W3gGV2KWgIUonlO2me3rvvEOTrfTb-L5s0V1TJMCw, Stav: čakajúce, Dôvod: chyba pri získavaní clouddns účtu: tajný kľúč "clouddns-accoun" nebol nájdený, Spracovávanie: true, Predložené: false
Príkaz tiež môže pomôcť získať podrobnejšie informácie o obsahu certifikátu. Príklad podrobností pre certifikát vydaný Letsencrypt:
$ kubectl cert-manager status certificate example
Názov: example
[...]
Tajný kľúč:
Názov: example
Krajina Vydavateľa: US
Organizácia Vydavateľa: Let's Encrypt
Spoločný názov Vydavateľa: Let's Encrypt Authority X3
Použitie kľúča: Digitálny podpis, Kódovanie kľúča
Rozšírené použitia kľúča: Serverová autentifikácia, Klientská autentifikácia
Algoritmus verejného kľúča: RSA
Algoritmus podpisu: SHA256-RSA
ID kľúča predmetu: 65081d98a9870764590829b88c53240571997862
ID kľúča autority: a84a6a63047dddbae6d139b7a64565eff3a8eca1
Sériové číslo: 0462ffaa887ea17797e0057ca81d7ba2a6fb
Udalosti:
Nie skôr: 2020-06-02T04:29:56+02:00
Nie neskôr: 2020-08-31T04:29:56+02:00
Čas obnovy: 2020-08-01T04:29:56+02:00
[...]
Používanie najnovších stabilných API Kubernetes
Cert-manager bol jedným z prvých, ktorý implementoval Kubernetes CRDs. To, ako aj naša podpora verzií Kubernetes až do 1.11, viedlo k tomu, že sme museli podporovať zastarané apiextensions.k8s.io/v1beta1 pre naše CRD, ako aj admissionregistration.k8s.io/v1beta1 pre naše webhooky. Teraz sú zastarané a budú odstránené v Kubernetes s verziou 1.22. S našou 1.0 teraz ponúkame plnú podporu apiextensions.k8s.io/v1 a admissionregistration.k8s.io/v1 pre Kubernetes 1.16 (kde boli pridané) a novšie. Pre používateľov predchádzajúcich verzií naďalej ponúkame podporu v1beta1 v našej legacy verzii.
Vylepšené protokolovanie
V tejto verzii sme aktualizovali knižnicu pre protokolovanie na klog/v2, ktorú používajú Kubernetes 1.19. Taktiež kontrolujeme každú správu, ktorú zaznamenávame, aby sme jej priradili príslušnú úroveň. Pripravovali sme sa podľa . Existuje päť (v skutočnosti šesť, pozn. prekladateľa) úrovní protokolovania, počnúc Chyba (úroveň 0), ktorá vypisuje len dôležité chyby, a končiac Trace (úroveň 5), ktorá pomôže presne zistiť, čo sa deje. Touto zmenou sme znížili množstvo protokolov, ak nepotrebujete ladenie pri práci cert-manager.
Tip: predvolené nastavenie cert-manager je na úrovni 2 (Info), môžete to prekonať použitím global.logLevel v Helm charte.
Poznámka: prezeranie protokolov je konečná možnosť pri odstraňovaní problémov. Pre viac informácií si prečítajte náš .
N.B. redakcia: Ak sa chcete dozvedieť viac o tom, ako to všetko funguje pod kapotou Kubernetes, získať cenné rady od praktikov-lektorov a aj kvalitnú pomoc technickej podpory, môžete sa zúčastniť online intenzívov , ktorý sa uskutoční 28.-30. septembra, a , ktorý sa uskutoční 14.-16. októbra.
Vylepšenia ACME
Najčastejšie používanie cert-manager je pravdepodobne spojené s vydávaním certifikátov od Let’s Encrypt pomocou ACME. Verzia 1.0 sa vyznačuje využívaním spätnej väzby od komunity na pridanie dvoch malých, ale dôležitých vylepšení do nášho ACME issuer.
Deaktivácia vytvárania kľúča účtu
Ak používate certifikáty ACME vo veľkých množstvách, pravdepodobne používate rovnaký účet na viacerých klastroch, takže vaše obmedzenia na vydávanie certifikátov sa budú týkať všetkých. To už bolo možné v cert-manager pri kopírovaní tajného kľúča uvedeného v privateKeySecretRef. Tento spôsob použitia bol dosť problematický, pretože cert-manager sa snažil byť nápomocný a s radosťou vytváral nový kľúč účtu, ak ho nenašiel. Preto sme pridali disableAccountKeyGeneration, aby sme vás ochránili pred takýmto správaním; ak nastavíte túto hodnotu na true — cert-manager nebude vytvárať kľúč a upozorní vás, že mu nebol poskytnutý kľúč účtu.
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
name: letsencrypt
spec:
acme:
privateKeySecretRef:
name: example-issuer-account-key
disableAccountKeyGeneration: false
Preferovaný reťazec
29. septembra Let’s Encrypt na vlastné koreňové certifikačné centrum ISRG Root. Certifikáty s krížovými podpismi budú nahradené Identrust. Táto zmena si nevyžaduje úpravy v nastaveniach cert-manager, všetky aktualizované alebo nové certifikáty vydané po tomto dátume budú používať nový koreňový CA.
Let’s Encrypt už podpisuje certifikáty pomocou tohto CA a ponúka ich ako "alternatívny reťazec certifikátov" cez ACME. V tejto verzii cert-manager je možné nastaviť prístup k týmto reťazcom v nastaveniach emissora. V parametri preferredChain môžete zadať názov používaného CA, pomocou ktorého bude certifikát vydaný. Ak bude dostupný certifikát CA, ktorý zodpovedá požiadavke, vydá vám certifikát. Upozorňujeme, že toto je preferovaná možnosť, ak nič nie je nájdené — bude vydaný certifikát podľa predvoleného nastavenia. To zabezpečí, že aj tak aktualizujete svoj certifikát po odstránení alternatívneho reťazca na strane ACME emissora.
Už dnes je možné získať certifikáty, podpísané ISRG Root, takto:
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
name: letsencrypt
spec:
acme:
server: https://acme-v02.api.letsencrypt.org/directory
preferredChain: "ISRG Root X1"
Ak uprednostňujete ponechať reťazec IdenTrust — nastavte tento parameter na 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"
Upozorňujeme, že toto koreňové certifikačné centrum čoskoro prestane byť podporované, Let’s Encrypt bude udržiavať tento reťazec aktívny do 29. septembra 2021.
Zdroj: habr.com
