🥇Izdan je bil upravitelj certifikatov 1.0

Če vprašate izkušenega, modrega inženirja, kaj si misli o Cert-Managerju in zakaj ga vsi uporabljajo, bo zavzdihnil, vas zaupno objel in utrujeno rekel: "Vsi ga uporabljajo, ker ni razumnih alternativ. Naše miši jokajo, se pičijo, a še naprej živijo s tem kaktusom. Zakaj ga imamo radi? Ker deluje. Zakaj nam ni všeč? Ker nenehno izhajajo nove različice, ki vključujejo nove funkcije. In gručo morate vedno znova posodabljati. In stare različice prenehajo delovati, ker obstaja zarota in velik, skrivnostni šamanizem."

Toda razvijalci zagotavljajo, da z upravitelj certifikatov 1.0 vse se bo spremenilo.

Bomo verjeli?

Cert-manager je izvorni krmilnik za upravljanje potrdil Kubernetes. Izdaja lahko potrdila iz različnih virov, vključno z Let's Encrypt, HashiCorp Vault, Venafi, ter pare ključev za podpisovanje in samopodpisovanje. Prav tako posodablja ključe z obdobji veljavnosti in poskuša samodejno obnoviti potrdila ob določenih časih, preden potečejo. Cert-manager temelji na kube-lego in si izposoja tudi nekatere tehnike iz drugih podobnih projektov, kot je kube-cert-manager.

Opombe ob izdaji

Z različico 1.0 praznujemo tri leta razvoja projekta cert-manager. V tem času je znatno zrasel v funkcionalnosti in stabilnosti, predvsem pa v skupnosti. Danes vidimo veliko ljudi, ki ga uporabljajo za zaščito svojih gruč Kubernetes in ga implementirajo v različne dele ekosistema. V zadnjih 16 izdajah je bilo odpravljenih veliko napak. In kar je bilo treba pokvariti, je bilo pokvarjeno. Več krogov dela na API-ju je izboljšalo uporabniško izkušnjo. Na GitHubu smo odpravili 1500 težav, s še več zahtevami za prevzem (pull requests) od 253 članov skupnosti.

Z izdajo različice 1.0 uradno razglašamo cert-manager za zrel projekt. Obljubljamo tudi, da bomo ohranili združljivost z našim API-jem. v1.

Velika zahvala vsem, ki ste nam v zadnjih treh letih pomagali pri razvoju Cert-Managerja! Naj bo različica 1.0 prvi od mnogih velikih dosežkov, ki prihajajo.

Izdaja 1.0 je stabilna izdaja z več področji osredotočanja:

v1 API;
Ekipa kubectl cert-manager status, za pomoč pri analizi težav;
Uporaba najnovejših stabilnih Kubernetes API-jev;
Izboljšano beleženje;
Izboljšave ACME.

Pred posodobitvijo preberite opombe k posodobitvi.

API v1

Različica v0.16 je delovala z API-jem v1beta1To je dodalo nekaj strukturnih sprememb in izboljšalo tudi dokumentacijo polj API. Različica 1.0 gradi na tem z API-jem. v1Ta API je naš prvi stabilen, čeprav smo že zagotovili jamstva za združljivost, vendar z API-jem v1 Obljubljamo, da bomo združljivost ohranili še vrsto let.

Spremembe (opomba: naša orodja za pretvorbo bodo poskrbela za vse namesto vas):

potrdilo:

emailSANs zdaj se imenuje emailAddresses
uriSANs - uris

Te spremembe dodajajo združljivost z drugimi omrežji SAN (alternativna imena subjektov, pribl. prevajalec), kot tudi z Go API-jem. Ta izraz odstranjujemo iz našega API-ja.

Posodobiti

Če uporabljate Kubernetes 1.16+, vam bo pretvorba spletnih kavljarjev omogočila nemoteno delo z različicami API-ja hkrati. v1alpha2, v1alpha3, v1beta1 и v1S temi lahko uporabljate novo različico API-ja, ne da bi morali spreminjati ali ponovno nameščati stare vire. Toplo priporočamo, da posodobite manifeste API-ja. v1, saj bodo prejšnje različice kmalu zastarele. Uporabniki legacy Različice programa cert-manager bodo še vedno imele dostop samo do v1, korake za posodobitev najdete tukaj.

Ukaz za status upravitelja certifikatov kubectl

Z novimi izboljšavami v naši razširitvi kubectl Preiskovanje težav, povezanih z neizdajo potrdil, je postalo lažje. kubectl cert-manager status zdaj ponuja veliko več informacij o tem, kaj se dogaja s certifikati, in prikazuje tudi fazo izdaje certifikata.

