🥇Cert-manaĝero 1.0 estas ekstere

Se vi demandas al sperta, saĝa inĝeniero, kion li pensas pri cert-manaĝero kaj kial ĉiuj uzas ĝin, tiam la specialisto ĝemos, memfide brakumos lin kaj diros lace: “Ĉiuj uzas ĝin, ĉar ne ekzistas prudentaj alternativoj. Niaj musoj ploras, pikas, sed daŭre vivas kun ĉi tiu kakto. Kial ni amas? Ĉar ĝi funkcias. Kial ni ne amas? Ĉar konstante aperas novaj versioj, kiuj uzas novajn funkciojn. Kaj vi devas ĝisdatigi la areton denove kaj denove. Kaj la malnovaj versioj ĉesas funkcii, ĉar ekzistas konspiro kaj granda mistera ŝamanismo.

Sed la programistoj asertas tion cert-manaĝero 1.0 ĉio ŝanĝiĝos.

Ĉu ni kredos?

Cert-manaĝero estas la denaska Kubernetes-atestila administra regilo. Ĝi povas esti uzata por elsendi atestojn el diversaj fontoj: Let's Encrypt, HashiCorp Vault, Venafi, subskribaj kaj memsubskribitaj ŝlosilparoj. Ĝi ankaŭ permesas vin teni ŝlosilojn ĝisdatigitaj laŭ limdato, kaj ankaŭ provas aŭtomate renovigi atestilojn en difinita tempo antaŭ ol ili eksvalidiĝas. Cert-manager baziĝas sur kube-lego kaj ankaŭ uzis kelkajn lertaĵojn de aliaj similaj projektoj kiel kube-cert-manager.

Eldonaj Notoj

Kun versio 1.0, ni metis markon de konfido por tri jaroj de disvolviĝo de la cert-manaĝera projekto. Dum ĉi tiu tempo, ĝi evoluis signife en funkcieco kaj stabileco, sed ĉefe en la komunumo. Hodiaŭ, ni vidas multajn homojn uzi ĝin por sekurigi siajn Kubernetes-aretojn kaj ankaŭ deploji ĝin al diversaj partoj de la ekosistemo. Multaj eraroj estis korektitaj en la lastaj 16 eldonoj. Kaj tio, kio devis esti rompita, estas rompita. Pluraj vizitoj por labori kun la API plibonigis ĝian interagadon kun uzantoj. Ni solvis 1500 problemojn en GitHub kun pliaj tiraj petoj de 253 komunumanoj.

Kun la eldono de 1.0, ni oficiale deklaras, ke cert-manaĝero estas matura projekto. Ni ankaŭ promesas konservi nian API kongrua v1.

Koran dankon al ĉiuj, kiuj helpis nin fari cert-manager ĉiujn ĉi tiujn tri jarojn! Lasu versio 1.0 esti la unua el multaj grandaj estontaj aferoj.

Eldonaĵo 1.0 estas stabila eldono kun pluraj prioritataj areoj:

v1 API;
teamo kubectl cert-manager status, helpi pri analizo de problemoj;
Uzante la plej novajn stabilajn Kubernetes-APIojn;
Plibonigita arbohakado;
ACME-plibonigoj.

Nepre legu la ĝisdatigajn notojn antaŭ ĝisdatigi.

API v1

Versio v0.16 funkciis kun la API v1beta1. Ĉi tio aldonis kelkajn strukturajn ŝanĝojn kaj ankaŭ plibonigis la API-kampan dokumentadon. Versio 1.0 konstruas sur ĉi tio kun API v1. Ĉi tiu API estas nia unua stabila, samtempe ni jam donis garantiojn pri kongrueco, sed kun la API v1 ni promesas konservi kongruecon dum venontaj jaroj.

Ŝanĝoj faritaj (notu: niaj konvertaj iloj prizorgas ĉion por vi):

Atestilo:

emailSANs nun vokis emailAddresses
uriSANs - uris

Ĉi tiuj ŝanĝoj aldonas kongruecon kun aliaj SANoj (subjektaj altnomoj, ĉ. tradukisto), same kiel kun la Go API. Ni forigas ĉi tiun terminon de nia API.

Ĝisdatigu

Se vi uzas Kubernetes 1.16+, konverti rethokojn permesos al vi samtempe kaj perfekte labori kun API-versioj. v1alpha2, v1alpha3, v1beta1 и v1. Kun ĉi tiuj, vi povos uzi la novan version de la API sen ŝanĝi aŭ redeploji viajn malnovajn rimedojn. Ni forte rekomendas ĝisdatigi viajn manifestojn al la API v1, ĉar antaŭaj versioj estos malrekomenditaj baldaŭ. Uzantoj legacy versioj de cert-manager ankoraŭ havos nur aliron al v1, ĝisdatigaj paŝoj troveblas tie.

stato komando kubectl cert-manager

Kun novaj plibonigoj en nia etendo al kubectl iĝis pli facile esplori la problemojn asociitajn kun la neemisio de atestiloj. kubectl cert-manager status nun donas multe pli da informoj pri kio okazas kun la atestiloj kaj ankaŭ montras la etapon de emisio de atestiloj.

Post instalo de la etendo, vi povas kuri kubectl cert-manager status certificate <имя-сертификата>, kiu serĉos la atestilon kun la persona nomo kaj ajnaj rilataj rimedoj kiel CertificateRequest, Secret, Issuer, kaj Order and Challenges se uzado de atestiloj de ACME.

Ekzemplo de sencimigado de atestilo kiu ankoraŭ ne estas preta:

