🥇Cert-manager 1.0 hè fora

Se dumandate à un ingegnere espertu è sàviu ciò ch'ellu pensa di cert-manager è perchè tutti l'utilizanu, allora u specialista suspirà, l'abbracciarà in cunfidenza è dicenu stancu: "Tutti l'utilizanu, perchè ùn ci sò micca alternative sane. I nostri topi pienghjenu, punghjenu, ma cuntinueghjanu à campà cù stu cactus. Perchè amemu? Perchè travaglia. Perchè ùn amemu micca? Perchè e versioni novi sò sempre esce chì utilizanu funzioni novi. È avete da aghjurnà u cluster una volta è una volta. È e versioni vechji cessanu di travaglià, perchè ci hè una cuspirazione è un grande sciamanisimu misteriosu.

Ma i sviluppatori dicenu chì cert-manager 1.0 tuttu cambierà.

Crideremu ?

Cert-manager hè u controller nativu di gestione di certificati Kubernetes. Pò esse usatu per emette certificati da diverse fonti: Let's Encrypt, HashiCorp Vault, Venafi, firmate è coppie di chjave autofirmate. Hè ancu permette di mantene e chjave up-to-date da a data di scadenza, è ancu prova di rinnuvà automaticamente i certificati à un tempu specificatu prima di scadenza. Cert-manager hè basatu annantu à kube-lego è hà ancu utilizatu alcuni trucchi da altri prughjetti simili cum'è kube-cert-manager.

Note di rilascio

Cù a versione 1.0, avemu messu una marca di fiducia per trè anni di sviluppu di u prughjettu cert-manager. Duranti stu tempu, hà evolutu significativamente in funziunalità è stabilità, ma soprattuttu in a cumunità. Oghje, vedemu parechje persone chì l'utilizanu per assicurà i so clusters Kubernetes è ancu di implementà in diverse parti di l'ecosistema. Un saccu di bug sò stati risolti in l'ultime versioni 16. È ciò chì ci vole à esse rottu hè rottu. Diversi visiti per travaglià cù l'API anu migliuratu a so interazzione cù l'utilizatori. Avemu risoltu 1500 prublemi nantu à GitHub cù più richieste di pull da 253 membri di a cumunità.

Cù a liberazione di 1.0, dichjaremu ufficialmente chì cert-manager hè un prughjettu maturu. Avemu ancu prumessu di mantene a nostra API cumpatibile v1.

Grazie mille à tutti quelli chì ci anu aiutatu à fà cert-manager tutti sti trè anni ! Chì a versione 1.0 sia a prima di parechje grandi cose à vene.

A versione 1.0 hè una versione stabile cù parechje aree di priorità:

v1 FEU;
squadra kubectl cert-manager status, per aiutà cù l'analisi di u prublema;
Utilizà l'ultime API stabili di Kubernetes;
Logging melloratu;
Migliure ACME.

Assicuratevi di leghje e note di l'aghjurnamentu prima di l'aghjurnamentu.

API v1

A versione v0.16 hà travagliatu cù l'API v1beta1. Questu hà aghjustatu alcuni cambiamenti strutturali è hà ancu migliuratu a documentazione di u campu API. A versione 1.0 si basa nantu à questu cù una API v1. Questa API hè a nostra prima stabile, à u stessu tempu avemu digià datu garanzii di cumpatibilità, ma cù l'API v1 prumettimu di mantene a cumpatibilità per l'anni à vene.

Cambiamenti fatti (nota: i nostri strumenti di cunversione si curanu di tuttu per voi):

Certificatu:

emailSANs avà chjamatu emailAddresses
uriSANs - uris

Questi cambiamenti aghjunghjenu a cumpatibilità cù altri SAN (sughjetti alt nomi, ca. traduttore), è ancu cù l'API Go. Rimuovemu stu termini da a nostra API.

Update

Sè vo aduprate Kubernetes 1.16+, a cunversione di webhooks vi permetterà di travaglià simultaneamente è senza saldatura cù versioni API. v1alpha2, v1alpha3, v1beta1 и v1. Cù questi, puderà utilizà a nova versione di l'API senza cambià o redistribuisce i vostri vechji risorse. Hè cunsigliatu assai di aghjurnà i vostri manifesti à l'API v1, cum'è e versioni precedenti seranu obsolete prestu. Users legacy versioni di cert-manager vi hannu sempre solu accessu à v1, i passi di l'aghjurnamentu ponu esse truvati ccà.

Kubectl cert-manager status cumanda

Cù novi migliure in a nostra estensione à kubectl hè diventatu più faciule per investigà i prublemi assuciati cù a non-emissione di certificati. kubectl cert-manager status avà dà assai più infurmazione nantu à ciò chì succede cù i certificati è mostra ancu a tappa di emissione di certificati.

Dopu avè installatu l'estensione, pudete eseguisce kubectl cert-manager status certificate <имя-сертификата>, chì cercherà u certificatu cù u nome datu è qualsiasi risorse cunnesse cum'è CertificateRequest, Secret, Issuer, è Order and Challenges se utilizate certificati da ACME.

