Ilmus cert-manager 1.0

Kui küsida kogenud mitme nutikuse insenerilt, mida ta arvab cert-managerist ja miks kõik seda kasutavad, siis spetsialist ohkab, embab usalduslikult ja väsinult ütleb: „Kõik kasutavad seda, kuna ei ole normaalset alternatiivi. Meie hiired nutavad, torkavad, kuid elavad selle kaktuse jaoks edasi. Miks armastame? Sest see töötab. Miks ei armasta? Sest pidevalt ilmuvad uued versioonid, mis kasutavad uusi funktsioone. Ja tuleb korduvalt klastrit uuendada. Aga vanad versioonid lõpetavad töö, sest seal on complot ja suur salapärane šamaanitöö.”

Aga arendajad kinnitavad, et cert-manager 1.0 kõik muutub.

Kas usume?

Cert-manager on Kubernetes'e „kodune” sertifikaatide haldamise kontroller. Selle abil saab välja anda sertifikaate erinevatest allikatest: Let’s Encrypt, HashiCorp Vault, Venafi, allkirjastamiseks mõeldud võtmete paare ja isesertifitseeritud. See võimaldab ka hoida võtmed kehtivad, samuti püüab automaatselt sertifikaate uuendada määratud kehtivusaja enne. Cert-manager põhineb kube-legol ja on kasutanud mõningaid tehnikaid teistest sarnastest projektidest, näiteks kube-cert-managerist.

Väljaande märkused

Versiooniga 1.0 kinnitame usaldust kolme aasta jooksul, mil cert-manager projekti arendati. Selle aja jooksul on see märgatavalt arenenud funktsionaalsuse ja stabiilsuse osas, kuid kõige rohkem — kogukonna poolelt. Tänasel päeval näeme, et paljud inimesed kasutavad seda oma Kubernetes klastrite kaitsmiseks ning rakendavad seda erinevates ökosüsteemi osades. Viimastes 16 väljaandes on parandatud hulgaliselt vigu. Ja kõik, mis pidi katki minema — on katki läinud. Toimingud API-ga on parandanud selle kasutajatega suhtlemist. Oleme lahendanud 1500 probleemi GitHubis koos veelgi enamate ühendamise taotlustega 253 kogukonna liikmelt.

Välja andes versiooni 1.0 kinnitame ametlikult, et cert-manager on küps projekt. Lubame samuti toetada meie API ühilduvust. v1.

Suur tänu kõikidele, kes meid on aidanud cert-manageri arendamisel kõik need kolm aastat! Olgu versioon 1.0 esimene paljude tulevaste suurtööde seas.

Väljaanne 1.0 on stabiilne väljaanne, millel on mõned prioriteetsed suunad:

• v1 API;

• Meeskond kubectl cert-manager state, et aidata probleemide analüüsimisel;

• Kubernetesi uusimate stabiilsete API-de kasutamine;

• Parandatud logimine;

• Parandused ACME.

Enne uuenduse tegemist lugege kindlasti uuenduste märkuseid.

API v1

Versioon v0.16 töötas API-ga v1beta1. See tõi kaasa mõned struktuursed muudatused ning parandas API väljade dokumentatsiooni. Versioon 1.0 tugineb sellele kõigile API kaudu v1. See API on meie esimene stabiilne versioon, samas oleme juba taganud ühilduvuse, kuid API-ga v1 lubame säilitada ühilduvust aastate jooksul.

Tehtud muudatused (märkused: meie konverteerimisvahendid hoolitsevad kõikide teie eest):

Sertifikaat:

• emailSANs nüüd nimetatakse emailAddresses

• uriSANs — uris

Need muudatused lisavad ühilduvuse teiste SAN-ide (subject alt names, tõlkija märk.), samuti Go API-ga. Eemaldame selle termini meie API-st.

Uuendamine

Kui kasutate Kubernetes 1.16+ — konverteerivad webhookid võimaldavad teil samal ajal ja sujuvalt töötada API versioonidega v1alpha2, v1alpha3, v1beta1 ja v1. Nende abil saate kasutada uut API versiooni, ilma et peaksite muutma või uuesti juurutama oma vanu ressursse. Soovitame tungivalt oma manifestide uuendamist API-le v1, kuna varasemad versioonid kuulutatakse peagi välja vananenuks. Kasutajad legacy cert-manager versiooniga on endiselt ligipääs ainult v1, uuendamise sammud leiate siit.

