🥇cert-manager 1.0 inilabas

Kung tatanungin mo ang isang may karanasan, matalinong inhinyero kung ano ang iniisip niya tungkol sa cert-manager at kung bakit ginagamit ito ng lahat, ang espesyalista ay magbubuntong-hininga, yayakapin siya nang kumpidensyal at pagod na sasabihin: “Ginagamit ito ng lahat, dahil walang matino na mga alternatibo. Ang aming mga daga ay umiiyak, tinutusok ang kanilang mga sarili, ngunit patuloy na nabubuhay kasama ang cactus na ito. Bakit tayo nagmamahal? Dahil ito ay gumagana. Bakit hindi tayo nagmamahal? Dahil ang mga bagong bersyon ay patuloy na inilalabas na gumagamit ng mga bagong tampok. At kailangan mong i-update ang cluster nang paulit-ulit. At ang mga lumang bersyon ay huminto sa paggana, dahil mayroong isang pagsasabwatan at isang mahusay na misteryosong shamanismo.

Ngunit inaangkin ng mga developer na may cert-manager 1.0 ang lahat ng bagay ay magbabago.

Maniniwala ba tayo?

Ang Cert-manager ay isang katutubong Kubernetes certificate management controller. Magagamit ito para mag-isyu ng mga certificate mula sa iba't ibang source: Let's Encrypt, HashiCorp Vault, Venafi, signing at self-signed key pairs. Nagbibigay-daan din ito sa iyo na panatilihing napapanahon ang mga susi at subukang awtomatikong mag-renew ng mga sertipiko sa isang tinukoy na oras bago mag-expire ang mga ito. Ang Cert-manager ay batay sa kube-lego, at gumamit din ng ilang diskarte mula sa iba pang katulad na proyekto, gaya ng kube-cert-manager.

Mga Tala sa Paglabas

Sa bersyon 1.0 naglalagay kami ng tanda ng pagtitiwala sa tatlong taon ng pagbuo ng proyekto ng cert-manager. Sa panahong ito, malaki ang naging pag-unlad nito sa functionality at stability, ngunit higit sa lahat sa komunidad. Ngayon, nakikita natin ang maraming tao na gumagamit nito upang ma-secure ang kanilang mga Kubernetes cluster, pati na rin ang pagpapatupad nito sa iba't ibang bahagi ng ecosystem. Isang grupo ng mga bug ang naayos sa huling 16 na paglabas. At ang dapat sana ay nasira ay nasira. Pinahusay ng ilang pagbisita sa API ang pakikipag-ugnayan nito sa mga user. Nalutas namin ang 1500 isyu sa GitHub, na may higit pang mga pull request mula sa 253 miyembro ng komunidad.

Sa pamamagitan ng paglabas ng 1.0, opisyal naming ipinapahayag na ang cert-manager ay isang mature na proyekto. Nangangako rin kaming panatilihing tugma ang aming API v1.

Maraming salamat sa lahat ng tumulong sa aming lumikha ng cert-manager sa lahat ng tatlong taon na ito! Hayaan ang bersyon 1.0 na maging una sa maraming magagandang bagay na darating.

Ang Release 1.0 ay isang stable na release na may ilang priority area:

v1 API;
Koponan kubectl cert-manager status, upang makatulong sa pagsusuri ng mga problema;
Gamit ang pinakabagong mga matatag na Kubernetes API;
Pinahusay na pag-log;
Mga pagpapabuti ng ACME.

Tiyaking basahin ang mga tala sa pag-update bago mag-upgrade.

API v1

Ang bersyon v0.16 ay gumana sa API v1beta1. Nagdagdag ito ng ilang pagbabago sa istruktura at pinahusay din ang dokumentasyon ng field ng API. Binubuo ng Bersyon 1.0 ang lahat ng ito gamit ang isang API v1. Ang API na ito ang aming unang matatag, sa parehong oras ay nagbigay na kami ng mga garantiya sa pagiging tugma, ngunit sa API v1 Nangangako kaming mapanatili ang pagiging tugma sa mga darating na taon.