Un esempiu di debugging di un certificatu chì ùn hè ancu pronta:

$ 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

U cumandamentu pò ancu aiutà à amparà più nantu à u cuntenutu di u certificatu. Esempiu detallatu per un certificatu emessu da 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
[...]

Utilizendu l'ultime API stabili di Kubernetes

Cert-manager hè statu unu di i primi à implementà i CRD Kubernetes. Questu, è u nostru supportu per e versioni Kubernetes finu à 1.11, significava chì avemu bisognu di sustene u legatu. apiextensions.k8s.io/v1beta1 per i nostri CRD ancu admissionregistration.k8s.io/v1beta1 per i nostri webhooks. Avà sò obsoleti è seranu eliminati in Kubernetes da a versione 1.22. Cù u nostru 1.0, avà offre un supportu tutale apiextensions.k8s.io/v1 и admissionregistration.k8s.io/v1 per Kubernetes 1.16 (induve sò stati aghjuntu) è più recenti. Per l'utilizatori di versioni precedenti, cuntinuemu à offre supportu v1beta1 in u nostru legacy versioni.

Logging melloratu

In questa liberazione, avemu aghjurnatu a biblioteca di logu à klog/v2, usatu in Kubernetes 1.19. Rivisemu ancu ogni ghjurnale chì scrivimu per assicurà chì hè assignatu u livellu adattatu. Eramu guidati da questu guida di Kubernetes. Ci sò cinque (in realtà sei, ca. traduttore) livelli di logging partendu da Error (livellu 0), chì stampa solu errori impurtanti, è finisce cù Trace (livellu 5) chì vi aiuterà à sapè esattamente ciò chì succede. Cù stu cambiamentu, avemu ridutta u numeru di logs s'è vo ùn avete bisognu di infurmazione debug quandu eseguisce cert-manager.

Tip: cert-manager corre à u livellu 2 per difettu (Info), pudete annullà questu utilizendu global.logLevel in Helmchart.

Nota: A visualizazione di i logs hè l'ultimu risorsu per a risoluzione di i prublemi. Per più infurmazione verificate u nostru dirigenza.

Editore n.b.: Per sapè di più nantu à cumu tuttu funziona sottu u cappucciu di Kubernetes, uttene cunsiglii preziosi da i prufessori praticanti, è ancu un aiutu di supportu tecnicu di qualità, pudete participà à intensivi in linea. Base Kubernetes, chì si terrà 28-30 settembre, è Kubernetes Megachì si terrà da u 14 à u 16 d'ottobre.

Migliure ACME

L'usu più cumuni di cert-manager hè probabilmente ligatu à l'emissione di certificati da Let's Encrypt cù ACME. A versione 1.0 hè nota per l'usu di feedback di a cumunità per aghjunghje duie migliure chjuche ma impurtanti à u nostru emittente ACME.

Disattivà a generazione di chjave di u contu

Sè vo aduprate certificati ACME in volumi grossi, hè prubabile di utilizà u stessu contu in parechji clusters, cusì e vostre restrizioni di emissione di certificati s'applicà à tutti. Questu era digià pussibule in cert-manager quandu copiava u sicretu specificatu in privateKeySecretRef. Stu casu d'usu era abbastanza buggy, cum'è cert-manager hà pruvatu à esse d'aiutu è felice di creà una nova chjave di u contu s'ellu ùn hà micca truvatu. Hè per quessa chì avemu aghjustatu disableAccountKeyGenerationper pruteggià da stu cumpurtamentu se stabilisce sta opzione true - cert-manager ùn generà micca una chjave è vi avviserà chì ùn hè micca stata furnita cù una chjave di contu.

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

Catena Preferita

Settembre 29 Let's Encrypt passerà à a vostra propria radica CA ISRG Root. I certificati firmati in croce seranu rimpiazzati da Identrust. Stu cambiamentu ùn hà micca bisognu di cambiamenti à i paràmetri di u cert-manager, tutti i certificati aghjurnati o novi emessi dopu à sta data utilizanu a nova CA root.

Let's Encrypt firma digià certificati cù questa CA è li offre cum'è una "catena di certificati alternativu" via ACME. In questa versione di cert-manager, hè pussibule stabilisce l'accessu à queste catene in i paràmetri di l'emittente. In u paràmetru preferredChain pudete specificà u nome di a CA in usu, cù quale u certificatu serà emessu. Se un certificatu CA chì currisponde à a dumanda hè dispunibule, vi emetterà un certificatu. Per piacè nutate chì questa hè l'opzione preferita, se ùn si trova nunda, un certificatu predeterminatu serà emessu. Questu hà da assicurà chì avete sempre rinnuvà u vostru certificatu dopu avè eliminatu a catena alternativa da u latu di l'emittente ACME.

Dighjà oghje pudete riceve certificati firmati da ISRG Root, Allora:

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

Se preferite lascià a catena IdenTrust - stabilisce sta opzione à 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"

Per piacè nutate chì sta CA radica serà obsoleta prestu, Let's Encrypt mantene sta catena attiva finu à u 29 di settembre di u 2021.

Source: www.habr.com

cert-manager 1.0 liberatu