Kirish
kubectl exec o‘zi bilan “konteyner ichida aynan nima qilingan?” degan savolga deyarli javob bermaydi. Kubernetes audit’ida siz pods/exec subresource’iga murojaat bo‘lganini ko‘rasiz, lekin interaktiv sessiya mazmunini ko‘rmaysiz. kubectl-rexec (Adyen’ning plagin’i) shu muammoni yopadi: u exec’ni o‘z endpoint’i orqali proksi qiladi va auditi mumkin bo‘lgan hodisalarni (events) chiqaradi — shunda sizda “ichkarida” bajarilgan amallar izi paydo bo‘ladi.
GitHub repozitoriy: https://github.com/Adyen/kubectl-rexec
kubectl-rexec ayniqsa qachon foydali
- Compliance va tergov: insident paytida pod ichida qaysi amallar bajarilganini tushunish kerak (faqat “kim shell’ga kirdi” emas).
- Privilegiyali kirish: exec’ni faqat cheklangan guruhga ruxsat berasiz, lekin amallar shaffof bo‘lishini xohlaysiz.
- Change management: “prod’da qo‘lbola o‘zgartirishlar” iz qoldirishi kerak (masalan, konfiguratsiyani o‘zgartirish, konteyner ichida servisni qo‘lda restart qilish).
kubectl-rexec qanday ishlaydi
Arxitektura ikki qismdan iborat:
- ValidatingWebhookConfiguration — odatiy pods/exec’ni bloklaydi, agar so‘rov rexec endpoint orqali kelmagan bo‘lsa (yoki foydalanuvchida aylanib o‘tish huquqi bo‘lmasa).
- APIService (rexec) — kubectl-plagin’dan so‘rovlarni qabul qiladi, ularni yana oddiy exec’ga aylantiradi va kube-apiserver’ga proksi qiladi, shu bilan birga audit hodisalarini yaratadi. Proksilash impersonation orqali qilinadi, chunki kube-apiserver zanjir bo‘ylab asl kredensiallarni uzatmaydi.
Talablar va cheklovlar
- Loyiha exec websocket orqali ishlaydigan klasterlarga mo‘ljallangan. README’da aytilgan: Kubernetes 1.30 (feature gate default holatda yoqilgan) yoki Kubernetes 1.29 va TranslateStreamCloseWebsocketRequests=true yoqilgan bo‘lishi kerak. 1.29’dan past versiyalar qo‘llab-quvvatlanmaydi.
O‘rnatish
O‘rnatish ikki qismga bo‘linadi: klasterga proxy-komponent + lokal kubectl-plagin.
1) Klasterga proxy’ni o‘rnatish
Repo’dagi quick start’da manifestlarni kustomize orqali qo‘llash (odatda kube-system’da) taklif qilinadi. Buyruq, shuningdek, odatiy kubectl exec’ni o‘chirib qo‘yadigan webhook’ni ham qo‘shadi.
kustomize build manifests/ | kubectl -n kube-system apply -f -2) kubectl-plagin’ni o‘rnatish
Getting started’dagi tezkor variant — plagin’ni go install orqali o‘rnatish va binarilar joylashgan katalog PATH’da ekanini tekshirish.
go install github.com/adyen/kubectl-rexec@latest3) Hodisalar yozilayotganini tekshirish
Tekshiruv uchun proxy-komponent loglarini ko‘rish mumkin (keyin odatda ularni markaziy log saqlash tizimiga yuborishadi).
kubectl -n kube-system logs -l app=rexec -fFoydalanish
Plagin oddiy kubectl exec parametrlarini takrorlaydi, faqat chaqirish ko‘rinishi kubectl rexec exec ... bo‘ladi.
Misol 1: interaktiv bash sessiya
kubectl rexec exec -ti some-pod -- bashMisol 2: TTY’siz bitta buyruqni bajarish
kubectl rexec exec some-pod -- sh -c "id && uname -a"Misol 3: namespace va container’ni tanlash
kubectl -n production rexec exec -ti pod-name -c app -- shReal jarayonlarda qo‘llash misollari
- “Break-glass” kirish: rexec’ga huquqni cheklangan guruhga berasiz, odatiy exec’ni esa webhook orqali bloklaysiz.
- Insidentlar: tergov vaqtida faqat “kim kirganini” emas, balki exec’dan qolgan hodisalar/izni ko‘rasiz va buni ilova loglari bilan solishtira olasiz.
- Operatsion o‘zgarishlar: jamoa majburan qo‘lbola hotfix qilsa ham, audit-treyl saqlanadi va “prod’dagi qora sehr” kamayadi.
Qayerda qulay joylashtirish va audit’ni yo‘qotmaslik
kubectl-rexec self-managed Kubernetes’da ayniqsa foydali: klasterni VM’larda ko‘tarasiz va xavfsizlik hamda audit uchun o‘zingiz javob berasiz. Serverspace.uz’da control plane/worker node’lar uchun bulut serverlarini tezda ishga tushirib, rexec proxy audit-loglarini o‘zingizning log tizimingizga (masalan, Loki/ELK) proksi qilishingiz mumkin — shunda node’lar qayta yaratilsa ham exec-sessiyalar izi yo‘qolmaydi.
Cloud Servers: https://serverspace.uz/services/cloud-servers/
FAQ
kubectl-rexec Kubernetes Audit Logs’ni to‘liq almashtiradimi?
Yo‘q. Kubernetes audit baribir kerak: API’ga murojaat faktlari (kim/qachon/nimaga) uchun. kubectl-rexec esa exec oqimi atrofida yetishmayotgan qismni proksilash va o‘z darajasida auditi mumkin bo‘lgan hodisalar orqali to‘ldiradi.
Nega shunchaki pods/exec audit loglarini ko‘rish yetarli emas?
Oddiy audit exec so‘rovi bo‘lganini qayd etadi, lekin interaktiv sessiya ichida “nima qilinganini” to‘liq va shaffof ko‘rsatmaydi. Loyihaning yopmoqchi bo‘lgan muammosi ham shu.
Kubernetes’ning minimal versiyasi qaysi?
README’da: exec websocket orqali ishlaydigan klasterlar qo‘llanadi — Kubernetes 1.30 (default) yoki 1.29 va TranslateStreamCloseWebsocketRequests=true yoqilgan bo‘lishi shart; 1.29’dan past — qo‘llanmaydi.
rexec’ning “audit-hodisalari”ni qayerdan ko‘raman?
Quick start’da proxy loglaridan boshlash tavsiya qilinadi (kubectl -n kube-system logs -l app=rexec -f), keyin esa loglarni markaziy tizimga yetkazib berishni sozlaysiz.
Shpargalka: kubectl’ning asosiy buyruqlari
| Vazifa | Buyruq | Izoh |
|---|---|---|
| Joriy kontekstni tekshirish | kubectl config current-context | Hozir qaysi klaster bilan ishlayotganingizni ko‘rsatadi |
| Barcha kontekstlarni ko‘rish | kubectl config get-contexts | Bir nechta klaster/muhit bo‘lsa qulay |
| Kontekstni almashtirish | kubectl config use-context <context> | Ehtiyot bo‘ling: “noto‘g‘ri joyga” tushib qolish oson |
| Namespace ro‘yxati | kubectl get ns | Muhitlar bo‘yicha tezkor ko‘rinish |
| Namespace’dagi podlar | kubectl -n <ns> get pods | Node va IP’larni ko‘rish uchun -o wide qo‘shing |
| Namespace’dagi asosiy resurslar | kubectl -n <ns> get pods,svc,deploy | Muhit bo‘yicha eng tez “health-check” |
| Pod’ni tavsiflash (hodisalar/tafsilotlar) | kubectl -n <ns> describe pod <pod> | CrashLoopBackOff va image/secret muammolarida foydali |
| Konteyner loglari | kubectl -n <ns> logs <pod> -c <container> | Qulaylik uchun -f va --tail=200 qo‘shing |
| Oldingi konteyner loglari | kubectl -n <ns> logs <pod> -c <container> --previous | Konteyner tez yiqilganda juda foydali |
| Exec (oddiy) | kubectl -n <ns> exec -ti <pod> -- sh | rexec webhook’i tomonidan bloklanishi mumkin |
| Exec (rexec orqali audit qilinadigan) | kubectl -n <ns> rexec exec -ti <pod> -- sh | kubectl-rexec yoqilganida tavsiya etiladigan variant |
| Servisga port-forward | kubectl -n <ns> port-forward svc/<svc> 8080:80 | Ingress’siz lokal kirishni tez ochish |
| Pod’ga port-forward | kubectl -n <ns> port-forward pod/<pod> 8080:8080 | Muayyan instans’ni debug qilish uchun foydali |
| Manifestni qo‘llash | kubectl apply -f file.yaml | Resurslarni yaratish/yangilash |
| Apply’dan oldin diff | kubectl diff -f file.yaml | Nima o‘zgarishini tushunish |
| Deploy rollout holati | kubectl -n <ns> rollout status deploy/<name> | Vykatni nazorat qilish |
| Deploy’ni qaytarish (rollback) | kubectl -n <ns> rollout undo deploy/<name> | Oldingi reviziyani qaytarish |
| Namespace’dagi hodisalar | kubectl -n <ns> get events --sort-by=.lastTimestamp | Pending/Failed sabablarini tez topish |
| Huquqlarni tekshirish (RBAC) | kubectl auth can-i create pods/exec -n <ns> | Kim exec qila olishini tushunish |
Xulosa
kubectl-rexec — Kubernetes audit’ining o‘zi yetarli bo‘lmagan joylarda kubectl exec atrofida audit qo‘shishning amaliy usuli. U validating webhook orqali “oddiy” exec’ni bloklash va exec’ni APIService orqali proksi qilishga tayanadi — shu yerda audit-hodisalarni shakllantirish mumkin bo‘ladi. Tez start uchun klasterga proxy’ni o‘rnating (kustomize → kube-system), kubectl-plagin’ni o‘rnating va proxy loglarini markaziy saqlash tizimiga yig‘ishni sozlang.