Mga pagbabagong ginawa (tandaan: ang aming mga tool sa conversion ang bahala sa lahat para sa iyo):

Sertipiko:

emailSANs tinatawag na ngayon emailAddresses
uriSANs - uris

Ang mga pagbabagong ito ay nagdaragdag ng pagiging tugma sa iba pang mga SAN (mga pangalan ng alt ng paksa, tinatayang tagasalin), pati na rin sa Go API. Aalisin namin ang terminong ito sa aming API.

I-update ang

Kung gumagamit ka ng Kubernetes 1.16+ - ang pag-convert ng mga webhook ay magbibigay-daan sa iyong magtrabaho sa mga bersyon ng API nang sabay-sabay at walang putol. v1alpha2, v1alpha3, v1beta1 и v1. Sa kanila, maaari mong gamitin ang bagong bersyon ng API nang hindi binabago o muling i-deploy ang iyong mga lumang mapagkukunan. Lubos naming inirerekomenda ang pag-upgrade ng iyong mga manifest sa API v1, dahil malapit nang mawala ang mga nakaraang bersyon. Mga gumagamit legacy ang mga bersyon ng cert-manager ay magkakaroon pa rin ng access sa v1, makikita ang mga hakbang sa pag-update dito.

kubectl cert-manager status command

Sa mga bagong pagpapahusay sa aming extension sa kubectl Naging mas madali ang pag-iimbestiga sa mga problemang nauugnay sa hindi pagbibigay ng mga sertipiko. kubectl cert-manager status ngayon ay nagbibigay ng higit pang impormasyon tungkol sa kung ano ang nangyayari sa mga sertipiko, at ipinapakita din ang yugto kung saan inilabas ang sertipiko.

Pagkatapos i-install ang extension maaari kang tumakbo kubectl cert-manager status certificate <имя-сертификата>, na maghahanap para sa certificate na may tinukoy na pangalan at anumang nauugnay na mapagkukunan, tulad ng CertificateRequest, Secret, Issuer, at Order and Challenges sa kaso ng mga certificate mula sa ACME.

Isang halimbawa ng pag-debug ng isang certificate na hindi pa handa:

$ 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

Matutulungan ka rin ng koponan na matuto nang higit pa tungkol sa mga nilalaman ng sertipiko. Mga halimbawang detalye para sa isang certificate na ibinigay ng 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
[...]

Gamitin ang pinakabagong mga matatag na Kubernetes API

Ang Cert-manager ay isa sa mga unang nagpatupad ng mga Kubernetes CRD. Ito, kasama ng aming suporta para sa mga bersyon ng Kubernetes hanggang 1.11, ay nangangahulugan na kailangan naming suportahan ang legacy apiextensions.k8s.io/v1beta1 para na rin sa mga CRD natin admissionregistration.k8s.io/v1beta1 para sa aming mga webhook. Ang mga ito ay hindi na ginagamit at aalisin sa Kubernetes simula sa bersyon 1.22. Sa aming 1.0 nag-aalok kami ngayon ng buong suporta apiextensions.k8s.io/v1 и admissionregistration.k8s.io/v1 para sa Kubernetes 1.16 (kung saan sila idinagdag) at mas bago. Para sa mga gumagamit ng mga nakaraang bersyon, patuloy kaming nag-aalok ng suporta v1beta1 sa aming legacy mga bersyon.

Pinahusay na pag-log

Sa bersyong ito na-update namin ang logging library sa klog/v2, ginamit sa Kubernetes 1.19. Sinusuri din namin ang bawat magazine na sinusulat namin upang matiyak na ito ay itinalaga sa naaangkop na antas. Ginabayan tayo nito gabay mula sa Kubernetes. Mayroong lima (sa katunayan - anim, tinatayang tagasalin) mga antas ng pag-log simula sa Error (level 0), na nagpi-print lamang ng mahahalagang error, at nagtatapos sa Trace (level 5), na tutulong sa iyo na malaman kung ano mismo ang nangyayari. Sa pagbabagong ito, binawasan namin ang bilang ng mga log kung hindi mo kailangan ng impormasyon sa pag-debug kapag nagpapatakbo ng cert-manager.

