ProHoster > Blog > Uprava > izdan cert-manager 1.0

izdan cert-manager 1.0

Če vprašate izkušenega, modrega inženirja, kaj si misli o cert-managerju in zakaj ga vsi uporabljajo, potem bo strokovnjak zavzdihnil, ga zaupno objel in naveličano dejal: »Vsi ga uporabljajo, ker ni nobene pametne alternative. Naše miši jokajo, pikajo, a še naprej živijo s tem kaktusom. Zakaj ljubimo? Ker deluje. Zakaj se ne ljubimo? Ker nenehno prihajajo nove različice, ki uporabljajo nove funkcije. In gručo morate znova in znova posodabljati. In stare različice prenehajo delovati, ker obstaja zarota in velik skrivnostni šamanizem.

Toda razvijalci trdijo, da cert-manager 1.0 vse se bo spremenilo.

Bomo verjeli?

izdan cert-manager 1.0

Cert-manager je izvorni krmilnik upravljanja potrdil Kubernetes. Uporablja se lahko za izdajanje potrdil iz različnih virov: Let's Encrypt, HashiCorp Vault, Venafi, podpisovanje in samopodpisani pari ključev. Omogoča vam tudi, da ključe posodabljate glede na čas poteka, poleg tega pa poskuša samodejno obnoviti potrdila ob določenem času, preden potečejo. Cert-manager temelji na kube-lego in je uporabil tudi nekaj trikov iz drugih podobnih projektov, kot je kube-cert-manager.

Opombe ob izdaji

Z verzijo 1.0 smo postavili znak zaupanja za tri leta razvoja projekta cert-manager. V tem času se je močno razvil v funkcionalnosti in stabilnosti, predvsem pa v skupnosti. Danes vidimo, da ga veliko ljudi uporablja za zavarovanje svojih gruč Kubernetes in za uvajanje v različne dele ekosistema. V zadnjih 16 izdajah je bilo odpravljenih veliko napak. In kar je bilo treba zlomiti, se je zlomilo. Več obiskov pri delu z API-jem je izboljšalo njegovo interakcijo z uporabniki. Razrešili smo 1500 težav na GitHubu z več zahtevami za vleko od 253 članov skupnosti.

Z izdajo 1.0 uradno izjavljamo, da je cert-manager zrel projekt. Obljubljamo tudi, da bomo ohranili združljivost našega API-ja v1.

Najlepša hvala vsem, ki ste nam vsa ta tri leta pomagali izdelovati cert-managerja! Naj bo različica 1.0 prva od mnogih velikih stvari, ki prihajajo.

Izdaja 1.0 je stabilna izdaja z več prednostnimi področji:

  • v1 API;

  • Ekipa kubectl cert-manager status, za pomoč pri analizi problema;

  • Uporaba najnovejših stabilnih API-jev Kubernetes;

  • Izboljšano beleženje;

  • Izboljšave ACME.

Pred nadgradnjo obvezno preberite opombe o nadgradnji.

API v1

Različica v0.16 je delovala z API-jem v1beta1. To je dodalo nekaj strukturnih sprememb in tudi izboljšalo dokumentacijo polja API. Različica 1.0 gradi na tem z API-jem v1. Ta API je naš prvi stabilen, hkrati pa smo že dali jamstva za združljivost, vendar z API-jem v1 obljubljamo, da bomo ohranili združljivost v prihodnjih letih.

Izvedene spremembe (opomba: naša orodja za pretvorbo poskrbijo za vse namesto vas):

potrdilo:

  • emailSANs zdaj poklican emailAddresses

  • uriSANs - uris

Te spremembe dodajo združljivost z drugimi SAN-ji (nadomestna imena subjektov, pribl. prevajalec), kot tudi z Go API. Ta izraz bomo odstranili iz našega API-ja.

Posodobiti

Če uporabljate Kubernetes 1.16+, vam bo pretvorba webhookov omogočila sočasno in nemoteno delo z različicami API-ja v1alpha2, v1alpha3, v1beta1 и v1. S temi boste lahko uporabljali novo različico API-ja, ne da bi spremenili ali prerazporedili stare vire. Zelo priporočamo, da svoje manifeste nadgradite na API v1, saj bodo prejšnje različice kmalu opuščene. Uporabniki legacy različice programa cert-manager bodo še vedno imele dostop samo do v1, najdete korake nadgradnje tukaj.

ukaz kubectl cert-manager status

Z novimi izboljšavami v naši razširitvi za kubectl postalo je lažje preiskovati probleme, povezane z neizdajanjem certifikatov. kubectl cert-manager status zdaj ponuja veliko več informacij o tem, kaj se dogaja s certifikati, in prikazuje tudi stopnjo izdaje certifikata.

Po namestitvi razširitve lahko zaženete kubectl cert-manager status certificate <имя-сертификата>, ki bo poiskal potrdilo z danim imenom in vse povezane vire, kot so CertificateRequest, Secret, Issuer ter Order and Challenges, če uporabljate potrdila ACME.

