🥇Cert-manager 1.0 wis metu

Yen sampeyan takon karo insinyur sing berpengalaman lan wicaksana apa sing dikira babagan manajer sertifikat lan kenapa kabeh wong nggunakake, banjur spesialis kasebut bakal mendesah, ngrangkul dheweke kanthi yakin lan ujar: "Kabeh wong nggunakake, amarga ora ana alternatif sing waras. Tikus kita nangis, prick, nanging terus urip karo kaktus iki. Kenapa kita tresna? Amarga iku bisa. Napa kita ora tresna? Amarga versi anyar terus metu sing nggunakake fitur anyar. Lan sampeyan kudu nganyari kluster maneh lan maneh. Lan versi lawas mandheg, amarga ana konspirasi lan shamanisme misterius sing gedhe.

Nanging pangembang ngaku manajer sertifikat 1.0 kabeh bakal owah.

Percaya?

Cert-manager minangka pengontrol manajemen sertifikat Kubernetes asli. Bisa digunakake kanggo ngetokake sertifikat saka macem-macem sumber: Ayo Encrypt, HashiCorp Vault, Venafi, tandha lan pasangan kunci sing ditandatangani dhewe. Sampeyan uga ngidini sampeyan nganyari kunci kanthi tanggal kadaluwarsa, lan uga nyoba nganyari sertifikat kanthi otomatis ing wektu sing ditemtokake sadurunge kadaluwarsa. Cert-manager adhedhasar kube-lego lan uga wis nggunakake sawetara trik saka proyek liyane sing padha kayata kube-cert-manager.

Cathetan Rilis

Kanthi versi 1.0, kita menehi tandha kapercayan sajrone telung taun pangembangan proyek manajer sertifikasi. Sajrone wektu iki, wis ngalami évolusi sacara signifikan ing fungsi lan stabilitas, nanging sing paling penting ing komunitas. Saiki, kita ndeleng akeh wong sing nggunakake kanggo ngamanake klompok Kubernetes lan uga nyebarake menyang macem-macem bagean ekosistem. Akeh kewan omo wis didandani ing 16 rilis pungkasan. Lan sing perlu dirusak wis rusak. Sawetara kunjungan kanggo nggarap API wis nambah interaksi karo pangguna. Kita wis ngrampungake 1500 masalah ing GitHub kanthi panjaluk tarik luwih akeh saka 253 anggota komunitas.

Kanthi rilis 1.0, kita resmi ngumumake manawa manajer sertifikasi minangka proyek sing diwasa. Kita uga janji bakal tetep kompatibel karo API v1.

Many thanks kanggo kabeh wong sing mbantu kita nggawe sertifikat-manajer kabeh telung taun iki! Ayo versi 1.0 dadi pisanan saka akeh perkara gedhe sing bakal teka.

Rilis 1.0 minangka rilis stabil kanthi sawetara wilayah prioritas:

v1 API;
tim kubectl cert-manager status, kanggo mbantu analisis masalah;
Nggunakake API Kubernetes stabil paling anyar;
Ngapikake logging;
dandan ACME.

Priksa manawa maca cathetan upgrade sadurunge nganyarke.

API v1

Versi v0.16 makarya karo API v1beta1. Iki nambah sawetara owah-owahan struktural lan uga nambah dokumentasi lapangan API. Versi 1.0 dibangun nganggo API v1. API iki minangka sing pertama sing stabil, ing wektu sing padha kita wis menehi jaminan kompatibilitas, nanging kanthi API v1 kita janji kanggo njaga kompatibilitas kanggo taun teka.

Owah-owahan sing digawe (cathetan: alat konversi kita ngurus kabeh kanggo sampeyan):

Sertifikat:

emailSANs saiki diarani emailAddresses
uriSANs - uris

Owah-owahan iki nambah kompatibilitas karo SAN liyane (jeneng alt subyek, kira-kira. penerjemah), uga karo Go API. Kita mbusak istilah iki saka API kita.

Update

Yen sampeyan nggunakake Kubernetes 1.16+, ngowahi webhooks bakal ngidini sampeyan nggarap versi API kanthi bebarengan lan lancar. v1alpha2, v1alpha3, v1beta1 и v1. Kanthi iki, sampeyan bakal bisa nggunakake versi anyar saka API tanpa ngganti utawa redeploying sumber lawas. Disaranake sampeyan nganyarke manifes menyang API v1, amarga versi sadurunge bakal ora digunakake maneh. Pangguna legacy versi cert-manager isih mung duwe akses menyang v1, langkah upgrade bisa ditemokake kene.

kubectl cert-manager status printah

Kanthi dandan anyar ing extension kita kanggo kubectl dadi luwih gampang kanggo neliti masalah sing digandhengake karo non-penerbitan sertifikat. kubectl cert-manager status saiki menehi informasi luwih akeh babagan apa sing kedadeyan karo sertifikat lan uga nuduhake tahap penerbitan sertifikat.

Sawise nginstal extension, sampeyan bisa mbukak kubectl cert-manager status certificate <имя-сертификата>, sing bakal nggoleki sertifikat kanthi jeneng sing diwenehake lan sumber daya sing gegandhengan kayata CertificateRequest, Secret, Issuer, lan Order and Challenges yen nggunakake sertifikat saka ACME.

Conto debugging sertifikat sing durung siyap:

$ 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

