🥇Cert-manager 1.0 je venku

Pokud se zeptáte zkušeného, moudrého inženýra, co si myslí o cert-managerovi a proč to všichni používají, pak si specialista povzdechne, sebevědomě ho obejme a unaveně řekne: „Všichni to používají, protože neexistují žádné rozumné alternativy. Naše myši pláčou, píchají, ale dál žijí s tímto kaktusem. Proč milujeme? Protože to funguje. Proč se nemilujeme? Protože neustále vycházejí nové verze, které využívají nové funkce. A cluster musíte aktualizovat znovu a znovu. A staré verze přestávají fungovat, protože dochází ke spiknutí a velkému tajemnému šamanismu.

To ale tvrdí vývojáři cert-manager 1.0 vše se změní.

Budeme věřit?

Cert-manager je nativní řadič správy certifikátů Kubernetes. Může vydávat certifikáty z různých zdrojů: Let's Encrypt, HashiCorp Vault, Venafi, podepisování párů klíčů a self-signed. Umožňuje také udržovat klíče aktuální podle doby vypršení platnosti a také se pokouší automaticky obnovit certifikáty v určený čas před vypršením platnosti. Cert-manager je založen na kube-lego a také použil některé triky z jiných podobných projektů, jako je kube-cert-manager.

Poznámky k vydání

S verzí 1.0 jsme dali známku důvěry za tři roky vývoje projektu cert-manager. Během této doby se výrazně vyvinul ve funkčnosti a stabilitě, ale především v komunitě. Dnes vidíme mnoho lidí, kteří jej používají k zabezpečení svých clusterů Kubernetes a také jej nasazují do různých částí ekosystému. V posledních 16 vydáních bylo opraveno mnoho chyb. A to, co bylo potřeba rozbít, je rozbité. Několik návštěv za účelem práce s rozhraním API zlepšilo jeho interakci s uživateli. Vyřešili jsme 1500 253 problémů na GitHubu pomocí dalších žádostí o stažení od XNUMX členů komunity.

S vydáním 1.0 oficiálně prohlašujeme, že cert-manager je vyspělý projekt. Slibujeme také, že udržíme naše API kompatibilní v1.

Mnohokrát děkujeme všem, kteří nám celé ty tři roky pomáhali dělat cert-managera! Nechť je verze 1.0 první z mnoha velkých věcí, které přijdou.

Vydání 1.0 je stabilní vydání s několika prioritními oblastmi:

v1 API;
Tým kubectl cert-manager status, pomoci s analýzou problémů;
Používání nejnovějších stabilních rozhraní API Kubernetes;
Vylepšené protokolování;
Vylepšení ACME.

Před upgradem si přečtěte poznámky k upgradu.

API v1

Verze v0.16 pracovala s API v1beta1. To přidalo některé strukturální změny a také zlepšilo dokumentaci API. Verze 1.0 na tom staví pomocí API v1. Toto API je naše první stabilní, zároveň jsme již dali záruky kompatibility, ale s API v1 Slibujeme, že zachováme kompatibilitu pro nadcházející roky.

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

Osvědčení:

emailSANs nyní volán emailAddresses
uriSANs - uris

Tyto změny přidávají kompatibilitu s jinými sítěmi SAN (předmětové alt názvy, Cca. překladatel), stejně jako s Go API. Tento termín odstraňujeme z našeho API.

Aktualizovat

Pokud používáte Kubernetes 1.16+, převod webhooků vám umožní současně a bezproblémově pracovat s verzemi API v1alpha2, v1alpha3, v1beta1 и v1. Díky nim budete moci používat novou verzi rozhraní API, aniž byste museli měnit nebo znovu nasazovat své staré prostředky. Důrazně doporučujeme upgradovat vaše manifesty na API v1, protože předchozí verze budou brzy ukončeny. Uživatelé legacy verze cert-manager budou mít stále přístup pouze k v1, kroky upgradu naleznete zde.

kubectl stavový příkaz cert-manager

S novými vylepšeními v našem rozšíření na kubectl bylo snazší zkoumat problémy spojené s nevydá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 <имя-сертификата>, který vyhledá certifikát s daným názvem a všechny související zdroje, jako je CertificateRequest, Secret, Issuer a Order and Challenges, pokud používáte certifikáty od ACME.

Příklad ladění certifikátu, který ještě není připraven:

$ 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