Po namestitvi razširitve lahko zaženete kubectl cert-manager status certificate <имя-сертификата>, ki bo poiskal potrdilo z navedenim imenom in vsemi povezanimi viri, kot so CertificateRequest, Secret, Issuer ter Order and Challenges v primeru potrdil 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 pomaga tudi izvedeti več o vsebini potrdila. Tukaj je primer podrobnosti za potrdilo, ki ga je izdal 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 Kubernetes API-jev

Cert-manager je bil eden prvih, ki je implementiral CRD-je Kubernetes. To je skupaj z našo podporo za različice Kubernetes do 1.11 pomenilo, da smo morali podpirati zastarelo različico. apiextensions.k8s.io/v1beta1 tudi za naše CRD-je admissionregistration.k8s.io/v1beta1 za naše spletne kavlje. Zdaj so zastareli in bodo v Kubernetes odstranjeni od različice 1.22 naprej. Z našo različico 1.0 zdaj ponujamo polno podporo. apiextensions.k8s.io/v1 и admissionregistration.k8s.io/v1 za Kubernetes 1.16 (kjer so bili dodani) in novejše. Še naprej nudimo podporo uporabnikom prejšnjih različic. v1beta1 v našem legacy različice.

Izboljšano beleženje

V tej različici smo posodobili knjižnico beleženja klog/v2, uporabljen v Kubernetes 1.19. Pregledamo tudi vsak dnevnik, ki ga napišemo, da mu dodelimo ustrezno raven. Uporabili smo navodila KubernetesaObstaja pet (pravzaprav šest, pribl. prevajalec) ravni sečnje, začenši z Error (raven 0), ki izpiše le pomembne napake in se konča z Trace (raven 5), ki vam bo pomagala ugotoviti, kaj se dogaja. S to spremembo smo zmanjšali količino dnevnikov, če pri izvajanju cert-managerja ne potrebujete informacij za odpravljanje napak.

Nasvet: Privzeto se upravitelj certifikatov izvaja na 2. ravni (Info), to lahko preglasite z uporabo global.logLevel v Helmovi karti.

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, dobiti dragocene nasvete izkušenih inštruktorjev in prejeti visokokakovostno tehnično podporo, se lahko udeležite intenzivnih spletnih tečajev. Baza Kubernetes, ki bo potekal od 28. do 30. septembra, in Kubernetes Mega, ki bo potekal od 14. do 16. oktobra.

Izboljšave ACME

Najpogostejša uporaba upravitelja certifikatov je verjetno izdajanje potrdil Let's Encrypt z uporabo ACME. Različica 1.0 je znana po tem, da je v dve majhni, a pomembni izboljšavi našega izdajatelja ACME vključila povratne informacije skupnosti.

Onemogočanje ustvarjanja ključev računa

Če uporabljate potrdila ACME v velikih količinah, boste verjetno uporabljali isti račun v več gručah, zato bodo omejitve izdaje potrdil veljale za vse. To je bilo v upravitelju certifikatov že mogoče s kopiranjem skrivnosti, navedene v privateKeySecretRefTa primer uporabe je bil precej hroščev, saj je cert-manager poskušal biti v pomoč in je z veseljem ustvaril nov ključ računa, če ga ni mogel najti. Zato smo dodali disableAccountKeyGenerationDa bi vas zaščitili pred tem vedenjem, če to možnost nastavite na true — cert-manager ne bo ustvaril ključa in vas bo opozoril, da mu ni bil dostavljen ključ 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 Šifrirajmo bo šel naprej svojemu korenskemu overitelju potrdil ISRG RootPotrdila z navzkrižnimi podpisi bodo zamenjana z IdentrustTa sprememba ne zahteva nobenih sprememb nastavitev upravitelja potrdil; vsa obnovljena ali nova potrdila, izdana po tem datumu, bodo uporabljala novi korenski overitelj potrdil.

Let's Encrypt že podpisuje potrdila s tem overiteljem potrdil in jih ponuja kot "alternativno verigo potrdil" prek ACME. Ta različica upravitelja certifikatov vam omogoča, da v nastavitvah izdajatelja določite dostop do teh verig. V parametru preferredChain Določite lahko ime overitelja potrdil (CA), ki bo izdal potrdilo. Če je na voljo potrdilo CA, ki ustreza vaši zahtevi, ga bo izdal. Upoštevajte, da je to prednostna možnost; če ni najdeno nič, bo izdano privzeto potrdilo. To zagotavlja, da lahko potrdilo še vedno obnovite po brisanju nadomestne verige pri izdajatelju ACME.

Podpisana potrdila lahko prejmete že danes 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 ta parameter 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 zastarel, Let's Encrypt pa bo to verigo ohranil aktivno do 29. septembra 2021.

Vir: www.habr.com