🥇Vydán cert-manager 1.0

Pokud se zeptáte zkušeného mnohomoudrého inženýra, co si myslí o cert-manageru a proč ho všichni používají, tak si odborník povzdechne, důvěrně obejme a unaveně řekne: „Všichni ho používají, protože neexistují žádné rozumné alternativy. Naši hlodavci pláčou, trpí, ale stále žijí s tímto kaktusem. Proč ho milujeme? Protože funguje. Proč ho nemilujeme? Protože neustále vycházejí nové verze, které využívají nové funkce. A musíme znovu a znovu aktualizovat klastr. A staré verze přestávají fungovat, protože existuje spiknutí a velké tajemné šamanství.

Ale vývojáři tvrdí, že s cert-manager 1.0 se všechno změní.

Věříme?

Cert-manager je „domácí“ kontroler správy certifikátů Kubernetes. Pomocí něj lze vydávat certifikáty z různých zdrojů: Let’s Encrypt, HashiCorp Vault, Venafi, páry klíčů pro podepisování a také self-signed certifikáty. Umožňuje také udržovat klíče aktuální z hlediska platnosti a automaticky se snaží obnovit certifikáty v určeném čase před jejich vypršením. Cert-manager je postaven na kube-legu a také využil některé techniky z jiných podobných projektů, jako je kube-cert-manager.

Poznámky k vydání

Verzí 1.0 dáváme znamení důvěry za tři roky vývoje projektu cert-manager. Během této doby se výrazně rozvinul v funkcionalitě a stabilitě, ale nejvíce v komunitě. Dnes vidíme, jak mnoho lidí používá tento projekt k ochraně svých Kubernetes klastrů a jak ho implementují do různých částí ekosystému. V posledních 16 vydáních bylo opraveno řada chyb. A to, co mělo být rozbito – bylo rozbito. Několik přístupů k práci s API zlepšilo interakci s uživateli. Řešili jsme 1500 problémů na GitHubu s ještě větším počtem žádostí o sloučení od 253 členů komunity.

Vydáním verze 1.0 oficiálně prohlašujeme, že cert-manager je zralý projekt. Také jsme slíbili, že budeme nadále podporovat kompatibilitu našeho API. v1.

Obrovské poděkování všem, kteří nám pomáhali dělat cert-manager během těchto tří let! Nechť se verze 1.0 stane prvním z mnoha budoucích velkých úspěchů.

Vydání 1.0 je stabilní verze s několika prioritními směry:

v1 API;
Tým kubectl cert-manager status, pro pomoc při analýze problémů;
Použití nejnovějších stabilních API Kubernetes;
Vylepšené protokolování;
Vylepšení ACME.

Před aktualizací si důkladně přečtěte poznámky k aktualizaci.

API v1

Verze v0.16 pracovala s API v1beta1. To přidalo několik strukturálních změn a také zlepšilo dokumentaci k polím API. Verze 1.0 se na to vše opírá pomocí API v1. Toto API je náš první stabilní, přestože jsme již poskytli záruky kompatibility, ale s API v1 slibujeme zachovat kompatibilitu na dlouhá léta.

Provedené změny (poznámka: naše nástroje k převodu se o vše postarají za vás):

Certifikát:

emailSANs se nyní nazývá emailAddresses
uriSANs — uris

Tyto změny přidávají kompatibilitu s jinými SAN (subject alt names, pozn. překladatele), stejně jako s Go API. Tento termín odstraňujeme z našeho API.

Aktualizace

Pokud používáte Kubernetes 1.16+ — převodní webhooks vám umožní současně a bezproblémově pracovat s verzemi API v1alpha2, v1alpha3, v1beta1 a v1. Tyto vám umožní používat novou verzi API bez změny nebo opětovného nasazení vašich starých zdrojů. Důrazně doporučujeme provést aktualizaci manifestů na API v1, protože předchozí verze budou brzy označeny jako zastaralé. Uživatelé legacy verze cert-manager budou mít stále přístup pouze k v1, kroky k aktualizaci najdete zde.

Tým kubectl cert-manager status

S novými vylepšeními v našem rozšíření k kubectl se stalo snazší prozkoumat problémy spojené s nevydáváním certifikátů. kubectl cert-manager status nyní poskytuje mnohem více informací o tom, co se děje s certifikáty, a také ukazuje fázi vydání certifikátu.

Po instalaci rozšíření můžete spustit kubectl cert-manager status certificate, což povede k nalezení certifikátu se zadaným jménem a všech souvisejících zdrojů, jako jsou CertificateRequest, Secret, Issuer, a také Order a Challenges v případě použití certifikátů od ACME.

Příklad ladění ještě nedokončeného certifikátu:

$ 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: Vydání certifikátu, protože Secret neexistuje
  Issuing: True, Reason: DoesNotExist, Message: Vydání certifikátu, protože Secret neexistuje
DNS Names:
- example.com
Events:
  Type    Reason     Age   From          Message
  ----    ------     ----  ----          -------
  Normal  Issuing    18m   cert-manager  Vydání certifikátu, protože Secret neexistuje
  Normal  Generated  18m   cert-manager  Uložil nový privátní klíč v dočasném Secret zdroji "acme-certificate-tr8b2"
  Normal  Requested  18m   cert-manager  Vytvořil nový CertificateRequest zdroj "acme-certificate-qp5dm"
Issuer:
  Name: acme-issuer
  Kind: Issuer
  Conditions:
    Ready: True, Reason: ACMEAccountRegistered, Message: Účet ACME byl zaregistrován na ACME serveru
