متخصصان میگویند که معماری Kubernetes به آن اجازه میدهد تا به راحتی از شکستهای مختلف جان سالم به در ببرد و بدون توجه به هر چیزی فعال بماند، که آن را به گزینهای عالی برای pentesting تبدیل میکند. در مورد نحوه انجام چندین حمله هک بر روی Kubernetes، از جمله خراب کردن یک خوشه، حذف یک گواهی، و اتصال یک گره، همه بدون توقف برای سرویس های در حال اجرا. دعوت به اقدام اجزاء:
و غیره: به عنوان پایگاه داده استفاده میشود
kube-apiserver: API و قلب خوشه
kube-controller-manager: برای استقرار در منابع Kubernetes
kube-scheduler[19]5 Master: kubelets: برای اجرای کانتینرها به طور مستقیم بر روی هاست
هر یک از این مؤلفهها توسط مجموعهای از گواهیهای TLS، کلاینت و سرور محافظت میشوند که هدف آنها تأیید اعتبار و تأیید مؤلفهها در بین خود است.
این منابع ذخیره نمیشوند. در هر نقطه از پایگاه داده Kubernetes، به جز در موارد خاص، اما به صورت فایل های معمولی ارائه می شوند:
کامپوننتها بهعنوان پادهای ثابت از دایرکتوری /etc/kubernetes/manifests/ توصیف میشوند و روی Masters اجرا میشوند.
مهمترین چیز این است که بدانید چگونه بسازید. یک خوشه عملکردی از همه اینها. بیایید تصور کنیم که اجزای Kubernetes ذکر شده در بالا به نحوی با یکدیگر تعامل دارند. Pentesters ابزار توزیع خود را ذکر میکنند، خواه kubeadm، kubespray یا چیز دیگری باشد. که ما قبلاً یک خوشه داریم.
اجازه دهید با جالبترین آنها شروع کنیم:[19659017]rm -rf /etc/kubernetes/
این دایرکتوری برای گره اصلی شامل:
مجموعه گواهینامه ها و CA برای etcd (c/etc /kubernetes/pki/etcd)
گواهی و مجموعه CA برای Kubernetes (c/etc/kubernetes/pki)
Kubeconfig برای cluster-admin، kube-controller-manager، kube-Scheduler و kubelet (هر کدام یک گواهی نیز دارند base64 CA رمزگذاری شده برای خوشه ما /etc/kubernetes/*.conf)
مجموعه مانیفست های استاتیک برای etcd، kube-apiserver، kube-Scheduler و kube-controller-manager (c/etc/kubernetes/manifests)[0115]69 فرض کنید همه چیز را به یکباره از دست دادیم.
رفع مشکلات هواپیمای کنترل
برای جلوگیری از سردرگمی، محققان توصیه میکنند مطمئن شوید که تمام غلافهای هواپیمای کنترلی ما نیز متوقف شدهاند:
crictl rm `crictl ps -aq`
توجه داشته باشید که kubeadm گواهیها و kubeconfigهای موجود را بهطور پیشفرض رونویسی نمیکند، بنابراین برای صدور مجدد آنها، ابتدا باید آنها را به صورت دستی حذف کنید. سپس خوشه etcd بدون وجود اکثر آنها شروع نمیشود.
kubeadm init stage certs etcd-ca
دستور بالا یک CA جدید برای خوشه etcd ما ایجاد می کند. آن را به همراه کلید خصوصی بقیه گره های اصلی:
/etc/kubernetes/pki/etcd/ca. {key,crt
حالا اجازه دهید بقیه گواهیهای etcd و مانیفستهای استاتیک را در همه گرهها در صفحه کنترل بازسازی کنیم: گواهیهای فاز etcd-peer
kubeadm init stage servers و غیره
kubeadm init فاز etcd محلی
در این مرحله باید یک خوشه etcd در حال اجرا داشته باشیم:[19659047] Container ID Image Created State Name Attempt Pod ID [1945904] 0369CF4303FFD 2 ثانیه پیش در حال اجرا ETCD 0 BC8B4D568751B
اکنون ما همین کار را انجام خواهیم داد، اما برای کوبرنت ها، در یکی از Node اصلی این کار را انجام می دهد:
kubeadm تمام گواهی های فاز اولیه
فاز اولیه kubeadm kubeconfig همه
kubeadm init stage control-plane all
cp -f /etc/kubernetes/admin.conf ~/.kube/config
دستورات بالا تمام گواهیهای SSL را برای خوشه Kubernetes ما، و همچنین آمار مانیفست و kubeconfig برای سرویسهای Kubernetes تولید میکنند.
اگر شما هستید. با استفاده از kubeadm برای پیوستن به kubelets، شما همچنین باید پیکربندی اطلاعات خوشه را در فضای نام kube-public که همچنان حاوی هش CA قدیمی شما است، به روز کنید، آنها را در گره های اصلی دیگر کپی کنید و دستورات بالا را در هر یک از آنها تکرار کنید، متخصصان توصیه کنید.
بهعنوان جایگزینی برای کپی دستی گواهیها، اکنون میتوانید از رابط Kubernetes استفاده کنید، برای مثال از دستور زیر: به مدت 2 ساعت، پس از آن میتوانید به Masters مانند این بپیوندید:
kubeadm join فاز کنترل هواپیما-آماده سازی همه kubernetes-apiserver: 6443 --control هواپیما --token cs0etm.ua7fbmwuf1jz946l --discovery-رمز-CA-SHA256 CERT-هش: 555f6ececd4721fed0269d27a5c7f1c6d7ef4614157a18e56ed9a1fd031a3ab8 --certificate کلید 385655ee0ab98d2441ba8038b4e8d03184df1806733eac131511891d1096be73
kubeadm join stage control-plane-join all [19659057] لازم به ذکر است که در Kubernetes API، پیکربندی دیگری وجود دارد که دارای گواهینامه CA برای یک کلاینت پروکسی جلویی است که برای احراز هویت درخواست های apiserver به وب هوک ها و سایر سرویس های لایه تجمیع استفاده می شود.
خوشبختانه، kube- apiserver آن را به طور خودکار به روز می کند.
با این حال، ممکن است بخواهید به صورت دستی آن را از گواهی های قدیمی پاک کنید:
kubectl get cm -n kube-system extension-apiserver-authentication -o yaml
به هر حال، در این مرحله ما داریم در حال حاضر یک صفحه کنترل کاملاً کارآمد وجود دارد.
تثبیت گره کارگر
این دستور همه گرهها را در خوشه فهرست میکند، اگرچه اکنون همه آنها در حالت NotReady خواهند بود:
kubectl get node
این به این دلیل است که همه آنها هنوز از گواهی های قدیمی استفاده می کنند و منتظر درخواست هایی از سرور هستند که توسط CA قدیمی امضا شده است. /var/lib/kubelet/pki/ /etc/kubernetes/kubelet.conf
فاز init kubeadm kubeconfig kubelet
kubeadm فاز init kubelet-start
سپس برای کارگران، یک توکن جدید تولید خواهیم کرد:
kubeadm tok en --print-join-command
و روی هر یک از آنها اجرا می کنیم: lib/kubelet/pki/ /etc/kubernetes/pki/ /etc/kubernetes/kubelet.conf
kubeadm عضویت فاز kubelet شروع kubernetes-apiserver: 6443 --token cs0etm.ua7fbmwuf1jz946l --discovery - رمز-CA-CERT-هش SHA256: kublets خود را 555f6ececd4721fed0269d27a5c7f1c6d7ef4614157a18e56ed9a1fd031a3ab8 به خوشه بدون تاثیر ظروف در حال حاضر در حال اجرا در آنها گره های خوشه ای .
به برای جلوگیری از این امر، میتوانیم به طور موقت آن را روی Masters متوقف کنیم: manager -q`
آخرین فرمان فقط برای اطمینان از اینکه Controller-Manager واقعاً در حال اجرا نیست. متصل هستند، میتوانیم یک مانیفست استاتیک برای باطن ایجاد کنیم.
برای انجام این کار، باید اجرا کنید: مرحله ای که قبلاً نشانه join را ایجاد کرده اید. در غیر این صورت، هنگام تلاش برای خواندن نشانه Cluster-info، عملیات اتصال از کار می افتد.
اگر kubelet برای دریافت گواهی امضا شده توسط CA پیکربندی شده باشد (سرور TLSBootstrap اختیاری: true)، همچنین باید kubelets خود را تأیید کنید. csr:
kubectl دریافت csr
گواهی kubectl تایید
بازیابی حسابهای سرویس
بازیابی حسابهای سرویس
. pki/sa.key، کارشناسان خاطرنشان میکنند که این همان کلیدی است که توکنهای jwt را برای همه حسابهای خدمات ما امضا میکند، بنابراین باید توکنها را برای هر یک از آنها بازسازی کنیم.
این کار را میتوان به سادگی با حذف فیلد نشانه انجام داد. از همه kubernetes secrets.io/service-account-token :
بعد از آن، kube-controller-manager به طور خودکار توکنهای جدید امضا شده با کلید جدید تولید میکند.
متأسفانه، همه میکروسرویسها نمیتوانند توکن را در جریان بازخوانی کنند، و به احتمال زیاد مجبور خواهید بود به صورت دستی مجدداً راهاندازی کنید. کانتینرهایی که در آنها استفاده می شود:
kubectl get pod --field-selector 'spec.serviceAccountName!=default' --no-headers --all-namespaces | awk '{print "kubectl delete pod -n " $1 " " $2 " --wait=false --grace-period=0"}'
به عنوان مثال، این دستور فهرستی از دستورات را برای حذف همه ایجاد می کند پادها با استفاده از یک حساب سرویس سفارشی .
توصیه می کنم با فضای نام سیستم kube شروع کنید. همچنین: