ProHoster > blog > Utawala > cert-manager 1.0 iliyotolewa

cert-manager 1.0 iliyotolewa

Ukimwuliza mhandisi mwenye uzoefu na busara anachofikiria kuhusu Cert-Meneja na kwa nini kila mtu anaitumia, ataugua, kukukumbatia kwa siri, na kusema kwa uchovu, "Kila mtu anaitumia kwa sababu hakuna njia mbadala za busara. Panya wetu hulia, hujichoma, lakini wanaendelea kuishi na cactus hii. Kwa nini tunaipenda? Kwa sababu inafanya kazi. Kwa nini vipengele vipya vinatolewa mara kwa mara. Kwa nini vipengele vipya vinatolewa kila wakati? Na inabidi usasishe kikundi tena na tena na matoleo ya zamani yanaacha kufanya kazi kwa sababu kuna njama na shamanism kuu ya kushangaza.

Lakini watengenezaji wanahakikishia hilo na meneja wa cheti 1.0 kila kitu kitabadilika.

Je, tutaamini?

cert-manager 1.0 iliyotolewa

Msimamizi wa Cert ni mdhibiti asili wa udhibiti wa cheti cha Kubernetes. Inaweza kutoa vyeti kutoka vyanzo mbalimbali, ikiwa ni pamoja na Let's Encrypt, HashiCorp Vault, Venafi, na jozi za ufunguo wa kutia saini na kujiandikisha. Pia husasisha funguo na vipindi vya uhalali na hujaribu kusasisha cheti kiotomatiki kwa nyakati maalum kabla hazijaisha. Cert-manager inategemea kube-lego na pia hukopa baadhi ya mbinu kutoka kwa miradi mingine kama hiyo, kama vile kube-cert-manager.

Vidokezo vya Kutolewa

Kwa toleo la 1.0, tunaadhimisha miaka mitatu ya maendeleo kwa mradi wa cert-manager. Wakati huu, imeongezeka kwa kiasi kikubwa katika utendaji na utulivu, lakini zaidi ya yote, katika jamii. Leo, tunaona watu wengi wakiitumia kulinda vikundi vyao vya Kubernetes na kuitekeleza katika sehemu mbalimbali za mfumo ikolojia. Matoleo 16 ya mwisho yameona marekebisho mengi ya hitilafu. Na kile kinachohitajika kuvunjwa kimevunjwa. Raundi kadhaa za kazi ya API zimeboresha matumizi ya mtumiaji. Tumetatua masuala 1500 kwenye GitHub, na maombi mengi zaidi ya kuvuta kutoka kwa wanajamii 253.

Kwa kutoa toleo la 1.0, tunamtangaza rasmi msimamizi wa cert kuwa mradi uliokomaa. Pia tunaahidi kudumisha utangamano na API yetu. v1.

Asante sana kwa kila mtu ambaye alitusaidia kukuza Cert-Meneja katika kipindi cha miaka mitatu iliyopita! Toleo la 1.0 linaweza kuwa la kwanza kati ya mafanikio mengi yajayo.

Toleo 1.0 ni toleo thabiti na maeneo kadhaa ya kuzingatia:

  • v1 MOTO;

  • Timu kubectl cert-manager status, kusaidia kuchambua matatizo;

  • Kwa kutumia API za Kubernetes za hivi punde;

  • Ukataji miti ulioboreshwa;

  • Maboresho ya ACME.

Tafadhali hakikisha kuwa umesoma maelezo ya sasisho kabla ya kusasisha.

API v1

Toleo la v0.16 lilifanya kazi na API v1beta1Hii iliongeza mabadiliko kadhaa ya kimuundo na pia kuboresha hati za sehemu za API. Toleo la 1.0 linajengwa juu ya hili na API. v1API hii ndiyo ya kwanza thabiti, wakati tayari tumetoa hakikisho za utangamano, lakini kwa API. v1 Tunaahidi kudumisha utangamano kwa miaka ijayo.