Příkaz vám také může pomoci dozvědět se více o obsahu certifikátu. Podrobný příklad certifikátu vydaného společností 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
[...]

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

Cert-manager byl jedním z prvních, kdo implementoval Kubernetes CRD. To a naše podpora pro verze Kubernetes až do 1.11 znamenaly, že jsme potřebovali podporovat starší verzi apiextensions.k8s.io/v1beta1 i pro naše CRD admissionregistration.k8s.io/v1beta1 pro naše webhooky. Nyní jsou zastaralé a budou odstraněny v Kubernetes z verze 1.22. S naší verzí 1.0 nyní nabízíme plnou podporu apiextensions.k8s.io/v1 и admissionregistration.k8s.io/v1 pro Kubernetes 1.16 (kde byly přidány) a novější. Pro uživatele předchozích verzí nadále nabízíme podporu v1beta1 v našem legacy verze.

Vylepšené protokolování

V této verzi jsme aktualizovali knihovnu protokolování na klog/v2, používaný v Kubernetes 1.19. Také kontrolujeme každý časopis, který píšeme, abychom se ujistili, že je mu přiřazena vhodná úroveň. Tím jsme se řídili pokyny od Kubernetes. Je jich pět (ve skutečnosti šest, Cca. překladatel) úrovně protokolování počínaje Error (úroveň 0), která vypíše pouze důležité chyby a končí Trace (úroveň 5), což vám pomůže přesně vědět, co se děje. Touto změnou jsme snížili počet protokolů, pokud při spuštění cert-manager nepotřebujete informace o ladění.

Tip: cert-manager běží ve výchozím nastavení na úrovni 2 (Info), toto můžete přepsat pomocí global.logLevel v Helmchart.

Poznámka: Zobrazení protokolů je poslední možností při odstraňování problémů. Pro více informací navštivte naše vedení lidí.

Redakce n.b.: Chcete-li se dozvědět více o tom, jak to vše funguje pod poklicí Kubernetes, získat cenné rady od praktických učitelů a také kvalitní pomoc technické podpory, můžete se zúčastnit online intenzivních kurzů Základna Kubernetes, který se bude konat 28. – 30. září a Kubernetes Megakterý se bude konat 14. – 16. října.

Vylepšení ACME

Nejběžnější použití cert-manageru pravděpodobně souvisí s vydáváním certifikátů z Let's Encrypt pomocí ACME. Verze 1.0 je pozoruhodná tím, že využívá zpětnou vazbu od komunity k přidání dvou malých, ale důležitých vylepšení našeho vydavatele ACME.

Zakázat generování klíčů účtu

Pokud používáte certifikáty ACME ve velkých objemech, pravděpodobně budete používat stejný účet na více clusterech, takže vaše omezení vydávání certifikátů se budou vztahovat na všechny z nich. To již bylo možné v cert-manager při kopírování tajného klíče uvedeného v privateKeySecretRef. Tento případ použití byl docela chybný, protože cert-manager se snažil být nápomocný a šťastně vytvořil nový klíč účtu, pokud žádný nenašel. Proto jsme přidali disableAccountKeyGenerationabyste byli chráněni před tímto chováním, pokud tuto možnost nastavíte na true - cert-manager nevygeneruje klíč a upozorní vás, že mu nebyl poskytnut klíč k úč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 do vaší vlastní kořenové CA ISRG Root. Křížově podepsané certifikáty budou nahrazeny Identrust. Tato změna nevyžaduje změny nastavení správce certifikátů, 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 s touto CA a nabízí je jako „alternativní řetězec certifikátů“ prostřednictvím ACME. V této verzi cert-manageru je možné nastavit přístup k těmto řetězcům v nastavení vydavatele. V parametru preferredChain můžete zadat název používaného CA, se kterým bude certifikát vydán. Pokud je k dispozici certifikát CA odpovídající požadavku, vydá vám certifikát. Upozorňujeme, že toto je preferovaná možnost, pokud nebude nic nalezeno, bude vydán výchozí certifikát. Tím zajistíte, že si certifikát obnovíte i po smazání alternativního řetězce na straně vydavatele ACME.

Již dnes můžete obdržet certifikáty s podpisem ISRG Root, Tak:

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 chcete řetěz opustit IdenTrust - nastavte tuto možnost 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 tato kořenová CA bude brzy ukončena, Let's Encrypt ponechá tento řetězec aktivní do 29. září 2021.

Zdroj: www.habr.com

Vydán cert-manager 1.0