Xususiy registr SSL muammolarini bartaraf etish

1. Fon va muammo holati

So'nggi loyiha faoliyati davomida Kubernetes muhitida ma'lum bir Pod normal ravishda yuklanmayapti va ImagePullBackOff xatosini takroriy ravishda keltirib chiqarmoqda.

Avval mavjud bo'lgan Podlar muammosiz ishlayotganligi sababli, dastlab Registryning o'zida muammo yo'q deb hisoblangan.

Ammo yangi Deployment tarqatilgandan so'ng, yangi yaratilayotgan Podlar doimiy ravishda tasvirni yuklab olishda muvaffaqiyatsizlikka uchrab, natijada yangi Pod normal ishlay olmadi.

Muammo sababini aniqlash uchun kubelet loglari va konteyner ishga tushirish loglarini tahlil qilish natijasida, Private Registry bilan TLS aloqasi jarayonida SSL sertifikatini tasdiqlashda xato yuz berayotganini aniqladik.

Xususan, “curl -v https://repo.example.com:11000/v2/” buyrug'i orqali Registry manzilini to'g'ridan-to'g'ri chaqirib ko'rish jarayonida quyidagi xato xabari topildi.

SSL certificate problem: unable to get local issuer certificate

Ushbu xabar shunchaki sertifikatning muddati o'tganligini anglatmaydi, balki ushbu SSL sertifikatini bergan CA (Sertifikat Ma'muriyati) tugun ishonmayapti deganidir.

Ya'ni, Registry serveri normal sertifikatdan foydalangan, ammo Kubernetes tuguni ichidagi ishonch do'koni (Trust Store) ushbu sertifikat beruvchi haqidagi ma'lumotga ega emasligi sababli TLS tekshiruvi muvaffaqiyatsiz bo'ldi.

Xususan Private Registry muhitida ichki tarmoq uchun mo'ljallangan sertifikatlar yoki xususiy sertifikatlar asosidagi sertifikatlarni ishlatish hollari ko'p bo'ladi.

Bunday hollarda operator nafaqat Registryni yaratishi, balki Kubernetes Worker Node va Container Runtime muhitida ham ushbu sertifikat tashkiloti haqidagi ma'lumotlarni ro'yxatdan o'tkazishi kerak.

Ammo dastlabki qurilish bosqichida bu qism ko'p hollarda yo'q bo'lib qoladi va yangi tugunlar qo'shilishi yoki qayta taqsimlanish vaqtida muammolar paydo bo'lishi tez-tez uchraydi.

Shuningdek, mavjud Pod'lar normal ishlaydi va yangi Pod'lar faqat muvaffaqiyatsiz bo'lgan sabab esa tasvir keshidir.

Container Runtime lokalda yuklab olingan suratlarni qayta ishlatish imkoniyatiga ega bo'lganligi sababli, mavjud Podlar Registry ga murojaat qilmasdan ishlay olgan.

Boshqa tomondan, yangi yaratilayotgan Podlar Registry ga bevosita murojaat qilib, suratlarni tortib olishlari kerak edi va bu jarayonda SSL tekshirish xatosi ro'y berdi.

Ushbu muammolar Kubernetes muhitida emas, balki Docker, containerd, CRI-O, k3s va boshqalar kabi Container Runtime muhitlarida ham sodir bo'lishi mumkin.

Shuning uchun SSL sertifikat tizimi va CA ishonch do'konlari tuzilmasini tushunish operatsion muhitning barqarorligi uchun juda muhimdir.

2. Muammo hal qilish

(1) SSL sertifikatini tekshirish

Muammoni hal qilishning birinchi bosqichi haqiqiy Registry serveri qaysi sertifikatlarni ishlatayotganini aniqlashdir.

Ishlab chiqarish muhitida sertifikat zanjiri ko'pincha bir necha darajalardan iborat bo'ladi va o‘rta sertifikat (Intermediate CA) o‘chirilsa, xuddi shunday muammo yuzaga kelishi mumkin.

Avval openssl buyruqini ishlatib sertifikatning Subject va Issuer ma'lumotlarini tekshirishingiz kerak.

openssl s_client -connect repo.example.com:11000 /dev/null | openssl x509 -noout -subject –issuer

Chiqarish namunasi quyidagicha.

subject=CN=*.example.com
issuer=C=GB; O=Sectigo Limited; CN=Sectigo Public Server Authentication CA DV R36

