اگر یک container در Kubernetes هک بشه، خطر فقط برای همون application نیست؛ سؤال اصلی اینه که اون container بعد از compromise شدن، چه دسترسی‌هایی داره.
آیا می‌تونه Secretهای دیگر را بخوونه؟ به Kubernetes API دسترسی داره؟ می‌تونه با سرویس‌های namespaceهای دیگر ارتباط برقرار کنه؟ با کاربر root یا تنظیمات privileged اجرا میشه؟
امنیت Kubernetes فقط به اسکن image محدود نمی‌شه. Service Account، RBAC، NetworkPolicy، محدودیت‌های runtime و مدیریت Secretها تعیین می‌کنه یک حادثهٔ کوچک در چه نقطه‌ای متوقف بشه یا به کل محیط گسترش پیدا کنه.
بهترین رویکرد اینه که هر workload فقط حداقل دسترسی لازم را داشته باشه و در صورت compromise شدن، دامنهٔ خسارت اون محدود بمونه.
در مقالهٔ زیر، مسیرهای رایج حرکت جانبی(Lateral Movement) در Kubernetes و راه‌های عملی کاهش این ریسک را بررسی کردم.
https://vrgl.ir/nku2V


@DevTwitter | <Sepehr Fassihi/>