Printah kasebut uga bisa mbantu sampeyan sinau luwih lengkap babagan isi sertifikat. Conto rinci kanggo sertifikat sing diterbitake dening 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
[...]

Nggunakake API Kubernetes stabil paling anyar

Cert-manager iku salah siji sing pisanan kanggo ngleksanakake Kubernetes CRDs. Iki, lan dhukungan kanggo versi Kubernetes nganti 1.11, tegese kita kudu ndhukung warisan kasebut. apiextensions.k8s.io/v1beta1 kanggo CRDs kita uga admissionregistration.k8s.io/v1beta1 kanggo webhooks kita. Saiki wis ora digunakake lan bakal dibusak ing Kubernetes saka versi 1.22. Kanthi 1.0 kita saiki nawakake dhukungan lengkap apiextensions.k8s.io/v1 и admissionregistration.k8s.io/v1 kanggo Kubernetes 1.16 (ngendi padha ditambahake) lan anyar. Kanggo pangguna versi sadurunge, kita terus nawakake dhukungan v1beta1 ing kita legacy versi.

Apik logging

Ing release iki, kita wis nganyari perpustakaan logging kanggo klog/v2, digunakake ing Kubernetes 1.19. Kita uga mriksa saben jurnal sing kita tulis kanggo mesthekake yen wis ditugasake ing tingkat sing cocog. Kita dipandu dening iki panuntun dhumateng saka Kubernetes. Ana lima (bener enem, kira-kira. penerjemah) tingkat logging wiwit saka Error (tingkat 0), kang prints mung kasalahan penting, lan ends karo Trace (level 5) sing bakal mbantu sampeyan ngerti persis apa sing kedadeyan. Kanthi owah-owahan iki, kita wis suda jumlah log yen sampeyan ora mbutuhake informasi debug nalika mbukak cert-manager.

Tip: manajer sertifikat mlaku ing level 2 kanthi standar (Info), sampeyan bisa ngatasi iki nggunakake global.logLevel ing Helmchart.

Cathetan: Ndeleng log minangka pilihan pungkasan nalika ngatasi masalah. Kanggo informasi luwih lengkap mriksa metu kita kepemimpinan.

Editor n.b.: Kanggo mangerteni sing luwih lengkap babagan cara kerjane kabeh ing hood saka Kubernetes, njaluk saran terkenal saka guru esthi, uga kualitas bantuan technical support, sampeyan bisa melu ing online intensif Pangkalan Kubernetes, kang bakal dianakaké 28-30 September, lan Kubernetes Megakang bakal dianakaké 14-16 Oktober.

dandan ACME

Panggunaan paling umum saka cert-manager mbokmenawa ana hubungane karo nerbitake sertifikat saka Ayo Encrypt nggunakake ACME. Versi 1.0 misuwur amarga nggunakake umpan balik komunitas kanggo nambah rong perbaikan cilik nanging penting kanggo sing ngetokake sekuritas ACME.

Pateni generasi kunci akun

Yen sampeyan nggunakake sertifikat ACME ing volume gedhe, sampeyan bisa nggunakake akun sing padha ing macem-macem klompok, supaya watesan penerbitan sertifikat bakal ditrapake kanggo kabeh. Iki wis bisa ditindakake ing manajer sertifikat nalika nyalin rahasia sing kasebut ing privateKeySecretRef. Kasus panggunaan iki cukup bug, amarga manajer sertifikat nyoba nulungi lan seneng nggawe kunci akun anyar yen ora nemokake. Pramila kita nambah disableAccountKeyGenerationkanggo nglindhungi sampeyan saka prilaku iki yen sampeyan nyetel pilihan iki kanggo true - cert-manager ora bakal generate tombol lan bakal ngelekake sing wis ora kasedhiya karo tombol akun.

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

Rantai sing disenengi

29 September Ayo Encrypt bakal liwat menyang ROOT dhewe CA ISRG Root. Sertifikat sing ditandatangani salib bakal diganti karo Identrust. Owah-owahan iki ora mbutuhake owah-owahan ing setelan cert-manager, kabeh sertifikat dianyari utawa anyar ditanggepi sawise tanggal iki bakal nggunakake CA ROOT anyar.

Ayo Encrypt wis tandha sertifikat karo CA iki lan nawakake minangka "rantai sertifikat alternatif" liwat ACME. Ing versi cert-manager iki, sampeyan bisa nyetel akses menyang rantai kasebut ing setelan sing ngetokake sekuritas. Ing parameter preferredChain sampeyan bisa nemtokake jeneng CA digunakake, karo kang certificate bakal ditanggepi. Yen sertifikat CA sing cocog karo panyuwunan kasedhiya, bakal menehi sertifikat. Elinga yen iki minangka pilihan sing disenengi, yen ora ana sing ditemokake, sertifikat standar bakal ditanggepi. Iki bakal mesthekake yen sampeyan isih bakal gawe anyar sertifikat sawise mbusak chain alternatif ing sisih sing ngetokake sekuritas ACME.

Saiki sampeyan bisa nampa sertifikat sing ditandatangani ISRG Root, Dadi:

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

Yen sampeyan luwih seneng ninggalake rantai IdenTrust - nyetel pilihan iki kanggo 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"

Wigati dimangerteni manawa CA ROOT iki bakal dibuwang, Ayo Encrypt bakal njaga rantai iki aktif nganti 29 September 2021.

Source: www.habr.com

cert-manager 1.0 dirilis