Natijadan shuni ta'kidlash mumkinki, haqiqiy sertifikatni bergan tashkilot Sectigo qatoridagi CA hisoblanadi.

Ushbu jarayon sertifikatning amal qilish muddati tugaganligini aniqlashdan tashqari, qaysi sertifikat beruvchi tashkilotga ishonish kerakligini aniqlash uchun muhim bosqichdir.

Keyinidagi bosqichda haqiqiy sertifikatni fayl sifatida chiqaramiz.

openssl s_client -connect repo.example.com:11000 -showcerts /dev/null | sed -n 
'/-----BEGIN CERTIFICATE-----/,/-----END CERTIFICATE-----/p' > 
SectigoPublicServerAuthenticationCA.crt

Ushbu buyruq Registry serveri taqdim etadigan to'liq sertifikat zanjirini faylga saqlaydi.

Atrofga qarab, ildiz sertifikatlari va o'rta sertifikatlar birgalikda mavjud bo'lishi mumkin, ba'zi atrof-muhitlarda bir vaqtning o'zida bir nechta sertifikatlar chiqariladi.

Chiqarilgan sertifikatlar sonini quyidagi buyruq bilan tekshirib ko'rishingiz mumkin.

grep -c 'BEGIN CERTIFICATE' SectigoPublicServerAuthenticationCA.crt

Agar bir nechta sertifikat zanjirlari mavjud bo'lsa, har bir sertifikatning to'g'ri kiritilganligini tekshirishingiz shart.

Ayniqsa, o'rta sertifikat yo'qolsa, brauzer to'g'ri ishlasa ham, Container Runtime-da tasdiqlash muvaffaqiyatsiz bo'lishi mumkin.

(2) CA sertifikat tizimini ro'yxatdan o'tkazish (Ubuntu / Debian oilasi)

Eng tavsiya etilgan yechim - CA sertifikatini tugunni kutilgan ishonch doirasiga ro'yxatdan o'tkazishdir.

Ushbu usul TLS tasdiqlashini saqlab qolgan holda, Registry bilan ishonchli aloqa o'rnatishga imkon beradiganligi sababli, ishga tushirish muhitida eng xavfsiz usul hisoblanadi.

Avvalgi olingan sertifikatni tizim CA saqlash joyi yo'liga nusxalash kerak.

sudo cp SectigoPublicServerAuthenticationCA.crt /usr/local/share/ca-certificates/

Keyin update-ca-certificates buyrug'i yordamida tizim ishonch do'koni yangilanadi.

sudo update-ca-certificates

Ushbu ish tugagach, Ubuntu yoki Debian tarzi tizimlari /etc/ssl/certs ichida simbolik havolalarni avtomatik ravishda yaratadi va butun CA to'plamlarini qayta tuzadi.

Qonuniy ro'yxatdan o'tish holatini quyidagi buyruq orqali tekshirish mumkin.

openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt SectigoPublicServerAuthenticationCA.crt

Agar muvaffaqiyatli ro'yxatdan o'tgan bo'lsangiz, «OK» xabari chiqadi.

Containerd yoki Docker Runtime'ni qayta ishga tushirganingizdan so'ng, aksariyat muhitlarda Image Pull muammosi hal bo'ladi.

Ishlab chiqarish muhitida bu usuldan foydalanish juda muhimdir.

noqonim sozlamalari xavfsizlikni tekshirish usulini aylanib o'tganligi uchun uzoq muddatda MITM (Man-In-The-Middle) hujumlariga nisbatan zaiflashishi mumkin.

Bundan tashqari, Auto Scaling muhitida yoki yangi Node Provisioning muhitida CA sertifikatlarini avtomatik ravishda tarqatish tizimini yaratish uchun cloud-init, Ansible, Terraform, Kubernetes bootstrap skriptlaridan foydalanish ma'qul.

(3) containerd Insecure sozlamasi

Ba'zi muhitlarda tugmachaga to'g'ridan-to'g'ri SSH kirish imkoniyati yo'q yoki favqulodda avariya sharoitida tezkor tiklash birinchi o'rinda turishi mumkin.

Ushbu holatda containerd sozlamalarida SSL tekshiruvini vaqtinchalik o'chirish mumkin.

Birinchidan, Registry uchun maxsus certs.d papkasini yarating.

mkdir -p /etc/containerd/certs.d/repo.example.com:11000

Keyin hosts.toml faylini yarating.