$ 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

La komando ankaŭ povas helpi vin lerni pli pri la enhavo de la atestilo. Detala ekzemplo por atestilo eldonita de 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
[...]

Uzante la plej novajn stabilajn Kubernetes-APIojn

Cert-manaĝero estis unu el la unuaj se temas pri efektivigi Kubernetes CRD-ojn. Ĉi tio, kaj nia subteno por Kubernetes-versioj ĝis 1.11, signifis, ke ni devis subteni la heredaĵon. apiextensions.k8s.io/v1beta1 ankaŭ por niaj CRD-oj admissionregistration.k8s.io/v1beta1 por niaj rethokoj. Ili nun estas malrekomenditaj kaj estos forigitaj en Kubernetes de versio 1.22. Kun nia 1.0 ni nun ofertas plenan subtenon apiextensions.k8s.io/v1 и admissionregistration.k8s.io/v1 por Kubernetes 1.16 (kie ili estis aldonitaj) kaj pli novaj. Por uzantoj de antaŭaj versioj, ni daŭre ofertas subtenon v1beta1 en nia legacy versioj.

Plibonigita arbohakado

En ĉi tiu eldono, ni ĝisdatigis la registran bibliotekon al klog/v2, uzata en Kubernetes 1.19. Ni ankaŭ revizias ĉiun ĵurnalon, kiun ni skribas, por certigi, ke ĝi ricevas la taŭgan nivelon. Ni estis gviditaj de ĉi tio gvidado de Kubernetes. Estas kvin (fakte ses, ĉ. tradukisto) registradniveloj ekde Error (nivelo 0), kiu presas nur gravajn erarojn, kaj finiĝas per Trace (nivelo 5) kiu helpos vin scii precize kio okazas. Kun ĉi tiu ŝanĝo, ni reduktis la nombron da protokoloj se vi ne bezonas sencimigan informon dum rulado de cert-manager.

Konsileto: cert-manager funkcias defaŭlte ĉe nivelo 2 (Info), vi povas anstataŭi ĉi tion uzante global.logLevel en Helmchart.

Noto: Vidi la protokolojn estas la lasta rimedo dum problemoj. Por pliaj informoj kontrolu nian gvidado.

Redaktoro n.b.: Por lerni pli pri kiel ĉio funkcias sub la kapuĉo de Kubernetes, ricevu valorajn konsilojn de praktikantaj instruistoj, kaj ankaŭ kvalitan teknikan subtenan helpon, vi povas partopreni interretajn intensiĝojn. Kubernetes Bazo, kiu okazos 28-30 septembro, kaj Kubernetes Megakiu okazos la 14-16-an de oktobro.

Pliboniĝoj de ACME

La plej ofta uzo de cert-manager probable rilatas al eldonado de atestiloj de Let's Encrypt uzante ACME. Versio 1.0 estas rimarkinda pro uzi komunumajn sugestojn por aldoni du malgrandajn sed gravajn plibonigojn al nia ACME-eldonanto.

Malebligu kont-ŝlosilgeneradon

Se vi uzas ACME-atestojn en grandaj volumoj, vi verŝajne uzos la saman konton en pluraj aretoj, do viaj atestillimigoj aplikiĝos al ĉiuj. Ĉi tio jam estis ebla en cert-manager dum kopiado de la sekreto specifita en privateKeySecretRef. Ĉi tiu uzokazo estis sufiĉe fuŝa, ĉar cert-manaĝero provis esti helpema kaj feliĉe kreis novan kontŝlosilon se ĝi ne trovis tian. Tial ni aldonis disableAccountKeyGenerationpor protekti vin kontraŭ ĉi tiu konduto se vi agordas ĉi tiun opcion true - cert-manager ne generos ŝlosilon kaj avertos vin ke ĝi ne estis provizita per kontŝlosilo.

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

Preferata Ĉeno

29 septembro Ni Ĉifri pasos al via propra radiko CA ISRG Root. Krucsubskribitaj atestiloj estos anstataŭigitaj per Identrust. Ĉi tiu ŝanĝo ne postulas ŝanĝojn al la cert-manaĝeraj agordoj, ĉiuj ĝisdatigitaj aŭ novaj atestiloj eldonitaj post ĉi tiu dato uzos la novan radikan CA.

Ni Ĉifri jam subskribas atestilojn kun ĉi tiu CA kaj proponas ilin kiel "alternan atestilĉenon" per ACME. En ĉi tiu versio de cert-manager, eblas agordi aliron al ĉi tiuj ĉenoj en la eldonaj agordoj. En parametro preferredChain vi povas specifi la nomon de la CA uzata, per kiu la atestilo estos eldonita. Se CA-atestilo kongrua kun la peto estas havebla, ĝi eldonos al vi atestilon. Bonvolu noti, ke ĉi tiu estas la preferata opcio, se nenio estas trovita, defaŭlta atestilo estos elsendita. Ĉi tio certigos, ke vi ankoraŭ renovigos vian atestilon post forigo de la alterna ĉeno ĉe la eldonanto de ACME.

Jam hodiaŭ vi povas ricevi atestilojn subskribitajn de ISRG Root, Do:

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

Se vi preferas forlasi la ĉenon IdenTrust - agordu ĉi tiun opcion al 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"

Bonvolu noti, ke ĉi tiu radiko CA estos malrekomendita, Let's Encrypt tenos ĉi tiun ĉenon aktiva ĝis la 29-a de septembro 2021.

fonto: www.habr.com

cert-manaĝero 1.0 liberigita