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 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 disebutemailAddresses
-
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
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 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
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
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 disableAccountKeyGeneration
untuk 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 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