Meeskond kubectl cert-manager status

Uute täiustustega meie laienduses kubectl on lihtsam uurida probleeme, mis on seotud sertifikaatide väljaandmisega. kubectl cert-manager state nüüd annab palju rohkem teavet selle kohta, mis sertifikaatidega toimub, samuti näitab sertifikaadi väljaandmise etappe.

Pärast laienduse installimist saate käivitada kubectl cert-manager status certificate, mis otsib määratletud nimega sertifikaati ja kõiki seotud ressursse, näiteks CertificateRequest, Secret, Issuer, samuti Order ja Challenges, kui kasutatakse ACME sertifikaate.

Kliendi sertifikaadi silumise näide:

$ kubectl cert-manager status certificate acme-certificate

Nimi: acme-certificate
Nimekiri: default
Loetud: 2020-08-21T16:44:13+02:00
Olukorrad:
  Valmis: Vale, Põhjus: EiEksisteeri, Teade: Sertifikaadi andmine kui Saladus ei eksisteeri
  Andmine: Tõsi, Põhjus: EiEksisteeri, Teade: Sertifikaadi andmine kui Saladus ei eksisteeri
DNS Nimed:
- example.com
Sündmused:
  Tüüp    Põhjus      Vanus  Allikas       Teade
  ----    ------      ----  ----          -------
  Normaalne  Andmine    18m   cert-manager  Sertifikaadi andmine kui Saladus ei eksisteeri
  Normaalne  Genereeritud  18m   cert-manager  Uus privaatvõti salvestati ajutisse Salajasse ressursse "acme-certificate-tr8b2"
  Normaalne  Taotletud  18m   cert-manager  Uus CertificateRequest ressursse "acme-certificate-qp5dm" loodi
Andja:
  Nimi: acme-issuer
  Tüüp: Andja
  Olukorrad:
    Valmis: Tõsi, Põhjus: ACMEAccountRegistered, Teade: ACME konto registreeriti ACME serveris
viga Salajase leidmisel "acme-tls": saladused "acme-tls" ei leitud
Mitte Enne: 
Mitte Pärast: 
Uuendamise Aeg: 
CertificateRequest:
  Nimi: acme-certificate-qp5dm
  Nimekiri: default
  Olukorrad:
    Valmis: Vale, Põhjus: Ootel, Teade: Ootamine sertifikaadi andmise järele tellimusest default/acme-certificate-qp5dm-1319513028: "ootel"
  Sündmused:
    Tüüp    Põhjus        Vanus  Allikas       Teade
    ----    ------        ----  ----          -------
    Normaalne  TellimusLoodud  18m   cert-manager  Tellimuse ressursse default/acme-certificate-qp5dm-1319513028 loodi
Tellimus:
  Nimi: acme-certificate-qp5dm-1319513028
  Oleku: ootel, Põhjus:
  Volitused:
    URL: https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/97777571, Identifikaator: example.com, Algne Oleku: ootel, Wildcard: vale
Väljakutsed:
- Nimi: acme-certificate-qp5dm-1319513028-1825664779, Tüüp: DNS-01, Token: J-lOZ39yNDQLZTtP_ZyrYojDqjutMAJOxCL1AkOEZWw, Võti: U_W3gGV2KWgIUonlO2me3rvvEOTrfTb-L5s0V1TJMCw, Oleku: ootel, Põhjus: viga clouddns teenuse konto saamisel: saladus "clouddns-accoun" ei leitud, Töötlemine: tõsi, Esitletud: vale

Meeskond aitab ka sertifikaadi sisu kohta rohkem teavet saada. Sertifikaadi, mille on välja andnud Letsencrypt, detailide näide:

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

Kubernetesi uusimate stabiilsete API-de kasutamine

Cert-manager oli üks esimesi, kes rakendas Kubernetes CRD-sid. See, samuti meie toetus Kubernetesi versioonidele kuni 1.11, tähendas, et pidime toetama aegunud apiextensions.k8s.io/v1beta1 meie CRD-de jaoks, samuti admissionregistration.k8s.io/v1beta1 meie webhookide jaoks. Nüüd on need aegunud ja neid eemaldatakse Kubernetesis alates versioonist 1.22. Meie 1.0 versiooniga pakume nüüd täielikku toetamist apiextensions.k8s.io/v1 ja admissionregistration.k8s.io/v1 Kubernetes 1.16 jaoks (kus need lisati) ja uuematele. Eelmiste versioonide kasutajatele pakume jätkuvalt tuge v1beta1 meie legacy versioonis.

