🥇Cert-manager 1.0 is út

As jo in betûfte, wize yngenieur freegje wat hy tinkt oer cert-manager en wêrom elkenien it brûkt, dan sil de spesjalist suchtsje, him fertroulik knuffelje en wurch sizze: "Elkenien brûkt it, want der binne gjin ferstannige alternativen. Us mûzen skrieme, prikke, mar libje mei dizze kaktus. Wêrom hâlde wy fan? Want it wurket. Wêrom hâlde wy net? Om't der hieltyd nije ferzjes komme dy't nije funksjes brûke. En jo moatte it kluster hieltyd wer bywurkje. En de âlde ferzjes stopje mei wurkjen, om't der in gearspanning is en in grut mysterieus sjamanisme.

Mar de ûntwikkelders beweare dat cert-manager 1.0 alles sil feroarje.

Sille wy leauwe?

Cert-manager is de native Kubernetes-sertifikaatbehearkontrôler. It kin brûkt wurde om sertifikaten út ferskate boarnen út te jaan: Let's Encrypt, HashiCorp Vault, Venafi, ûndertekening en sels ûndertekene kaaipearen. It lit jo ek toetsen bywurke hâlde op ferfaldatum, en besiket ek sertifikaten automatysk te fernijen op in bepaalde tiid foardat se ferrinne. Cert-manager is basearre op kube-lego en hat ek wat trúkjes brûkt fan oare ferlykbere projekten lykas kube-cert-manager.

Release Notes

Mei ferzje 1.0 sette wy in mark fan fertrouwen foar trije jier ûntwikkeling fan it cert-manager-projekt. Yn dizze tiid is it signifikant ûntwikkele yn funksjonaliteit en stabiliteit, mar it meast yn 'e mienskip. Tsjintwurdich sjogge wy in protte minsken dy't it brûke om har Kubernetes-klusters te befeiligjen en it yn ferskate dielen fan it ekosysteem yn te setten. In protte bugs binne reparearre yn 'e lêste 16 releases. En wat brutsen wurde moast is brutsen. Ferskate besites om te wurkjen mei de API hawwe har ynteraksje mei brûkers ferbettere. Wy hawwe 1500 problemen op GitHub oplost mei mear pull-oanfragen fan 253 mienskipsleden.

Mei de frijlitting fan 1.0 ferklearje wy offisjeel dat cert-manager in folwoeksen projekt is. Wy belje ek om ús API kompatibel te hâlden v1.

Tige tank oan elkenien dy't ús al dizze trije jier holpen hat om cert-manager te meitsjen! Lit ferzje 1.0 de earste wêze fan in protte grutte dingen dy't komme.

Release 1.0 is in stabile release mei ferskate prioriteitsgebieten:

v1 API;
team kubectl cert-manager status, om te helpen mei probleemanalyse;
Mei help fan de lêste stabile Kubernetes APIs;
Ferbettere logging;
ACME ferbetterings.

Wês wis dat jo de upgrade-notysjes lêze foardat jo opwurdearje.

API v1

Ferzje v0.16 wurke mei de API v1beta1. Dit tafoege wat strukturele feroarings en ferbettere ek de API-fjilddokumintaasje. Ferzje 1.0 bout hjirop mei in API v1. Dizze API is ús earste stabile ien, tagelyk hawwe wy al kompatibiliteitsgarânsjes jûn, mar mei de API v1 wy tasizze kompatibiliteit te behâlden foar de kommende jierren.

Feroarings makke (opmerking: ús konverzje-ark soargje foar alles foar jo):

Sertifikaat:

emailSANs no neamd emailAddresses
uriSANs - uris

Dizze wizigingen foegje kompatibiliteit ta mei oare SAN's (ûnderwerp alt-nammen, ca. oersetter), lykas ek mei de Go API. Wy fuortsmite dizze term út ús API.

Update

As jo Kubernetes 1.16+ brûke, sil it konvertearjen fan webhooks jo tagelyk en naadloos wurkje mei API-ferzjes v1alpha2, v1alpha3, v1beta1 и v1. Mei dizze kinne jo de nije ferzje fan 'e API brûke sûnder jo âlde boarnen te feroarjen of opnij yn te setten. Wy riede tige oan om jo manifesten te upgrade nei de API v1, lykas eardere ferzjes meikoarten wurde ôfret. Brûkers legacy ferzjes fan cert-manager sille noch allinich tagong hawwe ta v1, upgrade stappen kinne fûn wurde hjir.

kubectl cert-manager status kommando

Mei nije ferbetterings yn ús útwreiding oan kubectl it waard makliker om de problemen te ûndersiikjen ferbûn mei it net útjaan fan sertifikaten. kubectl cert-manager status jout no folle mear ynformaasje oer wat der bart mei de sertifikaten en toant ek it stadium fan útjefte fan sertifikaten.

Nei it ynstallearjen fan de tafoeging kinne jo rinne kubectl cert-manager status certificate <имя-сертификата>.

In foarbyld fan it debuggen fan in sertifikaat dat noch net klear is:

$ 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

It kommando kin jo ek helpe om mear te learen oer de ynhâld fan it sertifikaat. Detaillearre foarbyld foar in sertifikaat útjûn troch 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
[...]

