cert-manager 1.0 dirilis

Jika Anda bertanya kepada seorang insinyur yang berpengalaman dan bijaksana apa pendapatnya tentang manajer sertifikat dan mengapa semua orang menggunakannya, spesialis tersebut akan menghela nafas, memeluknya secara rahasia dan berkata dengan letih: β€œSemua orang menggunakannya, karena tidak ada alternatif yang masuk akal. Tikus kami menangis, menusuk dirinya sendiri, tapi terus hidup dengan kaktus ini. Mengapa kita mencintai? Karena itu berhasil. Mengapa kita tidak mencintai? Karena terus-menerus dirilis versi baru yang menggunakan fitur-fitur baru. Dan Anda harus memperbarui cluster berulang kali. Dan versi lama berhenti bekerja, karena ada konspirasi dan perdukunan misterius yang besar.”

Namun pengembang mengklaim hal itu dengan manajer-sertifikat 1.0 segalanya akan berubah.

Akankah kita percaya?

cert-manager 1.0 dirilis

Cert-manager adalah pengontrol manajemen sertifikat Kubernetes asli. Ini dapat digunakan untuk menerbitkan sertifikat dari berbagai sumber: Let's Encrypt, HashiCorp Vault, Venafi, penandatanganan, dan pasangan kunci yang ditandatangani sendiri. Ini juga memungkinkan Anda untuk selalu memperbarui kunci dan mencoba memperbarui sertifikat secara otomatis pada waktu tertentu sebelum masa berlakunya habis. Cert-manager didasarkan pada kube-lego, dan juga menggunakan beberapa teknik dari proyek serupa lainnya, seperti kube-cert-manager.

Catatan Rilis

Dengan versi 1.0 kami memberi tanda kepercayaan pada tiga tahun pengembangan proyek cert-manager. Selama ini, fungsionalitas dan stabilitasnya telah berkembang secara signifikan, tetapi yang terpenting adalah komunitas. Saat ini kita melihat banyak orang menggunakannya untuk mengamankan cluster Kubernetes mereka, serta mengimplementasikannya ke berbagai bagian ekosistem. Banyak bug telah diperbaiki dalam 16 rilis terakhir. Dan apa yang seharusnya rusak malah rusak. Beberapa kunjungan ke API meningkatkan interaksinya dengan pengguna. Kami telah menyelesaikan 1500 masalah di GitHub, dengan lebih banyak permintaan penarikan dari 253 anggota komunitas.

Dengan merilis 1.0, kami secara resmi menyatakan bahwa cert-manager adalah proyek yang matang. Kami juga berjanji untuk menjaga API kami tetap kompatibel v1.

Terima kasih banyak kepada semua orang yang membantu kami membuat manajer sertifikat selama tiga tahun ini! Biarkan versi 1.0 menjadi yang pertama dari banyak hal hebat yang akan datang.

Rilis 1.0 adalah rilis stabil dengan beberapa area prioritas:

  • v1 API;

  • Tim kubectl cert-manager status, untuk membantu menganalisis masalah;

  • Menggunakan API Kubernetes stabil terbaru;

  • Peningkatan pencatatan;

  • perbaikan ACME.

Pastikan untuk membaca catatan pembaruan sebelum memutakhirkan.

API v1

Versi v0.16 berfungsi dengan API v1beta1. Ini menambahkan beberapa perubahan struktural dan juga meningkatkan dokumentasi bidang API. Versi 1.0 dibangun berdasarkan semua ini dengan API v1. API ini adalah yang stabil pertama kami, pada saat yang sama kami telah memberikan jaminan kompatibilitas, tetapi dengan API tersebut v1 Kami berjanji untuk menjaga kompatibilitas selama bertahun-tahun yang akan datang.

Perubahan yang dilakukan (catatan: alat konversi kami akan mengurus semuanya untuk Anda):

Sertifikat:

  • emailSANs sekarang disebut emailAddresses

  • uriSANs - uris

Perubahan ini menambah kompatibilitas dengan SAN lain (nama alt subjek, kira-kira Penerjemah), serta dengan Go API. Kami menghapus istilah ini dari API kami.

Memperbarui

Jika Anda menggunakan Kubernetes 1.16+ - mengonversi webhook akan memungkinkan Anda bekerja dengan versi API secara bersamaan dan lancar v1alpha2, v1alpha3, v1beta1 ΠΈ v1. Dengan mereka, Anda dapat menggunakan API versi baru tanpa mengubah atau menerapkan ulang sumber daya lama Anda. Kami sangat menyarankan untuk mengupgrade manifes Anda ke API v1, karena versi sebelumnya tidak akan digunakan lagi. Pengguna legacy versi cert-manager hanya akan memiliki akses ke v1, langkah pembaruan dapat ditemukan di sini.

perintah status kubectl cert-manager

Dengan peningkatan baru dalam ekstensi kami ke kubectl Penyelidikan permasalahan yang berkaitan dengan tidak diterbitkannya sertifikat menjadi lebih mudah. kubectl cert-manager status sekarang memberikan lebih banyak informasi tentang apa yang terjadi dengan sertifikat, dan juga menunjukkan tahap penerbitan sertifikat.

Setelah menginstal ekstensi, Anda dapat menjalankannya kubectl cert-manager status certificate <имя-сСртификата>, yang akan mencari sertifikat dengan nama tertentu dan sumber daya apa pun yang terkait, seperti CertificateRequest, Secret, Issuer, dan Order and Challenges dalam hal sertifikat dari ACME.