Mabadiliko yaliyofanywa (kumbuka: zana zetu za uongofu zitashughulikia kila kitu kwa ajili yako):

Cheti:

  • emailSANs sasa inaitwa emailAddresses

  • uriSANs - uris

Mabadiliko haya yanaongeza utangamano na SANs zingine (majina mbadala ya mada, takriban. mfasiri), pamoja na Go API. Tunaondoa neno hili kutoka kwa API yetu.

Sasisha

Ikiwa unatumia Kubernetes 1.16+, kubadilisha viboreshaji vya wavuti kutakuruhusu kufanya kazi bila mshono na matoleo ya API kwa wakati mmoja. v1alpha2, v1alpha3, v1beta1 и v1Ukiwa na haya, unaweza kutumia toleo jipya la API bila kubadilisha au kutuma tena rasilimali zako za zamani. Tunapendekeza sana kusasisha maonyesho yako ya API. v1, kwani matoleo ya awali yataacha kutumika hivi karibuni. Watumiaji legacy matoleo ya cert-manager bado yataweza tu kufikia v1, hatua za sasisho zinaweza kupatikana hapa.

Amri ya hali ya meneja wa kubectl

Pamoja na maboresho mapya katika kiendelezi chetu cha kubectl Imekuwa rahisi kuchunguza masuala yanayohusiana na kutotoa vyeti. kubectl cert-manager status sasa hutoa habari zaidi kuhusu kile kinachotokea na vyeti, na pia inaonyesha hatua ya utoaji wa cheti.

Baada ya kufunga ugani, unaweza kukimbia kubectl cert-manager status certificate <имя-сертификата>, ambayo itatafuta cheti chenye jina lililobainishwa na nyenzo zozote zinazohusiana, kama vile Ombi la Cheti, Siri, Mtoaji, Agizo na Changamoto katika kesi ya vyeti kutoka ACME.

Mfano wa kurekebisha cheti ambacho bado hakijawa tayari:

$ 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

Amri pia inaweza kukusaidia kujifunza zaidi kuhusu yaliyomo kwenye cheti. Huu hapa ni mfano wa maelezo ya cheti kilichotolewa na 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
[...]

Kwa kutumia API za Kubernetes za hivi punde

Msimamizi wa Cert alikuwa mmoja wa wa kwanza kutekeleza Kubernetes CRDs. Hii, pamoja na usaidizi wetu wa matoleo ya Kubernetes hadi 1.11, ilimaanisha kwamba tulilazimika kuunga mkono urithi. apiextensions.k8s.io/v1beta1 kwa CRD zetu pia admissionregistration.k8s.io/v1beta1 kwa vijiti vyetu vya wavuti. Sasa zimeacha kutumika na zitaondolewa katika Kubernetes kuanzia toleo la 1.22. Kwa 1.0 yetu, sasa tunatoa usaidizi kamili. apiextensions.k8s.io/v1 и admissionregistration.k8s.io/v1 kwa Kubernetes 1.16 (ambapo ziliongezwa) na baadaye. Tunaendelea kutoa usaidizi kwa watumiaji wa matoleo ya awali. v1beta1 katika yetu legacy matoleo.

Ukataji miti ulioboreshwa

Katika toleo hili tumesasisha maktaba ya ukataji miti kuwa klog/v2, iliyotumika katika Kubernetes 1.19. Pia tunakagua kila kumbukumbu tunayoandika ili kuipa kiwango kinachofaa. Tulitumia mwongozo kutoka KubernetesKuna watano (kweli sita, takriban. mfasiri) viwango vya ukataji miti, kuanzia Error (kiwango cha 0), ambacho hutoa makosa muhimu tu, na kuishia na Trace (kiwango cha 5), ​​ambacho kitakusaidia kujua ni nini hasa kinaendelea. Kwa mabadiliko haya, tumepunguza idadi ya kumbukumbu ikiwa hauitaji maelezo ya utatuzi unapoendesha cert-manager.