Parandatud logimine

Selles versioonis oleme ajakohastanud logimise teeki klog/v2, mida kasutatakse Kubernetes 1.19-s. Samuti kontrollime iga logi, mille kirjutame, et määrata sellele sobiv tase. Selleks juhindusime Kubernetes'i juhistest. Logimise tasemeid on kokku viis (tõeliselt kuus, tõlkija märk.), alates Error (tase 0), mis kuvab ainult olulised vead, kuni Trace (tase 5), mis aitab täpselt teada, mis toimub. Selle muudatusega vähendasime logide arvu, kui te ei vaja silumisinfot cert-manageri töö käigus.

Soovitus: vaikimisi töötab cert-manager tasemel 2 (Info), saate seda üle kirjutada, kasutades global.logLevel Helm chart'is.

Märkus: logide vaatamine on viimane abinõu tõrgete tõrkeotsingul. Suurema teabe saamiseks tutvuge meiega juhendiga.

N.B. toimetaja: Et rohkem teada saada, kuidas see Kubernetes'e tagaküljel töötab, saada väärtuslikke näpunäiteid praktik õpetajatelt ja kvaliteetset tehnilist abi, saavad osaleda veebis intensivis Kubernetes Baas, mis toimub 28.-30. septembril, ja Kubernetes Mega, mis toimub 14.-16. oktoobril.

ACME parandused

Cert-manager'i kõige levinum kasutus on seotud Let's Encrypt'i sertifikaatide väljastamisega ACME protokolli abil. Versioon 1.0 on tuntud selle poolest, et see kasutas kogukonna tagasisidet kahte väikest, kuid olulist täiustust meie ACME emissari jaoks.

Konto võtme loomise keelamine

Kui kasutate ACME sertifikaate suurtes mahudes, kasutate tõenäoliselt sama kontot mitmel klastril, mistõttu kehtivad teie sertifikaatide väljastamise piirangud kõikidele neile. See oli juba võimalik cert-manager'i abil, kui kopeerida antud saladust, privateKeySecretRef. Selline kasutusviis oli piisavalt probleemne, sest cert-manager üritas olla abiks ja rõõmsasti lõi uue konto võtme, kui eelnevalt antud ei leitud. Seetõttu lisasime disableAccountKeyGeneration, et kaitsta teid sellise käitumise eest, kui seate selle parameetri true — cert-manager ei loo võtit ja teavitab teid, et konto võti ei ole antud.

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

Eelistatud ahel

29. september Let's Encrypt üleminekut oma juurkeskusesse sertifitseerimisel ISRG juurkeskus. Ristpindadega sertifikaadid asendatakse Identrust. See muudatus ei nõua muudatusi cert-manageri seadetes; kõik uuendatud või uued sertifikaadid, mis pärast seda kuupäeva väljastatakse, kasutavad uut juurkeskust CA.

Let’s Encrypt juba allkirjastab sertifikaate selle CA-ga ja pakub neid «alternatiivse sertifikaadiseina» kaudu ACME. Selles cert-manageri versioonis on võimalus määrata pääsu nendele ahelatele issueri seadetes. Parameetris preferredChain võib määrata CA nime, mille kaudu sertifikaat väljastatakse. Kui on saadaval CA sertifikaat, mis vastab taotlusele, väljastab see teile sertifikaadi. Pange tähele, et see on eelistatud variant, kui midagi ei leita — väljastatakse vaikimisi sertifikaat. See tagab, et te siiski uuendate oma sertifikaati pärast alternatiivse ahela eemaldamist ACME issueri küljelt.

Juba täna on võimalik saada sertifikaate, mida allkirjastab ISRG juurkeskus, näiteks:

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

Kui eelistate ketti jätta IdenTrust — seadke see parameeter 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"

Pange tähele, et see juurkeskus hakkab varsti aeguma, Let’s Encrypt toetab selle ketti aktiivsena kuni 29. septembrini 2021.

Allikas: habr.com