Contoh debugging sertifikat yang belum siap:

$ 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

Tim juga dapat membantu Anda mempelajari lebih lanjut isi sertifikat. Contoh detail sertifikat yang diterbitkan oleh 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
[...]

Manfaatkan API Kubernetes stabil terbaru

Cert-manager adalah salah satu orang pertama yang mengimplementasikan CRD Kubernetes. Hal ini, ditambah dengan dukungan kami terhadap versi Kubernetes hingga 1.11, berarti kami perlu mendukung versi lama apiextensions.k8s.io/v1beta1 untuk CRD kami juga admissionregistration.k8s.io/v1beta1 untuk webhook kami. Ini sekarang sudah tidak digunakan lagi dan akan dihapus di Kubernetes mulai versi 1.22. Dengan 1.0 kami sekarang menawarkan dukungan penuh apiextensions.k8s.io/v1 ΠΈ admissionregistration.k8s.io/v1 untuk Kubernetes 1.16 (di mana mereka ditambahkan) dan yang lebih baru. Untuk pengguna versi sebelumnya, kami terus menawarkan dukungan v1beta1 di kami legacy versi.

Pencatatan log yang lebih baik

Dalam versi ini kami telah memperbarui perpustakaan logging menjadi klog/v2, digunakan di Kubernetes 1.19. Kami juga meninjau setiap majalah yang kami tulis untuk memastikannya diberi tingkat yang sesuai. Kami dipandu oleh ini bimbingan dari Kubernetes. Ada lima (sebenarnya - enam, kira-kira Penerjemah) tingkat logging mulai dari Error (level 0), yang hanya mencetak kesalahan penting, dan diakhiri dengan Trace (level 5), yang akan membantu Anda mengetahui apa yang sebenarnya terjadi. Dengan perubahan ini kami telah mengurangi jumlah log jika Anda tidak memerlukan informasi debug saat menjalankan cert-manager.

Tip: secara default cert-manager berjalan pada level 2 (Info), Anda dapat menimpanya menggunakan global.logLevel dalam bagan Helm.

Catatan: Meninjau log adalah pilihan terakhir Anda saat memecahkan masalah. Untuk informasi lebih lanjut, lihat kami kepemimpinan.

Catatan Redaksi: Untuk mempelajari lebih lanjut tentang cara kerja Kubernetes, mendapatkan saran berharga dari guru praktik, serta dukungan teknis berkualitas tinggi, Anda dapat mengikuti kursus intensif online Basis Kubernetes, yang akan berlangsung 28-30 September, dan Kubernet Mega, yang akan berlangsung 14-16 Oktober.

Perbaikan ACME

Penggunaan cert-manager yang paling umum mungkin terkait dengan penerbitan sertifikat dari Let's Encrypt menggunakan ACME. Versi 1.0 terkenal karena menggunakan umpan balik komunitas untuk menambahkan dua perbaikan kecil namun penting pada penerbit ACME kami.

Nonaktifkan Pembuatan Kunci Akun

Jika Anda menggunakan sertifikat ACME dalam volume besar, kemungkinan besar Anda menggunakan akun yang sama di beberapa klaster, sehingga pembatasan penerbitan sertifikat Anda akan berlaku untuk semuanya. Ini sudah dimungkinkan di cert-manager saat menyalin rahasia yang ditentukan di privateKeySecretRef. Kasus penggunaan ini cukup bermasalah karena manajer sertifikat mencoba membantu dan dengan senang hati membuat kunci akun baru jika tidak dapat menemukannya. Itu sebabnya kami menambahkan disableAccountKeyGenerationuntuk melindungi Anda dari perilaku ini dengan menyetel opsi ini ke true - manajer-sertifikat tidak akan membuat kunci dan akan memperingatkan Anda bahwa kunci akun tidak diberikan.

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

Rantai Pilihan

29 September Mari Enkripsi akan pindah ke otoritas sertifikat akar Anda sendiri ISRG Root. Sertifikat yang ditandatangani silang akan diganti dengan Identrust. Perubahan ini tidak memerlukan perubahan pada pengaturan manajer sertifikat; semua sertifikat yang diperbarui atau baru yang diterbitkan setelah tanggal ini akan menggunakan root CA yang baru.

Mari Enkripsi sudah menandatangani sertifikat dengan CA ini dan menawarkannya sebagai "rantai sertifikat alternatif" melalui ACME. Versi manajer sertifikat ini memiliki kemampuan untuk mengatur akses ke rantai ini di pengaturan penerbit. Dalam parameternya preferredChain Anda dapat menentukan nama CA yang digunakan untuk menerbitkan sertifikat. Jika tersedia sertifikat CA yang sesuai dengan permintaan, Anda akan diberikan sertifikat. Harap dicatat bahwa ini adalah pilihan yang lebih disukai; jika tidak ada yang ditemukan, sertifikat default akan diterbitkan. Ini akan memastikan bahwa Anda masih akan memperbarui sertifikat Anda setelah menghapus rantai alternatif di sisi penerbit ACME.

Hari ini Anda dapat menerima sertifikat yang ditandatangani ISRG Root, Jadi:

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

Jika Anda lebih memilih untuk meninggalkan rantai IdenTrust β€” atur parameter ini ke 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"

Harap dicatat bahwa root CA ini akan segera dihentikan, Let's Encrypt akan menjaga rantai ini tetap aktif hingga 29 September 2021.

Sumber: www.habr.com

Tambah komentar