server = https://repo.example.com:11000
[host."https://repo.example.com:11000"]
capabilities = ["pull", "resolve"]
skip_verify = true

Bu yerda skip_verify = true opsiyasi muhimdir. Ushbu sozlama Registry sertifikatini tekshirishni amalga oshirmaslikka majburlaydi. Sozlamani qo'llaganingizdan so'ng, containerd'ni qayta ishga tushirish muhimdir.

sudo systemctl restart containerd

Ushbu usul tezkor nosozlikdan tiklanishda foydali, ammo ishchi muhitda uzoq muddatli ishlatish tavsiya etilmaydi.

Ayniqsa, xavfsizlik auditi yoki moliya/jamoat muhitlarida notekis sozlamalar o'z-o'zidan siyosat buzilishi bo'lishi mumkin.Bundan tashqari, Registry sertifikatlarini soxtalashtirsangiz ham, tasdiqlashsiz ulanishga ruxsat berilishi mumkin, shuning uchun xavfsizlik xavfi mavjud.Bunaqa usulni faqat vaqtincha choralar sifatida yoki rivojlanish muhitida cheklangan holda ishlatish ma'qul.

(4) k3s registries.yaml Insecure sozlamalari

k3s muhitida odatiy Kubernetes'tan farqli o'laroq, ichki containerd sozlamalari avtomatik boshqariladi. Shuning uchun, containerd sozlamalarini qo'lda o'zgartirsangiz ham, k3s qayta ishga tushirilganda ustiga yozilishi mumkin.

Bu holatda /etc/rancher/k3s/registries.yaml faylidan foydalanish kerak.

mirrors:
 "repo.example.com:11000":
 endpoint:
  - "https://repo.example.com:11000"

configs:
 "repo.example.com:11000":
   auth:
    username: "your-username"
    password: "your-password"
   tls:
     insecure_skip_verify: true

Ushbu sozlama k3s ichida containerd sozlamalari yaratganda avtomatik ravishda aks etadi.

Sozlamalar qo'llanilgandan so'ng k3s xizmatini qayta ishga tushiring.

sudo systemctl restart k3s

Xususan, Edge muhitlari yoki engil Kubernetes muhitlarida k3s dan foydalanish misollari ko'p, shuning uchun registries.yaml tuzilmasini tushunish muhimdir.

Bundan tashqari, operatsion muhitda autentifikatsiya ma'lumotlarini (foydalanuvchi nomi/parol) ochiq matn sifatida saqlash o'rniga Kubernetes Secret yoki Vault asosida autentifikatsiya integratsiyasini ko'rib chiqish tavsiya etiladi.

3. Xulosa

Ushbu muammo bilan shug'ullanish jarayonida Private Registry muhitida yuzaga kelishi mumkin bo'lgan asosan SSL sertifikat muammolarini tahlil qilish va hal etish jarayonini boshdan kechirdik.

Muammoning asosiy sababi Registry serveri sertifikatini bergan CA Kubernetes Node ning ishonchli saqlash joyida mavjud emasligi edi.

Mavjud Pod suratlar keshidagi manfaat tufayli normal ishladi, ammo yangi Pod Registry ga kirish jarayonida SSL tasdiqlash muvaffaqiyatsiz bo'ldi.

Buni hal qilish uchun avval openssl’dan foydalanib, sertifikat beruvchini va sertifikat zanjirini tekshirdim va haqiqiy sertifikotni chiqarib, tizim ishonchli saqlash joyiga ro'yxatdan o'tkazish usulini qo'lladim.

Shuningdek, favqulodda vaziyatlarga javob berish uchun containerd hosts.toml asosidagi insecure sozlash va k3s registries.yaml asosidagi insecure_skip_verify sozlash usullarini ham ko'rib chiqdim.

Biroq, operatsion muhitingizda CA sertifikatini rasmiy ravishda ro'yxatga olish va TLS tekshirish tizimini saqlash juda muhimdir.

insecure sozlamalari vaqtinchalik nosozlikka qarshi choralar sifatida foydalanish kerak va uzoq muddatda foydalanish xavfsizlik zaifliklariga olib kelishi mumkin.

Oxiri, ishonchli Kubernetes boshqaruvi uchun oddiy dasturiy ta'minotni tarqatishdan tashqari, SSL sertifikat tizimi, autentifikatsiya tashkilotining ishonch tuzilishi, Container Runtime ish tartibi kabi barcha jihatlarini tushunish juda muhimligini aniqladim.

Jsia