ProHoster > Dienoraštis > Administravimas > Cert-Manager 1.0 išleista

Cert-Manager 1.0 išleista

Paklausus patyrusio, išmintingo inžinieriaus, ką jis mano apie sertifikavimo vadybininką ir kodėl visi juo naudojasi, specialistas atsiduso, konfidencialiai apkabins ir pavargęs pasakys: „Naudoja visi, nes sveikų alternatyvų nėra. Mūsų pelės verkia, dūšia, bet ir toliau gyvena su šiuo kaktusu. Kodėl mes mylime? Nes tai veikia. Kodėl mes nemylime? Nes nuolat išleidžiamos naujos versijos, kuriose naudojamos naujos funkcijos. Ir jūs turite atnaujinti klasterį vėl ir vėl. O senosios versijos nustoja veikti, nes ten yra sąmokslas ir didelis paslaptingas šamanizmas.

Tačiau kūrėjai teigia, kad su Cert-Manager 1.0 viskas pasikeis.

Ar patikėsime?

Cert-Manager 1.0 išleista

Cert-manager yra vietinis Kubernetes sertifikatų valdymo valdiklis. Juo galima išduoti sertifikatus iš įvairių šaltinių: Let's Encrypt, HashiCorp Vault, Venafi, pasirašymo ir savarankiškai pasirašytų raktų porų. Tai taip pat leidžia nuolat atnaujinti raktus ir bandyti automatiškai atnaujinti sertifikatus nurodytu laiku prieš pasibaigiant jų galiojimo laikui. Cert-manager yra pagrįsta kube-lego, taip pat naudojo kai kuriuos metodus iš kitų panašių projektų, tokių kaip kube-cert-manager.

Išleidimo pastabos

1.0 versija rodome pasitikėjimą trejus metus trukusiu sertifikavimo tvarkyklės projekto vystymu. Per šį laiką jis gerokai išaugo funkcionalumo ir stabilumo, bet labiausiai – bendruomenėje. Šiandien matome, kad daugelis žmonių jį naudoja siekdami apsaugoti savo „Kubernetes“ grupes, taip pat diegti įvairiose ekosistemos dalyse. Per pastaruosius 16 leidimų buvo ištaisyta daugybė klaidų. Ir tai, kas turėjo būti sulaužyta, buvo sulaužyta. Keletas apsilankymų API pagerino jos sąveiką su vartotojais. Išsprendėme 1500 253 „GitHub“ problemų, o XNUMX bendruomenės nariai pateikė dar daugiau užklausų.

Išleisdami 1.0 oficialiai pareiškiame, kad sertifikatų tvarkyklė yra brandus projektas. Taip pat pažadame, kad mūsų API bus suderinama v1.

Labai ačiū visiems, padėjusiems sukurti sertifikatų vadybininką visus šiuos trejus metus! Tegul 1.0 versija bus pirmoji iš daugelio puikių dalykų.

1.0 leidimas yra stabilus leidimas su keliomis prioritetinėmis sritimis:

  • v1 API;

  • Komanda kubectl cert-manager status, padėti analizuoti problemas;

  • Naudojant naujausias stabilias Kubernetes API;

  • Patobulintas medienos ruoša;

  • ACME patobulinimai.

Prieš atnaujindami būtinai perskaitykite atnaujinimo pastabas.

API v1

0.16 versija veikė su API v1beta1. Tai papildė keletą struktūrinių pakeitimų ir patobulino API lauko dokumentaciją. 1.0 versija pagrįsta visa tai naudojant API v1. Ši API yra mūsų pirmoji stabili, tuo pat metu jau suteikėme suderinamumo garantijas, bet su API v1 Pažadame išlaikyti suderinamumą daugelį metų.

Atlikti pakeitimai (pastaba: mūsų konvertavimo įrankiai viskuo pasirūpins už jus):

Sertifikatas:

  • emailSANs dabar vadinamas emailAddresses

  • uriSANs - uris

Šie pakeitimai papildo suderinamumą su kitais SAN (subject alt pavadinimai, apytiksliai vertėjas), taip pat su Go API. Pašaliname šį terminą iš savo API.

Atnaujinti

Jei naudojate Kubernetes 1.16 naujesnę versiją, žiniatinklio kabliukų konvertavimas leis vienu metu ir sklandžiai dirbti su API versijomis v1alpha2, v1alpha3, v1beta1 и v1. Su jais galite naudoti naują API versiją nekeisdami ir neperskirstydami senų išteklių. Primygtinai rekomenduojame atnaujinti aprašus į API v1, nes ankstesnės versijos netrukus bus nebenaudojamos. Vartotojai legacy Cert-Manager versijos vis tiek turės prieigą tik prie v1, galima rasti atnaujinimo veiksmus čia.

kubectl cert-manager būsenos komanda

Su naujais mūsų plėtinio patobulinimais kubectl Su sertifikatų neišdavimu susijusias problemas tirti tapo lengviau. kubectl cert-manager status dabar suteikia daug daugiau informacijos apie tai, kas vyksta su sertifikatais, taip pat parodo, kokiame etape pažymėjimas išduodamas.

Įdiegę plėtinį galite paleisti kubectl cert-manager status certificate <имя-сертификата>, kuri ieškos sertifikato su nurodytu pavadinimu ir visais susijusiais ištekliais, pvz., CertificateRequest, Secret, Issuer ir Order and Challenges, jei sertifikatai iš ACME.

Dar neparengto sertifikato derinimo pavyzdys:

$ 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