Tip: bilang default ang cert-manager ay tumatakbo sa antas 2 (Info), maaari mong i-override ito gamit ang global.logLevel sa Helm chart.

Tandaan: Ang pagsusuri sa mga log ay ang iyong huling paraan kapag nag-troubleshoot. Para sa karagdagang impormasyon tingnan ang aming pamumuno.

NB ng editor: Upang matuto nang higit pa tungkol sa kung paano gumagana ang lahat sa ilalim ng hood ng Kubernetes, kumuha ng mahalagang payo mula sa mga gurong nagsasanay, pati na rin ang mataas na kalidad na teknikal na suporta, maaari kang makilahok sa mga online na masinsinang kurso Kubernetes Base, na magaganap sa Setyembre 28-30, at Kubernetes Mega, na magaganap sa Oktubre 14–16.

Mga Pagpapabuti ng ACME

Ang pinakakaraniwang paggamit ng cert-manager ay malamang na nauugnay sa pagbibigay ng mga certificate mula sa Let's Encrypt gamit ang ACME. Ang Bersyon 1.0 ay kapansin-pansin sa paggamit ng feedback ng komunidad upang magdagdag ng dalawang maliit ngunit mahalagang pagpapabuti sa aming tagabigay ng ACME.

Huwag paganahin ang Pagbuo ng Key ng Account

Kung gumagamit ka ng mga ACME certificate sa malalaking volume, malamang na ginagamit mo ang parehong account sa maraming cluster, kaya malalapat ang iyong mga paghihigpit sa pag-isyu ng certificate sa lahat ng ito. Posible na ito sa cert-manager kapag kinopya ang lihim na tinukoy sa privateKeySecretRef. Napakaluwag ng use case na ito dahil sinubukan ng cert-manager na tumulong at masayang gumawa ng bagong account key kung wala itong mahanap. Kaya naman nagdagdag kami disableAccountKeyGenerationupang protektahan ka mula sa gawi na ito sa pamamagitan ng pagtatakda ng opsyong ito sa true - hindi bubuo ng key ang cert-manager at babalaan ka nito na hindi ito binigyan ng account key.

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

Ginustong Chain

Setyembre 29 Let's Encrypt ililipat sa sarili mong awtoridad sa root certificate ISRG Root. Ang mga naka-cross-sign na sertipiko ay papalitan ng Identrust. Ang pagbabagong ito ay hindi nangangailangan ng mga pagbabago sa mga setting ng cert-manager; lahat ng na-update o bagong certificate na ibinigay pagkatapos ng petsang ito ay gagamit ng bagong root CA.

Ang Let's Encrypt ay pumipirma na ng mga certificate gamit ang CA na ito at inaalok ang mga ito bilang isang "alternate certificate chain" sa pamamagitan ng ACME. Ang bersyon na ito ng cert-manager ay may kakayahang magtakda ng access sa mga chain na ito sa mga setting ng issuer. Sa parameter preferredChain Maaari mong tukuyin ang pangalan ng CA na ginamit sa pag-isyu ng sertipiko. Kung may available na CA certificate na tumutugma sa kahilingan, bibigyan ka nito ng certificate. Pakitandaan na ito ang gustong opsyon; kung walang mahanap, bibigyan ng default na certificate. Titiyakin nito na ire-renew mo pa rin ang iyong certificate pagkatapos tanggalin ang kahaliling chain sa panig ng tagabigay ng ACME.

Ngayon ay maaari kang makatanggap ng mga sertipiko na nilagdaan ISRG Root, Kaya:

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

Kung mas gusto mong umalis sa kadena IdenTrust — itakda ang parameter na ito sa 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"

Pakitandaan na ang root CA na ito ay malapit nang hindi gamitin, ang Let's Encrypt ay pananatiling aktibo ang chain na ito hanggang Setyembre 29, 2021.

Pinagmulan: www.habr.com

inilabas ang cert-manager 1.0