Primer odpravljanja napak v potrdilu, ki še ni pripravljeno:

$ 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

Ukaz vam lahko tudi pomaga izvedeti več o vsebini potrdila. Podroben primer potrdila, ki ga izda 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
[...]

Uporaba najnovejših stabilnih API-jev Kubernetes

Cert-manager je bil eden prvih, ki je implementiral Kubernetes CRD. To in naša podpora za različice Kubernetes do 1.11 je pomenilo, da moramo podpreti zapuščino apiextensions.k8s.io/v1beta1 tudi za naše CRD admissionregistration.k8s.io/v1beta1 za naše webhooke. Zdaj so zastareli in bodo odstranjeni v Kubernetesu od različice 1.22. Z našim 1.0 zdaj nudimo popolno podporo apiextensions.k8s.io/v1 и admissionregistration.k8s.io/v1 za Kubernetes 1.16 (kamor so bili dodani) in novejše. Za uporabnike prejšnjih različic še naprej nudimo podporo v1beta1 v našem legacy različice.

Izboljšano beleženje

V tej izdaji smo knjižnico beleženja posodobili na klog/v2, ki se uporablja v Kubernetes 1.19. Prav tako pregledamo vsako revijo, ki jo pišemo, da se prepričamo, da ji je dodeljena ustrezna raven. To nas je vodilo navodila Kubernetesa. Pet jih je (pravzaprav šest, pribl. prevajalec) ravni beleženja od Error (raven 0), ki izpiše samo pomembne napake in se konča z Trace (raven 5), ki vam bo pomagal natančno vedeti, kaj se dogaja. S to spremembo smo zmanjšali število dnevnikov, če ne potrebujete informacij o odpravljanju napak, ko izvajate cert-manager.

Namig: cert-manager se privzeto izvaja na ravni 2 (Info), lahko to preglasite z global.logLevel v Helmchartu.

Opomba: ogled dnevnikov je zadnja možnost pri odpravljanju težav. Za več informacij si oglejte našo vodstvo.

Opomba urednika: Če želite izvedeti več o tem, kako vse deluje pod pokrovom Kubernetesa, pridobiti dragocene nasvete učiteljev v praksi in kakovostno tehnično pomoč, se lahko udeležite spletnih intenzivov. Baza Kubernetes, ki bo potekal od 28. do 30. septembra, in Kubernetes Megaki bo od 14. do 16. oktobra.

Izboljšave ACME

Najpogostejša uporaba cert-managerja je verjetno povezana z izdajanjem potrdil Let's Encrypt z uporabo ACME. Različica 1.0 je znana po uporabi povratnih informacij skupnosti za dodajanje dveh majhnih, a pomembnih izboljšav našemu izdajatelju ACME.

Onemogoči ustvarjanje ključa računa

Če uporabljate potrdila ACME v velikih količinah, boste verjetno uporabljali isti račun v več gručih, zato bodo vaše omejitve izdajanja potrdil veljale za vse. To je bilo že mogoče v cert-managerju pri kopiranju skrivnosti, navedene v privateKeySecretRef. Ta primer uporabe je bil precej hrošč, saj je cert-manager poskušal pomagati in z veseljem ustvaril nov ključ računa, če ga ni našel. Zato smo dodali disableAccountKeyGenerationda vas zaščiti pred tem vedenjem, če to možnost nastavite na true - cert-manager ne bo ustvaril ključa in vas bo opozoril, da ni prejel ključa računa.

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

Prednostna veriga

29. september Let's Encrypt bo minilo v svoj korenski CA ISRG Root. Navzkrižno podpisana potrdila bodo zamenjana z Identrust. Ta sprememba ne zahteva sprememb nastavitev upravitelja potrdil, vsa posodobljena ali nova potrdila, izdana po tem datumu, bodo uporabljala novo korensko CA.

Let's Encrypt že podpisuje potrdila s tem CA in jih ponuja kot "nadomestno verigo potrdil" prek ACME. V tej različici cert-managerja je možno nastaviti dostop do teh verig v nastavitvah izdajatelja. V parametru preferredChain lahko določite ime CA v uporabi, s katerim bo izdano potrdilo. Če je na voljo potrdilo CA, ki ustreza zahtevi, vam bo izdalo potrdilo. Upoštevajte, da je to prednostna možnost, če ne najdete ničesar, bo izdano privzeto potrdilo. To bo zagotovilo, da boste še vedno obnovili svoje potrdilo po izbrisu nadomestne verige na strani izdajatelja ACME.

Že danes lahko prejmete potrdila s podpisom ISRG Root, torej:

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

Če raje zapustite verigo IdenTrust - nastavite to 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"

Upoštevajte, da bo ta korenski CA kmalu opuščen, Let's Encrypt bo to verigo ohranil aktivno do 29. septembra 2021.

Vir: www.habr.com

Dodaj komentar