Komanda taip pat gali padėti jums sužinoti daugiau apie sertifikato turinį. Letsencrypt išduoto sertifikato pavyzdys:

$ 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
[...]

Pasinaudokite naujausiomis stabiliomis Kubernetes API

Cert-manager buvo vienas iš pirmųjų, įdiegusių Kubernetes CRD. Tai kartu su mūsų palaikymu Kubernetes versijoms iki 1.11 reiškė, kad turime palaikyti seną apiextensions.k8s.io/v1beta1 mūsų CRD taip pat admissionregistration.k8s.io/v1beta1 mūsų internetiniams kabliukams. Dabar jie nebenaudojami ir bus pašalinti iš Kubernetes nuo 1.22 versijos. Su savo 1.0 dabar siūlome visapusišką palaikymą apiextensions.k8s.io/v1 и admissionregistration.k8s.io/v1 Kubernetes 1.16 (kur jie buvo pridėti) ir vėliau. Ankstesnių versijų naudotojams ir toliau siūlome palaikymą v1beta1 mūsų legacy versijos.

Patobulintas kirtimas

Šioje versijoje atnaujinome registravimo biblioteką į klog/v2, naudojamas Kubernetes 1.19. Taip pat peržiūrime kiekvieną žurnalą, kurį rašome, kad įsitikintume, jog jam priskirtas tinkamas lygis. Tuo ir vadovavomės Kubernetes nurodymas. Yra penki (iš tikrųjų - šeši, apytiksliai vertėjas) registravimo lygiai pradedant nuo Error (0 lygis), kuris spausdina tik svarbias klaidas ir baigiasi Trace (5 lygis), kuris padės tiksliai sužinoti, kas vyksta. Atlikę šį pakeitimą sumažinome žurnalų skaičių, jei jums nereikia derinimo informacijos paleidžiant sertifikatų tvarkyklę.

Patarimas: pagal numatytuosius nustatymus sertifikatų tvarkyklė veikia 2 lygiu (Info), galite tai nepaisyti naudodami global.logLevel vairo diagramoje.

Pastaba: žurnalų peržiūra yra paskutinė išeitis šalinant triktis. Norėdami gauti daugiau informacijos, apsilankykite mūsų vadovavimas.

Redaktoriaus n.b.: Norėdami sužinoti daugiau apie tai, kaip visa tai veikia po Kubernetes gaubtu, gauti vertingų patarimų iš praktikuojančių mokytojų, taip pat gauti aukštos kokybės techninę pagalbą, galite dalyvauti intensyviuose internetiniuose kursuose. Kubernetes bazė, kuris vyks rugsėjo 28-30 d., ir Kubernetes Mega, kuris vyks spalio 14–16 d.

ACME patobulinimai

Dažniausias sertifikatų tvarkyklės naudojimas tikriausiai yra susijęs su sertifikatų išdavimu iš Let's Encrypt naudojant ACME. 1.0 versija pasižymi bendruomenės atsiliepimais, kad pridėtų du nedidelius, bet svarbius mūsų ACME leidėjo patobulinimus.

Išjungti paskyros raktų generavimą

Jei naudojate didelius kiekius ACME sertifikatų, greičiausiai naudojate tą pačią paskyrą keliose grupėse, todėl sertifikatų išdavimo apribojimai bus taikomi jiems visiems. Tai jau buvo įmanoma sertifikatų tvarkyklėje, kai nukopijuojate nurodytą paslaptį privateKeySecretRef. Šis naudojimo atvejis buvo gana klaidingas, nes sertifikato tvarkytojas stengėsi būti naudingas ir mielai sukūrė naują paskyros raktą, jei jo nerado. Štai kodėl mes pridėjome disableAccountKeyGenerationkad apsaugotumėte jus nuo tokio elgesio, nustatydami šią parinktį true - Cert-manager nesukurs rakto ir įspės, kad jam nebuvo suteiktas paskyros raktas.

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

Pageidautina grandinė

Rugsėjo 29 d. Šifruokime pajudės savo šakninio sertifikato institucijai ISRG Root. Kryžmiškai pasirašyti sertifikatai bus pakeisti į Identrust. Šis pakeitimas nereikalauja keisti sertifikatų tvarkyklės nustatymų; visuose atnaujintuose arba naujuose sertifikatuose, išduotuose po šios datos, bus naudojama nauja šakninė CA.

Let's Encrypt jau pasirašo sertifikatus su šia CA ir siūlo juos kaip „alternatyvią sertifikatų grandinę“ per ACME. Ši sertifikatų tvarkyklės versija turi galimybę nustatyti prieigą prie šių grandinių išdavėjo nustatymuose. Parametre preferredChain Galite nurodyti sertifikatui išduoti naudotos CA pavadinimą. Jei yra CA sertifikatas, atitinkantis užklausą, jis jums išduos sertifikatą. Atminkite, kad tai yra pageidaujama parinktis; jei nieko nerasta, bus išduotas numatytasis sertifikatas. Tai užtikrins, kad vis tiek atnaujinsite sertifikatą, kai ištrinsite alternatyvią grandinę ACME išdavėjo pusėje.

Šiandien galite gauti pasirašytus sertifikatus ISRG Root, Taigi:

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

Jei norite palikti grandinę IdenTrust — nustatykite šį parametrą į 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"

Atminkite, kad ši šakninė CA netrukus bus nebenaudojama, o „Let's Encrypt“ išlaikys šią grandinę aktyvią iki 29 m. rugsėjo 2021 d.

Šaltinis: www.habr.com