Kidokezo: Kwa chaguo-msingi, meneja wa cert anaendesha katika kiwango cha 2 (Info), unaweza kubatilisha hii kwa kutumia global.logLevel katika chati ya Helm.

Kumbuka: Kuangalia kumbukumbu ni njia ya mwisho wakati wa kutatua matatizo. Kwa habari zaidi, tafadhali tazama yetu uongozi.

Mhariri NBIli kupata maelezo zaidi kuhusu jinsi kila kitu kinavyofanya kazi chini ya usimamizi wa Kubernetes, kupata ushauri muhimu kutoka kwa wakufunzi wanaofanya mazoezi, na kupokea usaidizi wa kiufundi wa hali ya juu, unaweza kushiriki katika kozi za mtandaoni. Msingi wa Kubernetes, ambayo itafanyika Septemba 28-30, na Kubernetes Mega, ambayo itafanyika Oktoba 14-16.

Maboresho ya ACME

Matumizi ya kawaida ya cert-manager pengine ni kutoa vyeti vya Let's Encrypt kwa kutumia ACME. Toleo la 1.0 linajulikana kwa kujumuisha maoni ya jumuiya katika maboresho mawili madogo lakini muhimu kwa mtoaji wetu wa ACME.

Inazima uundaji wa ufunguo wa akaunti

Ukitumia vyeti vya ACME kwa wingi, utakuwa unatumia akaunti sawa kwenye makundi mengi, kwa hivyo vikwazo vya utoaji wa cheti chako vitatumika kwa zote. Hili tayari liliwezekana kwa meneja wa cert kwa kunakili siri iliyoainishwa ndani privateKeySecretRefKesi hii ya utumiaji ilikuwa na tatizo kubwa, kwa kuwa meneja wa cert alijaribu kusaidia na kuunda ufunguo mpya wa akaunti ikiwa hakuweza kuupata. Ndio maana tumeongeza disableAccountKeyGenerationIli kukulinda kutokana na tabia hii, ikiwa utaweka chaguo hili true — meneja wa cert hataunda ufunguo na atakuonya kuwa haijapewa ufunguo wa akaunti.

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

Mnyororo unaopendekezwa

Septemba 29 Hebu Tusimbe kwa Njia Fiche itaendelea kwa mamlaka yako mwenyewe ya uthibitisho wa mizizi ISRG Root. Vyeti vilivyo na saini za msalaba vitabadilishwa na IdentrustMabadiliko haya hayahitaji mabadiliko yoyote kwa mipangilio ya cert-manager; vyeti vyote vilivyosasishwa au vipya vilivyotolewa baada ya tarehe hii vitatumia mzizi mpya wa CA.

Hebu Tusimbe kwa njia fiche tayari tunasaini vyeti kwa kutumia CA hii na kuvitoa kama "msururu wa cheti mbadala" kupitia ACME. Toleo hili la cert-manager hukuruhusu kubainisha ufikiaji wa minyororo hii katika mipangilio ya mtoaji. Katika parameter preferredChain Unaweza kutaja jina la CA ambayo itatoa cheti. Ikiwa cheti cha CA kinacholingana na ombi lako kinapatikana, kitakitoa. Kumbuka kwamba hii ndiyo chaguo linalopendekezwa; ikiwa hakuna kitu kinachopatikana, cheti chaguo-msingi kitatolewa. Hii inahakikisha kwamba bado unaweza kufanya upya cheti chako baada ya kufuta mlolongo mbadala kwenye mtoaji wa ACME.

Tayari unaweza kupokea vyeti vilivyotiwa saini leo ISRG Root, Kwa hiyo:

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

Ikiwa unapendelea kuacha mnyororo IdenTrust - weka parameter hii 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"

Tafadhali kumbuka kuwa mzizi huu wa CA utaacha kutumika hivi karibuni, Let's Encrypt utafanya msururu huu uendelee kutumika hadi tarehe 29 Septemba 2021.

Chanzo: mapenzi.com