Mei help fan de lêste stabile Kubernetes API's

Cert-manager wie ien fan 'e earsten dy't Kubernetes CRD's ymplementeare. Dit, en ús stipe foar Kubernetes-ferzjes oant 1.11, betsjutte dat wy de legacy moasten stypje apiextensions.k8s.io/v1beta1 foar ús CRD's ek admissionregistration.k8s.io/v1beta1 foar ús webhooks. Se binne no ôfret en sille fuortsmiten wurde yn Kubernetes fan ferzje 1.22. Mei ús 1.0 biede wy no folsleine stipe apiextensions.k8s.io/v1 и admissionregistration.k8s.io/v1 foar Kubernetes 1.16 (dêr't se waarden tafoege) en nijer. Foar brûkers fan eardere ferzjes bliuwe wy stipe oanbiede v1beta1 yn ús legacy ferzjes.

Ferbettere logging

Yn dizze útjefte hawwe wy de loggingbibleteek bywurke nei klog/v2, brûkt yn Kubernetes 1.19. Wy kontrolearje ek elk tydskrift dat wy skriuwe om te soargjen dat it it passende nivo wurdt tawiisd. Wy waarden liede troch dit begelieding fan Kubernetes. Der binne fiif (eins seis, ca. oersetter) logging nivo's begjinnend fan Error (nivo 0), dy't printsje allinnich wichtige flaters, en einiget mei Trace (nivo 5) dy't jo sille helpe krekt te witten wat der bart. Mei dizze feroaring hawwe wy it oantal logs fermindere as jo gjin debug-ynformaasje nedich binne by it útfieren fan cert-manager.

Tip: cert-manager rint standert op nivo 2 (Info), kinne jo dit oerskriuwe mei global.logLevel yn Helmchart.

Opmerking: it besjen fan de logs is it lêste resort by it oplossen fan problemen. Foar mear ynformaasje besjoch ús liederskip.

Redaksje n.b.: Om mear te learen oer hoe't it allegear wurket ûnder de motorkap fan Kubernetes, krije weardefolle advys fan praktisearjende leararen, lykas kwaliteitshelp foar technyske stipe, kinne jo meidwaan oan online yntinsives Kubernetes Base, dat wurdt holden 28-30 septimber, en Kubernetes Megadat wurdt holden 14-16 oktober.

ACME Ferbetterings

It meast foarkommende gebrûk fan cert-manager is wierskynlik relatearre oan it útjaan fan sertifikaten fan Let's Encrypt mei ACME. Ferzje 1.0 is opmerklik foar it brûken fan feedback fan 'e mienskip om twa lytse, mar wichtige ferbetteringen ta te foegjen oan ús ACME-útjouwer.

Skeakelje account kaai generaasje

As jo ACME-sertifikaten yn grutte folumes brûke, sille jo wierskynlik itselde akkount brûke op meardere klusters, sadat jo beheiningen foar útjefte fan sertifikaat jilde foar allegear. Dit wie al mooglik yn cert-manager by it kopiearjen fan it geheim spesifisearre yn privateKeySecretRef. Dit gebrûksgefal wie frijwat buggy, om't cert-manager besocht behelpsum te wêzen en lokkich in nije akkountkaai makke as it net ien fûn. Dêrom hawwe wy tafoege disableAccountKeyGenerationom jo te beskermjen tsjin dit gedrach as jo dizze opsje ynstelle true - cert-manager sil gjin kaai generearje en sil jo warskôgje dat it net is foarsjoen fan in akkountkaai.

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

Foarkarske ketting

29 septimber Lit ús fersiferje sil foarby nei jo eigen root CA ISRG Root. Cross-ûndertekene sertifikaten wurde ferfongen troch Identrust. Dizze wiziging fereasket gjin wizigingen oan 'e ynstellings fan 'e cert-manager, alle bywurke of nije sertifikaten dy't nei dizze datum útjûn binne sille de nije root-CA brûke.

Lit ús fersiferje al sertifikaten ûndertekenje mei dizze CA en biedt se as in "alternatyf sertifikaatketen" fia ACME. Yn dizze ferzje fan cert-manager is it mooglik om tagong ta dizze keatlingen yn te stellen yn 'e útjouwerynstellingen. Yn parameter preferredChain jo kinne de namme opjaan fan 'e CA yn gebrûk, wêrmei't it sertifikaat wurdt útjûn. As in CA-sertifikaat dat oerienkomt mei it fersyk beskikber is, sil it jo in sertifikaat útjaan. Tink derom dat dit de foarkarsopsje is, as neat fûn wurdt, sil in standertsertifikaat útjûn wurde. Dit sil derfoar soargje dat jo jo sertifikaat noch sille fernije nei it wiskjen fan de alternative ketting oan 'e ACME-útjouwerkant.

Al hjoed kinne jo ûntfange sertifikaten tekene troch ISRG Root, dus:

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

As jo leaver te ferlitte de keatling IdenTrust - set dizze opsje op 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"

Tink derom dat dizze root CA meikoarten ôfret wurde sil, Let's Encrypt sil dizze ketting aktyf hâlde oant 29 septimber 2021.

Boarne: www.habr.com

cert-manager 1.0 frijlitten