error when finding Secret "acme-tls": secrets "acme-tls" not found
Not Before: 
Not After: 
Renewal Time: 
CertificateRequest:
  Name: acme-certificate-qp5dm
  Namespace: default
  Conditions:
    Ready: False, Reason: Pending, Message: Čekání na vydání certifikátu z objednávky default/acme-certificate-qp5dm-1319513028: "pending"
  Events:
    Type    Reason        Age   From          Message
    ----    ------        ----  ----          -------
    Normal  OrderCreated  18m   cert-manager  Vytvořil Order zdroj 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: chyba při získávání účtu clouddns služby: secret "clouddns-accoun" not found, Processing: true, Presented: false

Tento příkaz může také pomoci zjistit více o obsahu certifikátu. Příklad podrobností pro certifikát vydaný 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: Digitální podpis, Klíčové šifrování
  Extended Key Usages: Serverová autentizace, Klientská autentizace
  Public Key Algorithm: RSA
  Signature Algorithm: SHA256-RSA
  Subject Key ID: 65081d98a9870764590829b88c53240571997862
  Authority Key ID: a84a6a63047dddbae6d139b7a64565eff3a8eca1
  Serial Number: 0462ffaa887ea17797e0057ca81d7ba2a6fb
  Events:  
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
[...]

Používání nejnovějších stabilních API Kubernetes

Cert-manager byl jedním z prvních, kdo implementoval Kubernetes CRD. To, společně s naší podporou verzí Kubernetes až do 1.11, vedlo k tomu, že jsme museli podporovat zastaralé apiextensions.k8s.io/v1beta1 pro naše CRD, a také admissionregistration.k8s.io/v1beta1 pro naše webhooks. Nyní jsou zastaralé a budou odstraněny v Kubernetes od verze 1.22. S naší 1.0 nyní nabízíme plnou podporu apiextensions.k8s.io/v1 a admissionregistration.k8s.io/v1 pro Kubernetes 1.16 (kde byly přidány) a novější. Pro uživatele předchozích verzí pokračujeme v poskytování podpory v1beta1 v naší legacy verzi.

Vylepšené logování

V této verzi jsme aktualizovali knihovnu pro logování na klog/v2, používanou v Kubernetes 1.19. Také kontrolujeme každý log, který zapisujeme, aby mu byl přiřazen odpovídající úroveň. Řídili jsme se přitom pokyny od Kubernetes. Existuje pět (ve skutečnosti šest, pozn. překladatele) úrovní logování, počínaje Chyba (úroveň 0), která vypisuje pouze důležité chyby, a konče Trace (úroveň 5), která pomůže zjistit přesně, co se děje. Tímto změnami jsme snížili množství logů, pokud nepotřebujete ladicí informace při práci cert-manager.

Tip: výchozí nastavení cert-manageru pracuje na úrovni 2 (Info), můžete to přepsat pomocí global.logLevel v Helm chart.

Poznámka: prohlížení logů je poslední možnost při odstraňování problémů. Pro více informací si prostudujte náš vedení.

N.B. editor: Chcete-li se podrobněji dozvědět, jak to všechno funguje pod kapotou Kubernetes, získat cenné rady od praktiků-učitelů a také kvalitní pomoc technické podpory, můžete se zúčastnit online intenzivních kurzů Základy Kubernetes, které se uskuteční 28.-30. září, a Mega Kubernetes, které se uskuteční 14.-16. října.

Vylepšení ACME

Nejčastěji se používání cert-manageru může spojovat s vydáváním certifikátů od Let’s Encrypt pomocí ACME. Verze 1.0 se vyznačuje využitím odezev od komunity k přidání dvou malých, ale důležitých vylepšení do našeho ACME issuer.

Vypnutí generování klíče účtu

Pokud používáte certifikáty ACME ve velkém objemu, pravděpodobně používáte stejný účet na několika clusterech, takže vaše limity pro vydávání certifikátů se budou vztahovat na všechny. To již bylo možné v cert-manageru při kopírování tajemství uvedeného v privateKeySecretRef. Tento způsob použití byl dost chybový, protože cert-manager se snažil být užitečný a radostně vytvářel nový klíč účtu, pokud ho nenalezl. Proto jsme přidali disableAccountKeyGeneration, abychom vás ochránili před tímto chováním, pokud nastavíte tuto možnost na true — cert-manager nebude vytvářet klíč a upozorní vás, že mu nebyl poskytnut klíč účtu.

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

Preferovaný řetězec

29. září Let’s Encrypt přejde na vlastní kořenový certifikační úřad ISRG Root. Certifikáty s křížovými podpisy budou nahrazeny certifikáty od Identrust. Tato změna nevyžaduje úpravy v nastavení cert-manager, všechny aktualizované nebo nové certifikáty vydané po tomto datu budou používat novou kořenovou CA.

Let’s Encrypt již podepisuje certifikáty pomocí tohoto CA a nabízí je jako "alternativní řetězec certifikátů" prostřednictvím ACME. V této verzi cert-manager je možné zadat přístup k těmto řetězcům v nastavení issuer. V parametru preferredChain můžete uvést název používaného CA, pomocí kterého bude certifikát vydán. Pokud bude dostupný certifikát CA odpovídající žádosti, vydá vám certifikát. Všimněte si, že toto je preferovaná varianta, pokud nebude nic nalezeno — bude vydán certifikát podle výchozí hodnoty. To zaručuje, že i tak provedete obnovu svého certifikátu po odstranění alternativního řetězce na straně ACME issuer.

Už dnes je možné získat certifikáty podepsané 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"

Pokud dáváte přednost ponechání řetězce IdenTrust — nastavte tento parametr 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"

Všimněte si, že tento kořenový certifikační úřad brzy zastará, Let’s Encrypt tento řetězec udrží aktivní do 29. září 2021.

Zdroj: habr.com