امنیت Kubernetes چیست؟ مهم‌ترین اصول امن‌سازی Kubernetes و کلاسترهای وب
امنیت Kubernetes مجموعه‌ای از اصول و کنترل‌های حفاظتی برای ایمن‌سازی کلاسترها، کانتینرها، شبکه و اطلاعات حساس در زیرساخت‌های وب است. تنظیمات نادرست RBAC، مجوزهای بیش‌ازحد Podها، ارتباطات شبکه‌ای نامحدود و مدیریت ناامن Secrets می‌توانند زمینه دسترسی غیرمجاز و گسترش حملات را فراهم کنند. استفاده از Pod Security Standards، NetworkPolicy، رمزنگاری داده‌ها، اسکن تصاویر کانتینری و مانیتورینگ امنیتی از مهم‌ترین روش‌های کاهش این خطرات است.
امنیت Kubernetes به مجموعه‌ای از سیاست‌ها، تنظیمات و روش‌های حفاظتی گفته می‌شود که از کلاسترهای Kubernetes، کانتینرها، سرویس‌ها، شبکه، اطلاعات محرمانه و زیرساخت میزبانی در برابر دسترسی غیرمجاز، سوءاستفاده از منابع و حملات سایبری محافظت می‌کنند. مهم‌ترین اصول امن‌سازی Kubernetes شامل کنترل دسترسی با RBAC، محدودسازی مجوزهای Pod، جداسازی شبکه، حفاظت از Secrets، ایمن‌سازی Control Plane، بررسی تصاویر کانتینری و پایش مداوم فعالیت‌های کلاستر است.
مقدمه: چرا امنیت Kubernetes به یکی از چالش‌های مهم زیرساخت وب تبدیل شده است؟
گسترش معماری‌های Cloud Native، استفاده از Microservices و افزایش نیاز سازمان‌ها به استقرار سریع نرم‌افزار باعث شده است Kubernetes به یکی از مهم‌ترین فناوری‌های مدیریت زیرساخت‌های کانتینری تبدیل شود.
این پلتفرم به تیم‌های توسعه و عملیات اجازه می‌دهد صدها یا هزاران کانتینر را مدیریت کنند، سرویس‌ها را به‌صورت خودکار مقیاس دهند و در صورت بروز اختلال، بخش‌هایی از زیرساخت را بازیابی کنند.
اما همین قدرت مدیریتی، چالش امنیتی مهمی ایجاد می‌کند.
در معماری سنتی، ممکن است یک وب‌سایت روی یک سرور مشخص اجرا شود و مدیر سیستم با تنظیم فایروال، محدودسازی SSH و به‌روزرسانی نرم‌افزارها بخش قابل‌توجهی از سطح حمله را کنترل کند.
در Kubernetes شرایط متفاوت است.
یک درخواست ساده از کاربران اینترنت ممکن است از چندین جزء عبور کند: Load Balancer، Ingress Controller، سرویس وب، Pod برنامه، سرویس احراز هویت و پایگاه داده.
هرکدام از این اجزا تنظیمات، مجوزها، ارتباطات شبکه‌ای و وابستگی‌های امنیتی مخصوص خود را دارند.
اگر مهاجمی بتواند یکی از سرویس‌ها را به خطر بیندازد، میزان خسارت به این بستگی دارد که آن سرویس چه مجوزهایی دارد و تا چه اندازه از سایر قسمت‌های زیرساخت جدا شده است.
برای مثال، آسیب‌پذیری در یک وب‌اپلیکیشن ممکن است فقط به همان کانتینر محدود بماند؛ اما اگر کانتینر دسترسی مدیریتی گسترده، اطلاعات محرمانه یا ارتباط آزاد با سایر سرویس‌ها داشته باشد، دامنه حادثه می‌تواند بسیار بزرگ‌تر شود.
بنابراین، امنیت Kubernetes صرفاً به جلوگیری از نفوذ اولیه محدود نمی‌شود؛ بلکه باید مانع گسترش نفوذ، سرقت اطلاعات و تبدیل یک آسیب‌پذیری کوچک به بحران زیرساختی شود.
در این راهنما، معماری امنیتی Kubernetes، مهم‌ترین تهدیدهای کلاسترهای وب و روش‌های عملی کاهش ریسک را بررسی می‌کنیم.
Kubernetes چیست و چگونه کار می‌کند؟
Kubernetes که معمولاً با نام K8s شناخته می‌شود، یک پلتفرم متن‌باز برای مدیریت، استقرار، مقیاس‌پذیری و هماهنگ‌سازی برنامه‌های کانتینری است.
به‌جای اجرای مستقیم برنامه روی یک سرور، Kubernetes امکان می‌دهد برنامه‌ها در قالب کانتینرهای قابل‌مدیریت روی مجموعه‌ای از ماشین‌ها اجرا شوند.
به این مجموعه ماشین‌ها و اجزای مدیریتی، کلاستر Kubernetes گفته می‌شود. 
اجزای اصلی معماری Kubernetes
برای درک امنیت Kubernetes باید ابتدا نقش اجزای اصلی آن را بشناسیم.
Control Plane: بخش مدیریتی کلاستر است که تصمیم‌های مربوط به زمان‌بندی، وضعیت منابع و هماهنگی اجزا را کنترل می‌کند.
API Server: درگاه اصلی ارتباط با Kubernetes است. درخواست‌های مدیریتی، تغییر منابع و بسیاری از عملیات کلاستر از این بخش عبور می‌کنند.
etcd: پایگاه داده کلید-مقدار Kubernetes است که وضعیت کلاستر و اطلاعات پیکربندی را نگهداری می‌کند.
Scheduler: مشخص می‌کند Podهای جدید روی کدام Node اجرا شوند.
Controller Manager: کنترل‌کننده‌هایی را اجرا می‌کند که وضعیت واقعی کلاستر را به وضعیت مطلوب نزدیک می‌کنند.
Worker Node: ماشین فیزیکی یا مجازی است که برنامه‌ها و کانتینرها روی آن اجرا می‌شوند.
Kubelet: عامل موجود روی Node است که اجرای Podها و ارتباط با Control Plane را مدیریت می‌کند.
Pod: کوچک‌ترین واحد استقرار Kubernetes است که می‌تواند یک یا چند کانتینر مرتبط داشته باشد.
Service: دسترسی پایدار و منطقی به مجموعه‌ای از Podها را فراهم می‌کند.
Ingress یا Gateway: مسیر ورود و هدایت درخواست‌های شبکه به سرویس‌های داخل کلاستر را مدیریت می‌کند.
Namespace: محدوده‌ای منطقی برای سازمان‌دهی منابع و اعمال برخی کنترل‌های دسترسی و سیاست‌های امنیتی ایجاد می‌کند.
هرکدام از این بخش‌ها می‌توانند در صورت پیکربندی اشتباه به نقطه ضعف امنیتی تبدیل شوند.
چرا معماری توزیع‌شده امنیت را پیچیده می‌کند؟
در یک زیرساخت توزیع‌شده، امنیت فقط به وضعیت یک ماشین وابسته نیست.
ممکن است سیستم‌عامل تمام سرورها به‌روزرسانی شده باشد، اما یک ServiceAccount مجوزهای بیش‌ازحد داشته باشد.
یا ممکن است برنامه از HTTPS استفاده کند، ولی ارتباط داخلی بین سرویس‌ها بدون احراز هویت مناسب برقرار شود.
همچنین اضافه‌شدن خودکار Podها، تغییر Nodeها و انتشار نسخه‌های جدید نرم‌افزار باعث می‌شود وضعیت امنیتی محیط دائماً تغییر کند.
به همین دلیل، امنیت Kubernetes باید بر پایه سیاست‌های قابل‌تکرار، خودکار و قابل‌اندازه‌گیری طراحی شود. 
مهم‌ترین تهدیدهای امنیتی Kubernetes کدام‌اند؟
تهدیدهای Kubernetes را می‌توان در چند گروه اصلی دسته‌بندی کرد.
دسترسی غیرمجاز به API Server
API Server یکی از حساس‌ترین اجزای کلاستر است.
اگر مهاجم به اطلاعات احراز هویت معتبر دست پیدا کند یا تنظیمات دسترسی بیش‌ازحد باز باشند، ممکن است بتواند منابع کلاستر را مشاهده، ایجاد یا تغییر دهد.
البته میزان خسارت به سطح مجوزهای هویت مورد استفاده بستگی دارد.
دسترسی محدود به یک Namespace با دسترسی مدیریتی به کل کلاستر یکسان نیست.
افزایش سطح دسترسی یا Privilege Escalation
افزایش سطح دسترسی زمانی رخ می‌دهد که یک کاربر یا سرویس بتواند از اختیارات اولیه خود فراتر برود.
در Kubernetes، مجوز ایجاد یا تغییر بعضی از منابع می‌تواند به‌صورت غیرمستقیم دسترسی‌های قدرتمندی ایجاد کند.
برای مثال، کاربری که توانایی ایجاد Pod با تنظیمات دلخواه را دارد، ممکن است بتواند از طریق آن به اطلاعات یا قابلیت‌هایی دسترسی پیدا کند که مجوز مشاهده مستقیمشان را ندارد.
بنابراین، صرفاً محدودسازی مجوز خواندن منابع برای جلوگیری از افزایش سطح دسترسی کافی نیست.
اجرای کانتینرهای ناامن
کانتینرهایی که با کاربر Root اجرا می‌شوند، قابلیت‌های سیستمی غیرضروری دارند یا به مسیرهای حساس میزبان دسترسی پیدا می‌کنند، سطح حمله را افزایش می‌دهند.
این وضعیت به معنای فرار قطعی از کانتینر نیست؛ اما ممکن است در کنار آسیب‌پذیری‌های دیگر، شدت حادثه را بیشتر کند.
جابه‌جایی جانبی در شبکه
Lateral Movement یا حرکت جانبی به تلاش مهاجم برای گسترش دسترسی از یک سرویس آلوده به سایر سرویس‌ها گفته می‌شود.
برای مثال، نفوذ به یک سرویس عمومی نباید به معنای امکان ارتباط آزاد با پایگاه داده، سامانه پرداخت یا زیرساخت مدیریتی باشد.
افشای Secrets و اطلاعات محرمانه
رمزهای پایگاه داده، کلیدهای API، گواهی‌های خصوصی و توکن‌های سرویس از مهم‌ترین اطلاعات حساس هستند.
ذخیره نامناسب این اطلاعات یا اعطای مجوزهای گسترده برای خواندن آن‌ها ممکن است باعث افشای اطلاعات و دسترسی غیرمجاز به سامانه‌های دیگر شود.
حملات زنجیره تأمین نرم‌افزار
Supply Chain Attack به حمله‌ای گفته می‌شود که از مسیر وابستگی‌های نرم‌افزاری، تصاویر کانتینری، ابزارهای ساخت یا مخازن توزیع نرم‌افزار انجام می‌شود.
حتی اگر کد اصلی یک برنامه امن باشد، یک وابستگی آلوده یا تصویر کانتینری آسیب‌پذیر می‌تواند امنیت محیط اجرا را تهدید کند.
اصول بنیادین امنیت Kubernetes
پیش از بررسی تنظیمات فنی، لازم است چند اصل مهم در طراحی معماری امنیتی کلاستر رعایت شود.
اصل حداقل دسترسی یا Least Privilege
هر کاربر، سرویس و کانتینر باید فقط مجوزهایی را دریافت کند که برای انجام وظیفه خود لازم دارد.
برای نمونه، یک وب‌اپلیکیشن که فقط نیازمند پاسخ‌گویی به درخواست‌های HTTP است، معمولاً به دسترسی مدیریتی Kubernetes احتیاج ندارد.
اگر برنامه نیازی به ارتباط با API Server ندارد، بهتر است توکن مربوط به ServiceAccount نیز به آن ارائه نشود.
این اصل باعث کاهش دامنه خسارت در صورت نفوذ می‌شود.
دفاع چندلایه یا Defense in Depth
هیچ ابزار امنیتی به‌تنهایی نمی‌تواند تمام تهدیدها را برطرف کند.
فایروال شبکه نمی‌تواند جایگزین کنترل دسترسی Kubernetes شود.
WAF نیز جایگزین مدیریت Secrets یا ایمن‌سازی کانتینرها نیست.
در معماری دفاع چندلایه، هر کنترل امنیتی بخشی از تهدید را محدود می‌کند.
اگر یک لایه شکست بخورد، سایر لایه‌ها باید همچنان مانع گسترش حادثه شوند.
اصل اعتماد صفر یا Zero Trust
در مدل Zero Trust، قرارگرفتن یک سرویس داخل شبکه سازمان به معنای قابل‌اعتمادبودن آن نیست.
هویت، مجوز و شرایط هر ارتباط باید متناسب با حساسیت سرویس بررسی شود.
این اصل به‌ویژه در محیط‌هایی اهمیت دارد که چندین Microservice با یکدیگر ارتباط برقرار می‌کنند.
کاهش سطح حمله یا Attack Surface Reduction
هر سرویس غیرضروری، درگاه باز، قابلیت اضافی یا حساب کاربری بلااستفاده می‌تواند سطح حمله را افزایش دهد.
حذف اجزای غیرضروری یکی از ساده‌ترین و درعین‌حال مؤثرترین روش‌های کاهش ریسک است.
امنیت به‌عنوان کد یا Security as Code
در Kubernetes بهتر است تنظیمات امنیتی به‌صورت فایل‌های نسخه‌بندی‌شده و سیاست‌های خودکار مدیریت شوند.
این رویکرد کمک می‌کند تغییرات قابل‌بررسی باشند و تنظیمات ناامن به‌صورت اتفاقی وارد محیط عملیاتی نشوند. 
ایمن‌سازی Control Plane در Kubernetes
Control Plane مرکز کنترل کلاستر است و حفاظت از آن باید در اولویت قرار گیرد.
محدودسازی دسترسی به Kubernetes API Server
اولین اقدام، تعیین دقیق افرادی و سرویس‌هایی است که مجاز به ارتباط با API Server هستند.
در کلاسترهای عملیاتی بهتر است دسترسی مدیریتی از شبکه‌های مشخص، مسیرهای خصوصی یا زیرساخت دسترسی امن انجام شود.
استفاده از VPN سازمانی، Bastion Host یا اتصال خصوصی مدیریت‌شده می‌تواند سطح دسترسی شبکه‌ای را کاهش دهد.
همچنین باید بررسی شود که API Server ناخواسته از اینترنت عمومی قابل‌دسترسی نباشد.
این توصیه به معنای حذف تمام دسترسی‌های خارجی نیست؛ بلکه هر دسترسی باید بر اساس نیاز عملیاتی تعریف و محافظت شود.
استفاده از TLS برای ارتباطات مدیریتی
TLS یا Transport Layer Security وظیفه محافظت از محرمانگی و یکپارچگی ارتباطات شبکه را بر عهده دارد.
ارتباط کاربران و اجزای مدیریتی با API Server باید با TLS معتبر محافظت شود.
در موارد لازم، استفاده از Mutual TLS یا mTLS باعث می‌شود دو طرف ارتباط بتوانند هویت یکدیگر را نیز با گواهی دیجیتال بررسی کنند.
گواهی‌ها باید از منابع معتبر صادر شوند، دوره اعتبار مشخص داشته باشند و پیش از انقضا تمدید شوند.
غیرفعال‌کردن اعتبارسنجی گواهی برای رفع سریع خطاهای اتصال، راهکار مناسبی برای محیط عملیاتی نیست.
حفاظت از پایگاه داده etcd
پایگاه داده etcd اطلاعات بسیار حساسی درباره وضعیت کلاستر ذخیره می‌کند.
بسته به پیکربندی، این اطلاعات ممکن است شامل Secrets و سایر داده‌های مهم Kubernetes باشد.
مهم‌ترین اقدامات حفاظتی عبارت‌اند از:
- جلوگیری از دسترسی مستقیم و غیرضروری به etcd از شبکه عمومی
- استفاده از احراز هویت و ارتباط رمزنگاری‌شده بین اجزای مجاز
- محدودسازی دسترسی سیستم‌عاملی و مدیریتی به محل ذخیره اطلاعات
- محافظت از فایل‌های پشتیبان و کلیدهای رمزنگاری
- بررسی وضعیت سلامت و ثبت رویدادهای امنیتی مرتبط
نکته مهم این است که رمزنگاری دیسک یا ارتباطات شبکه به‌تنهایی جایگزین کنترل مجوز دسترسی به داده‌های etcd نمی‌شود.
محافظت از اجزای مدیریتی دیگر
Scheduler، Controller Manager و سایر اجزای Control Plane نیز باید با تنظیمات مناسب اجرا شوند.
نباید فرض کرد که چون یک جزء مستقیماً درخواست کاربران اینترنت را دریافت نمی‌کند، نیازی به ایمن‌سازی ندارد.
کنترل هویت سرویس‌ها، محافظت از فایل‌های تنظیمات و محدودسازی دسترسی به نقاط مدیریتی اهمیت زیادی دارد.
در کلاسترهای مدیریت‌شده، بخشی از مسئولیت حفاظت Control Plane بر عهده ارائه‌دهنده سرویس است؛ اما تنظیمات دسترسی و امنیت Workloadها همچنان باید بررسی شوند. 
مدیریت دسترسی کاربران با RBAC در Kubernetes
یکی از اساسی‌ترین اجزای امنیت Kubernetes، کنترل مجوزهای کاربران و سرویس‌ها است.
Kubernetes از سازوکاری با نام Role-Based Access Control یا RBAC برای تعریف مجوزها استفاده می‌کند.
RBAC چگونه کار می‌کند؟
RBAC بر پایه چند مفهوم اصلی طراحی شده است.
Role: مجموعه‌ای از مجوزها را در محدوده یک Namespace مشخص می‌کند.
ClusterRole: مجموعه‌ای از مجوزها را تعریف می‌کند که می‌تواند برای منابع کلاستری یا منابع یک Namespace استفاده شود.
RoleBinding: مجوزهای یک Role یا ClusterRole را در یک Namespace به هویت مشخص اختصاص می‌دهد.
ClusterRoleBinding: مجوزهای ClusterRole را در سطح کلاستر به هویت موردنظر متصل می‌کند.
هر مجوز معمولاً مشخص می‌کند چه عملیاتی روی چه نوع منابعی مجاز است.
برای مثال، ممکن است کاربری فقط اجازه مشاهده Podها را داشته باشد و نتواند آن‌ها را حذف یا تغییر دهد.
چرا مجوز cluster-admin خطرناک است؟
مجوز cluster-admin دسترسی بسیار گسترده‌ای به منابع Kubernetes فراهم می‌کند.
اختصاص دائمی این مجوز به حساب‌های توسعه‌دهندگان، برنامه‌ها یا ابزارهای جانبی می‌تواند خطرناک باشد.
چنانچه اطلاعات احراز هویت چنین حسابی افشا شود، مهاجم ممکن است به بخش بزرگی از کلاستر دسترسی پیدا کند.
بهتر است حساب‌های مدیریتی قدرتمند فقط برای عملیات مشخص و ضروری استفاده شوند.
همچنین استفاده از حساب‌های جداگانه برای امور روزمره و فعالیت‌های مدیریتی حساس، احتمال تغییرات ناخواسته را کاهش می‌دهد.
بهترین روش‌های پیکربندی RBAC
برای پیاده‌سازی اصولی RBAC بهتر است اقدامات زیر انجام شود:
- برای هر گروه کاری، نقش مشخص و محدود طراحی شود.
- مجوزها تا حد امکان در سطح Namespace تعریف شوند.
- از اعطای مجوزهای عمومی با علامت Wildcard بدون ضرورت خودداری شود.
- دسترسی به Secrets به‌صورت جداگانه و محدود بررسی شود.
- مجوز ایجاد و تغییر Pod، Deployment، Role و RoleBinding با دقت ارزیابی شود.
- دسترسی کاربران غیرفعال یا اعضای جداشده از تیم حذف شود.
- نقش‌ها و اتصال‌های دسترسی به‌صورت دوره‌ای بازبینی شوند.
نکته مهم اینکه بعضی مجوزهای ظاهراً محدود نیز می‌توانند دسترسی غیرمستقیم ایجاد کنند.
برای نمونه، امکان ایجاد Pod در یک Namespace ممکن است به دسترسی به Secrets قابل‌استفاده توسط همان Pod منجر شود.
بنابراین، ارزیابی RBAC نباید صرفاً بر نام مجوزها متکی باشد؛ بلکه باید پیامد واقعی هر مجوز بررسی شود.
احراز هویت کاربران و حساب‌های مدیریتی
RBAC وظیفه تعیین مجوز را بر عهده دارد، نه احراز هویت اولیه کاربر.
برای احراز هویت بهتر است از سازوکارهای قابل‌اعتماد سازمانی مانند OIDC و سامانه‌های مدیریت هویت استفاده شود.
استفاده از احراز هویت دومرحله‌ای یا 2FA در سامانه هویت متصل به Kubernetes، به کاهش خطر سوءاستفاده از حساب‌های مدیریتی کمک می‌کند.
فایل‌های Kubeconfig و اعتبارنامه‌های مدیریتی نیز باید مانند اطلاعات محرمانه محافظت شوند. 
امنیت Pod و کانتینرها در Kubernetes
Podها محل اجرای برنامه‌ها هستند؛ بنابراین بخش قابل‌توجهی از تهدیدهای عملیاتی در این قسمت شکل می‌گیرد.
جلوگیری از اجرای غیرضروری کانتینر با Root
اجرای برنامه با حساب Root ممکن است دسترسی بیشتری از نیاز واقعی سرویس فراهم کند.
بهتر است برنامه‌ها در صورت امکان با یک کاربر غیرممتاز اجرا شوند.
در Kubernetes می‌توان از تنظیماتی مانند runAsNonRoot و runAsUser برای کنترل هویت فرآیند استفاده کرد.
البته تغییر کاربر اجرایی باید با مجوزهای فایل‌ها و نیازهای برنامه سازگار باشد.
اجرای غیر Root به‌تنهایی امنیت کامل ایجاد نمی‌کند، اما بخشی مهم از کاهش اختیارات کانتینر است.
محدودسازی Linux Capabilities
سیستم‌عامل لینوکس برخی توانایی‌های قدرتمند را در قالب Capabilities مدیریت می‌کند.
کانتینرها ممکن است به بعضی از این قابلیت‌ها نیاز داشته باشند؛ اما ارائه قابلیت‌های غیرضروری سطح حمله را افزایش می‌دهد.
رویکرد مناسب این است که قابلیت‌های اضافی حذف شوند و فقط موارد ضروری به کانتینر اختصاص یابند.
همچنین باید از فعال‌کردن privileged: true برای برنامه‌های معمولی خودداری شود.
حالت Privileged می‌تواند محدودیت‌های امنیتی مهمی را کاهش دهد و باید فقط برای اجزای زیرساختی کاملاً ضروری و مورداعتماد استفاده شود.
جلوگیری از افزایش سطح دسترسی در زمان اجرا
گزینه allowPrivilegeEscalation: false می‌تواند بخشی از سیاست محدودسازی افزایش اختیارات فرآیند باشد.
همچنین استفاده از readOnlyRootFilesystem: true در برنامه‌های سازگار، امکان تغییر سیستم فایل اصلی کانتینر را محدود می‌کند.
برای برنامه‌هایی که نیاز به نوشتن فایل‌های موقت دارند، می‌توان مسیرهای مشخص و محدود برای این عملیات در نظر گرفت.
این تنظیمات باید متناسب با نوع برنامه آزمایش شوند تا باعث اختلال در سرویس نشوند.
استفاده از Seccomp، AppArmor و SELinux
سه فناوری مهم برای افزایش جداسازی و کنترل رفتار فرآیندها عبارت‌اند از:
Seccomp: با محدودسازی System Callهای قابل‌استفاده، بخشی از سطح حمله به هسته لینوکس را کاهش می‌دهد.
AppArmor: بر اساس پروفایل‌های امنیتی، دسترسی فرآیندها به منابع مشخص را کنترل می‌کند.
SELinux: با استفاده از سیاست‌های کنترل دسترسی اجباری یا Mandatory Access Control، محدودیت‌های امنیتی دقیق‌تری اعمال می‌کند.
این فناوری‌ها مکمل تنظیمات امنیتی Kubernetes هستند و بسته به سیستم‌عامل، Runtime و پیکربندی Node ممکن است امکانات متفاوتی داشته باشند.
استفاده از پروفایل RuntimeDefault برای Seccomp می‌تواند نقطه شروع مناسبی برای بسیاری از Workloadهای لینوکسی باشد.
Pod Security Standards چیست؟
Kubernetes مجموعه‌ای از استانداردهای امنیتی با نام Pod Security Standards یا PSS دارد.
این استانداردها سه سطح اصلی تعریف می‌کنند.
| سطح امنیتی | ویژگی اصلی | کاربرد |
|---|---|---|
| Privileged | محدودیت‌های امنیتی بسیار کم | برخی اجزای زیرساختی مورداعتماد |
| Baseline | جلوگیری از تنظیمات پرخطر شناخته‌شده | برنامه‌هایی که نیازمند سازگاری بیشتر هستند |
| Restricted | اعمال محدودیت‌های سخت‌گیرانه‌تر | بسیاری از برنامه‌های معمولی در محیط عملیاتی |
برای سرویس‌هایی که با محدودیت‌های سطح Restricted سازگار هستند، استفاده از این سطح می‌تواند انتخاب مناسبی باشد.
بااین‌حال، بعضی از اجزای شبکه، مانیتورینگ یا مدیریت Node ممکن است به مجوزهای خاص نیاز داشته باشند.
این موارد باید جداگانه بررسی شوند و مجوزهای اضافی فقط به همان اجزای ضروری داده شود.
Pod Security Admission چگونه به امنیت کمک می‌کند؟
Pod Security Admission سازوکاری داخلی در Kubernetes است که می‌تواند سیاست‌های Pod Security Standards را در سطح Namespace اعمال کند.
سه حالت مهم آن عبارت‌اند از:
enforce: جلوگیری از پذیرش Podهایی که سیاست را نقض می‌کنند.audit: ثبت اطلاعات مربوط به نقض سیاست برای بررسی.warn: نمایش هشدار هنگام درخواست‌های ناسازگار.
برای انتقال یک محیط موجود به سیاست Restricted، بهتر است ابتدا ناسازگاری‌ها شناسایی شوند.
اعمال ناگهانی محدودیت‌های سخت‌گیرانه بدون بررسی، ممکن است مانع استقرار یا به‌روزرسانی بعضی برنامه‌ها شود.
امنیت ServiceAccount و توکن‌های Kubernetes
ServiceAccount هویت مورد استفاده Workloadها برای تعامل با Kubernetes API را فراهم می‌کند.
هر Namespace دارای یک ServiceAccount پیش‌فرض است؛ اما این موضوع به معنای مناسب‌بودن آن برای تمام برنامه‌ها نیست.
چرا استفاده مشترک از ServiceAccount مناسب نیست؟
وقتی چندین برنامه از یک ServiceAccount مشترک استفاده می‌کنند، تفکیک مجوزها و بررسی فعالیت‌ها دشوارتر می‌شود.
برای سرویس‌هایی که واقعاً به Kubernetes API نیاز دارند، بهتر است ServiceAccount اختصاصی با حداقل مجوزهای لازم ساخته شود.
برای مثال، سامانه مانیتورینگ ممکن است مجوز مشاهده بعضی منابع را نیاز داشته باشد؛ اما یک وب‌سایت معمولی الزاماً نیازی به چنین دسترسی ندارد.
غیرفعال‌کردن Mount خودکار توکن
در برنامه‌هایی که نیازی به ارتباط با API Server ندارند، می‌توان از تنظیم زیر استفاده کرد:
automountServiceAccountToken: false
این تنظیم از ارائه خودکار اعتبارنامه ServiceAccount به Pod جلوگیری می‌کند.
در نتیجه، اگر برنامه آسیب ببیند، یکی از مسیرهای احتمالی دسترسی به API Server محدود می‌شود.
استفاده از توکن‌های کوتاه‌مدت
برای سرویس‌هایی که واقعاً به اعتبارنامه نیاز دارند، توکن‌های دارای دوره اعتبار محدود و قابلیت چرخش، گزینه مناسب‌تری نسبت به توکن‌های ثابت و بلندمدت هستند.
در نسخه‌های جدید Kubernetes، سازوکارهایی مانند TokenRequest و Projected Service Account Token برای این هدف وجود دارند.
مدیریت چرخه عمر اعتبارنامه‌ها یکی از بخش‌های مهم امنیت Kubernetes است.
مدیریت امن Secrets در Kubernetes
Secrets برای نگهداری اطلاعات حساس مانند رمز عبور، توکن، کلید API و برخی گواهی‌ها استفاده می‌شوند.
اما وجود یک شیء از نوع Secret به‌تنهایی تضمین نمی‌کند که اطلاعات در تمام مراحل ذخیره‌سازی و استفاده ایمن هستند.
تفاوت Secret و ConfigMap
ConfigMap برای ذخیره تنظیمات غیرمحرمانه برنامه طراحی شده است.
Secret برای داده‌هایی استفاده می‌شود که نیازمند حفاظت بیشتری هستند.
برای مثال، نام محیط اجرا یا تنظیمات عمومی برنامه می‌تواند در ConfigMap نگهداری شود؛ اما رمز اتصال پایگاه داده باید در سازوکار مناسب مدیریت اطلاعات محرمانه قرار گیرد.
یکی از نکات مهم این است که Base64 نوعی رمزنگاری امنیتی نیست.
نمایش داده‌های Secret به‌صورت Base64 نباید با حفاظت رمزنگاری‌شده اشتباه گرفته شود.
فعال‌سازی Encryption at Rest
Encryption at Rest به رمزنگاری اطلاعات هنگام ذخیره‌شدن روی رسانه‌های ذخیره‌سازی گفته می‌شود.
در Kubernetes، داده‌های API از جمله Secrets را می‌توان هنگام ذخیره در etcd رمزنگاری کرد.
پیکربندی پیش‌فرض در کلاسترهای مختلف ممکن است متفاوت باشد؛ بنابراین وضعیت واقعی رمزنگاری باید بررسی شود.
در محیط‌هایی با نیاز امنیتی بیشتر، استفاده از سامانه مدیریت کلید یا KMS می‌تواند مدیریت و حفاظت از کلیدهای رمزنگاری را تقویت کند.
باید توجه داشت که رمزنگاری اطلاعات در حالت ذخیره‌شده، مجوزهای نامناسب RBAC یا افشای داده پس از خواندن توسط برنامه را برطرف نمی‌کند.
جلوگیری از افشای Secrets در مخازن کد
قرارگرفتن رمز عبور یا کلید API در فایل‌های پروژه یکی از خطاهای خطرناک زنجیره توسعه است.
حتی اگر اطلاعات بعداً از نسخه فعلی حذف شوند، ممکن است همچنان در تاریخچه Git باقی مانده باشند.
برای کاهش این خطر باید از ذخیره اعتبارنامه‌های واقعی در مخازن عمومی و خصوصی بدون کنترل مناسب جلوگیری شود.
استفاده از ابزارهای Secret Scanning در فرایند CI/CD می‌تواند به شناسایی اشتباهات کمک کند.
استفاده از Secret Manager خارجی
در بعضی زیرساخت‌ها می‌توان مدیریت اطلاعات محرمانه را به سامانه‌های تخصصی سپرد.
برای نمونه، ابزارهایی مانند HashiCorp Vault یا سرویس‌های مدیریت Secret ارائه‌دهندگان ابری برای این هدف استفاده می‌شوند.
همچنین راهکارهایی مانند Secrets Store CSI Driver امکان ارائه اطلاعات محرمانه به Workloadها را از طریق سازوکارهای مشخص فراهم می‌کنند.
انتخاب چنین راهکاری باید براساس نیاز سازمان، مدل اعتماد، دسترس‌پذیری و قابلیت مدیریت کلید انجام شود.
چرخش دوره‌ای اعتبارنامه‌ها
Rotation یا چرخش اعتبارنامه به فرایند جایگزینی کنترل‌شده رمزها، کلیدها و توکن‌ها گفته می‌شود.
در محیط‌های حساس، بهتر است برنامه مشخصی برای تغییر اعتبارنامه‌ها وجود داشته باشد.
چرخش باید بدون ایجاد اختلال غیرضروری در سرویس انجام شود.
همچنین پس از افشای احتمالی یک Secret، تنها حذف فایل حاوی آن کافی نیست؛ اعتبارنامه مرتبط نیز باید باطل یا جایگزین شود. 
امنیت شبکه Kubernetes با NetworkPolicy
یکی از مهم‌ترین اصول امن‌سازی کلاسترهای وب، کنترل ارتباطات شبکه‌ای بین سرویس‌ها است.
در بسیاری از کلاسترها، اگر سیاست شبکه‌ای محدودکننده‌ای تعریف نشده باشد، Podها امکان برقراری ارتباط گسترده با سایر Podها را دارند.
این وضعیت می‌تواند حرکت جانبی مهاجم را آسان‌تر کند.
NetworkPolicy چیست؟
NetworkPolicy یک منبع Kubernetes برای تعریف ارتباطات مجاز شبکه در سطح Pod است.
این سیاست‌ها می‌توانند ترافیک ورودی یا Ingress و ترافیک خروجی یا Egress را محدود کنند.
برای مثال، می‌توان مشخص کرد که فقط Podهای برنامه وب اجازه ارتباط با سرویس Backend روی یک درگاه مشخص را داشته باشند.
یا سرویس پایگاه داده فقط درخواست‌های بخش Backend را بپذیرد.
نکته مهم اینکه NetworkPolicy استاندارد عمدتاً بر کنترل ترافیک لایه‌های ۳ و ۴ شبکه تمرکز دارد.
این قابلیت جایگزین احراز هویت برنامه، TLS یا WAF نیست.
نقش CNI در اجرای NetworkPolicy
Kubernetes به‌تنهایی اجرای تمام قوانین شبکه را تضمین نمی‌کند.
این سیاست‌ها باید توسط افزونه شبکه یا CNI پشتیبانی و اعمال شوند.
بنابراین، ایجاد یک NetworkPolicy بدون وجود پیاده‌سازی سازگار ممکن است هیچ محدودیتی در ترافیک ایجاد نکند.
برای بررسی امنیت شبکه باید علاوه بر تعریف سیاست، صحت اجرای واقعی آن نیز آزمایش شود.
سیاست Default Deny چیست؟
Default Deny به رویکردی گفته می‌شود که ارتباطات به‌صورت پیش‌فرض محدود می‌شوند و فقط مسیرهای ضروری مجاز خواهند بود.
برای مثال، یک Namespace شامل سرویس‌های وب می‌تواند ابتدا سیاستی داشته باشد که تمام ارتباطات ورودی و خروجی انتخاب‌شده را محدود کند.
سپس دسترسی‌های لازم برای DNS، ارتباط با Backend و سایر سرویس‌های ضروری اضافه شوند.
این روش از مدل دسترسی آزاد و محدودسازی موردی، قابل‌کنترل‌تر است.
البته باید توجه داشت که اعمال محدودیت خروجی بدون مجازکردن DNS ممکن است باعث اختلال در نام‌یابی سرویس‌ها شود.
بنابراین، پیاده‌سازی Default Deny باید مرحله‌ای و همراه با آزمایش انجام شود.
تفاوت امنیت Ingress و Egress
Ingress به ترافیکی اشاره دارد که وارد Pod می‌شود.
Egress ترافیکی است که از Pod به مقصد دیگری ارسال می‌شود.
کنترل هر دو جهت اهمیت دارد.
برای نمونه، محدودسازی Ingress یک پایگاه داده می‌تواند ارتباط سرویس‌های غیرمجاز با آن را کاهش دهد.
کنترل Egress از یک وب‌اپلیکیشن نیز می‌تواند ارتباطات خروجی غیرضروری را محدود کند.
در سناریوهای حساس، باید سیاست‌های مجازکننده ارتباط در دو سمت مسیر بررسی شوند.
تقسیم‌بندی شبکه بر اساس حساسیت سرویس‌ها
تمام سرویس‌های یک کلاستر سطح حساسیت یکسانی ندارند.
برای مثال، سامانه پرداخت، پنل مدیریت، پایگاه داده و وب‌سایت عمومی نیازهای امنیتی متفاوتی دارند.
می‌توان ارتباطات را به شکلی طراحی کرد که هر بخش فقط به سرویس‌های ضروری دسترسی داشته باشد.
این رویکرد که Microsegmentation نامیده می‌شود، به محدودسازی گسترش حادثه کمک می‌کند.
امنیت Ingress، Gateway و ارتباطات HTTPS
در کلاسترهای وب، بسیاری از درخواست‌های کاربران از طریق Ingress Controller یا Gateway وارد زیرساخت می‌شوند.
پیکربندی نادرست این اجزا می‌تواند باعث افشای سرویس‌های داخلی یا ایجاد مسیرهای ارتباطی ناخواسته شود.
استفاده صحیح از HTTPS و TLS
ارتباط کاربران با سرویس‌های عمومی باید با TLS معتبر محافظت شود.
گواهی‌های دیجیتال باید به‌درستی مدیریت شوند و پیش از انقضا تمدید شوند.
در معماری‌هایی که TLS روی Load Balancer یا Ingress خاتمه پیدا می‌کند، امنیت ارتباطات بعدی داخل کلاستر نیز باید جداگانه بررسی شود.
نباید فرض کرد که استفاده از HTTPS در ورودی، تمام ارتباطات داخلی را نیز رمزنگاری می‌کند.
محدودسازی مسیرهای مدیریتی
مسیرهایی مانند پنل مدیریت، داشبورد مانیتورینگ و رابط‌های مدیریتی نباید بدون ضرورت در دسترس اینترنت عمومی باشند.
دسترسی به این سرویس‌ها بهتر است از طریق مسیرهای خصوصی یا کنترل‌های هویتی مناسب انجام شود.
نقش WAF در امنیت Kubernetes
Web Application Firewall یا WAF ابزار محافظت از برنامه‌های وب در برابر دسته‌ای از درخواست‌ها و الگوهای حمله است.
این ابزار می‌تواند به کاهش خطر بعضی حملات لایه کاربرد مانند SQL Injection و XSS کمک کند.
اما WAF جایگزین اصلاح آسیب‌پذیری برنامه، کنترل دسترسی Kubernetes یا ایمن‌سازی کانتینرها نیست.
برای مثال، WAF نمی‌تواند مشکل مجوزهای بیش‌ازحد یک ServiceAccount را برطرف کند.
در یک معماری امن، WAF باید در کنار سایر کنترل‌های دفاعی استفاده شود.
جلوگیری از انتشار ناخواسته سرویس‌ها
در Kubernetes روش‌های مختلفی برای در دسترس قرار دادن سرویس‌ها وجود دارد.
استفاده از LoadBalancer یا NodePort بدون بررسی سیاست‌های شبکه می‌تواند باعث ایجاد مسیرهای دسترسی ناخواسته شود.
بهتر است سرویس‌های داخلی تا حد امکان فقط در شبکه‌های موردنیاز قابل‌دسترسی باشند.
همچنین باید وضعیت دسترسی عمومی آدرس‌ها و درگاه‌های مربوط به کلاستر به‌صورت دوره‌ای بررسی شود.
ایمن‌سازی Worker Node و سیستم‌عامل میزبان
امنیت Kubernetes به امنیت سیستم‌عامل میزبان وابسته است.
کانتینرها به‌صورت معمول از هسته سیستم‌عامل میزبان استفاده می‌کنند.
به همین دلیل، آسیب‌پذیری‌های مهم هسته یا Runtime می‌توانند بر امنیت محیط کانتینری تأثیر بگذارند.
به‌روزرسانی سیستم‌عامل و Runtime
سیستم‌عامل Nodeها، Container Runtime و اجزای Kubernetes باید بر اساس فرایند مشخص مدیریت وصله‌های امنیتی به‌روزرسانی شوند.
به‌روزرسانی باید با نسخه‌های پشتیبانی‌شده و سازگاری اجزای کلاستر هماهنگ باشد.
نصب بدون بررسی نسخه‌های جدید در محیط عملیاتی ممکن است باعث اختلال شود.
بنابراین، بهتر است تغییرات ابتدا در محیط آزمایشی بررسی شوند.
محدودسازی سرویس‌های سیستم‌عامل
سرویس‌هایی که برای اجرای Kubernetes ضروری نیستند، بهتر است غیرفعال شوند.
همچنین دسترسی SSH باید محدود شود و احراز هویت مناسب برای حساب‌های مدیریتی وجود داشته باشد.
استفاده از فایروال میزبان و کنترل‌های امنیتی سیستم‌عامل نیز به کاهش سطح حمله کمک می‌کند.
حفاظت از Kubelet
Kubelet یکی از حساس‌ترین اجزای Worker Node است.
این سرویس وظایفی مرتبط با اجرای Workloadها دارد و رابط مدیریتی آن نباید بدون کنترل مناسب در دسترس قرار گیرد.
احراز هویت و مجوزدهی Kubelet باید مطابق تنظیمات امن انجام شود.
به‌ویژه نباید برای سهولت مدیریت، دسترسی‌های ناشناس یا مجوزهای بسیار گسترده فعال شوند.
جداسازی Workloadهای حساس
اجرای تمام برنامه‌ها روی Nodeهای مشترک همیشه انتخاب مناسبی نیست.
در زیرساخت‌هایی که داده‌های بسیار حساس پردازش می‌کنند، ممکن است نیاز به Nodeهای اختصاصی یا مکانیزم‌های جداسازی قوی‌تر وجود داشته باشد.
ابزارهایی مانند Taints، Tolerations، Node Affinity و RuntimeClass می‌توانند در طراحی این معماری نقش داشته باشند.
بااین‌حال، اختصاص Namespace یا Node مجزا لزوماً معادل یک مرز امنیتی کامل نیست.
سطح جداسازی باید متناسب با مدل تهدید ارزیابی شود.
امنیت تصاویر Docker و زنجیره تأمین نرم‌افزار
امنیت یک کلاستر از زمان اجرای کانتینر آغاز نمی‌شود.
تصاویر کانتینری، کتابخانه‌ها، ابزارهای Build و فرایند انتشار نرم‌افزار نیز بخشی از سطح حمله هستند.
استفاده از تصاویر پایه معتبر
Base Image یا تصویر پایه، مجموعه اولیه فایل‌ها و وابستگی‌های موردنیاز برنامه را فراهم می‌کند.
استفاده از تصاویر ناشناس یا بدون پشتیبانی می‌تواند ریسک امنیتی ایجاد کند.
بهتر است تصاویر پایه از منابع قابل‌اعتماد انتخاب شوند و وضعیت به‌روزرسانی آن‌ها بررسی شود.
کاهش اجزای غیرضروری داخل Image
هر ابزار یا کتابخانه اضافی ممکن است آسیب‌پذیری جدیدی به تصویر اضافه کند.
به همین دلیل، استفاده از تصاویر کم‌حجم و متناسب با نیاز برنامه می‌تواند سطح حمله را کاهش دهد.
برای نمونه، معمولاً وجود ابزارهای توسعه و عیب‌یابی در تصویر نهایی یک سرویس وب ضروری نیست.
در بسیاری از پروژه‌ها می‌توان با Multi-stage Build، ابزارهای Build را از محیط اجرای نهایی جدا کرد.
اسکن امنیتی تصاویر کانتینری
Image Scanning فرایندی برای شناسایی آسیب‌پذیری‌های شناخته‌شده در بسته‌ها و وابستگی‌های تصویر است.
ابزارهایی مانند Trivy و Grype برای بررسی تصاویر کانتینری استفاده می‌شوند.
این اسکن‌ها باید بخشی از فرایند ساخت و انتشار نرم‌افزار باشند.
بااین‌حال، نتیجه اسکن به‌تنهایی نشان‌دهنده امن یا ناامن بودن قطعی یک برنامه نیست.
شدت آسیب‌پذیری، قابلیت بهره‌برداری، میزان دسترسی برنامه و شرایط محیط اجرا باید در اولویت‌بندی اصلاحات لحاظ شوند.
چرا استفاده از latest در محیط عملیاتی مناسب نیست؟
تگ latest یک شناسه تغییرپذیر است.
ممکن است محتوای تصویر پشت این تگ در زمان‌های مختلف تغییر کند.
برای افزایش قابلیت بازتولید و کنترل نسخه، بهتر است تصاویر با نسخه مشخص یا Digest مبتنی بر SHA-256 ارجاع داده شوند.
استفاده از Digest کمک می‌کند محتوای تصویر موردنظر به‌صورت دقیق مشخص شود.
البته Digest به‌تنهایی اصالت تولیدکننده تصویر را تضمین نمی‌کند.
امضای دیجیتال و اعتبارسنجی تصاویر
Image Signing روشی برای بررسی منشأ و یکپارچگی تصاویر کانتینری است.
ابزارهایی مانند Cosign می‌توانند در فرایند امضای تصاویر و بررسی امضا نقش داشته باشند.
در معماری‌های پیشرفته می‌توان سیاست‌هایی تعریف کرد که فقط تصاویر تأییدشده اجازه استقرار داشته باشند.
این کنترل در کنار اسکن آسیب‌پذیری، ثبت منشأ ساخت و محدودسازی دسترسی به Registry اهمیت پیدا می‌کند.
امنیت CI/CD
Continuous Integration و Continuous Delivery به خودکارسازی ساخت، آزمایش و انتشار نرم‌افزار کمک می‌کنند.
اما اگر Pipeline دسترسی‌های بیش‌ازحد داشته باشد یا اطلاعات محرمانه در آن به‌درستی محافظت نشوند، خود این فرایند می‌تواند به نقطه ضعف تبدیل شود.
برای افزایش امنیت CI/CD باید دسترسی Runnerها محدود شود، اعتبارنامه‌ها محافظت شوند و تغییرات حساس پیش از انتشار بررسی شوند.
همچنین بهتر است بین محیط‌های توسعه، آزمایش و Production تفکیک مشخص وجود داشته باشد.
استفاده از Admission Controller برای جلوگیری از تنظیمات ناامن
یکی از قابلیت‌های مهم Kubernetes امکان بررسی درخواست‌ها پیش از پذیرش نهایی آن‌ها است.
Admission Controllerها می‌توانند سیاست‌های مشخصی را در مسیر ایجاد یا تغییر منابع اعمال کنند.
برای مثال، ممکن است سازمان قانونی داشته باشد که کانتینرهای Privileged اجازه استقرار در Namespaceهای برنامه‌های عمومی را نداشته باشند.
یا فقط تصاویر ثبت‌شده در Registryهای تأییدشده موردقبول باشند.
تفاوت کنترل دسترسی و Admission Policy
RBAC مشخص می‌کند چه هویتی مجاز به انجام یک عملیات روی یک نوع منبع است.
Admission Policy می‌تواند بررسی کند که مشخصات همان منبع با سیاست‌های سازمان سازگار هستند یا خیر.
به بیان ساده، RBAC به پرسش «چه کسی اجازه ایجاد Pod دارد؟» پاسخ می‌دهد.
در مقابل، Admission Policy می‌تواند بررسی کند «آیا تنظیمات این Pod با الزامات امنیتی سازگار است؟».
ترکیب این دو سازوکار، کنترل دقیق‌تری ایجاد می‌کند.
ابزارهای مدیریت سیاست
ابزارهایی مانند Kyverno و OPA Gatekeeper امکان پیاده‌سازی مجموعه‌ای از سیاست‌های امنیتی و عملیاتی را فراهم می‌کنند.
از این ابزارها می‌توان برای بررسی تنظیمات منابع و جلوگیری از استقرار برخی پیکربندی‌های ناامن استفاده کرد.
همچنین Kubernetes دارای قابلیت‌های داخلی مانند ValidatingAdmissionPolicy است که بسته به نوع نیاز می‌تواند در اعتبارسنجی سیاست‌ها کاربرد داشته باشد.
انتخاب ابزار مناسب باید بر اساس پیچیدگی سیاست‌ها، نیازهای عملیاتی و قابلیت نگهداری انجام شود.
چرا اجرای تدریجی سیاست اهمیت دارد؟
اگر سیاست امنیتی بدون آزمایش روی محیط عملیاتی اعمال شود، ممکن است استقرار برنامه‌ها متوقف شود.
برای جلوگیری از چنین مشکلی بهتر است ابتدا سیاست‌ها در حالت بررسی و گزارش‌گیری آزمایش شوند.
پس از شناسایی ناسازگاری‌ها، می‌توان اجرای محدودکننده را فعال کرد.
این روش کمک می‌کند امنیت افزایش یابد، بدون اینکه پایداری سرویس‌ها به‌صورت غیرضروری آسیب ببیند.
مانیتورینگ و تشخیص تهدید در Kubernetes
امنیت Kubernetes فقط به پیشگیری از حملات محدود نمی‌شود.
سازمان باید بتواند رفتارهای غیرعادی را شناسایی کند و در صورت وقوع حادثه واکنش مناسبی داشته باشد.
ثبت رویدادها با Kubernetes Audit Logging
Audit Logging قابلیت ثبت رویدادهای مرتبط با درخواست‌های API Server را فراهم می‌کند.
این گزارش‌ها می‌توانند به پرسش‌های مهمی پاسخ دهند:
- چه هویتی یک منبع را تغییر داده است؟
- چه زمانی درخواست اجرا شده است؟
- درخواست به چه منبعی مربوط بوده است؟
- عملیات از چه مبدأیی انجام شده است؟
- نتیجه درخواست چه بوده است؟
برای نمونه، ایجاد ناگهانی یک ClusterRoleBinding قدرتمند می‌تواند رویدادی باشد که نیازمند بررسی امنیتی است.
سیاست ثبت رویداد باید به شکلی تنظیم شود که اطلاعات مفید حفظ شوند، اما داده‌های محرمانه غیرضروری در گزارش‌ها ذخیره نشوند.
پایش رفتار کانتینرها در زمان اجرا
Runtime Security Monitoring به بررسی فعالیت‌های برنامه‌ها و فرآیندها هنگام اجرا اشاره دارد.
برای مثال، اجرای فرآیندی غیرمنتظره در کانتینری که فقط باید یک سرویس وب مشخص را اجرا کند، می‌تواند نشانه‌ای برای بررسی باشد.
ابزارهایی مانند Falco در شناسایی بعضی رفتارهای مشکوک زمان اجرا کاربرد دارند.
البته تشخیص یک رویداد غیرعادی الزاماً به معنای وقوع حمله نیست.
هشدارها باید بر اساس زمینه عملیاتی، رفتار عادی سرویس و شواهد دیگر تحلیل شوند.
تجمیع گزارش‌ها در سامانه مرکزی
نگهداری گزارش‌های امنیتی فقط داخل همان Pod یا Node ممکن است کافی نباشد.
Podها می‌توانند حذف یا جایگزین شوند و اطلاعات محلی نیز ممکن است از بین بروند.
بهتر است رویدادهای مهم به زیرساخت ثبت و تحلیل مرکزی ارسال شوند.
سامانه‌های Log Management و SIEM می‌توانند به همبسته‌سازی رویدادها و شناسایی الگوهای مشکوک کمک کنند.
مهم‌ترین هشدارهای امنیتی Kubernetes
برخی رویدادهایی که ارزش پایش ویژه دارند عبارت‌اند از:
- ایجاد یا تغییر مجوزهای مدیریتی حساس
- افزایش غیرمنتظره دسترسی ServiceAccountها
- تلاش‌های ناموفق متعدد برای دسترسی به API
- استقرار کانتینرهای Privileged خارج از سیاست سازمان
- دسترسی غیرعادی به تعداد زیادی Secret
- تغییر ناخواسته سیاست‌های شبکه
- اجرای تصاویر کانتینری تأییدنشده
- ارتباطات خروجی غیرمعمول از سرویس‌های حساس
این موارد باید با شناخت رفتار عادی زیرساخت تحلیل شوند تا تعداد هشدارهای اشتباه کاهش پیدا کند.
امنیت چندمستاجری یا Multi-Tenancy در Kubernetes
در بعضی زیرساخت‌ها، چند تیم، پروژه یا مشتری از یک کلاستر مشترک استفاده می‌کنند.
به این معماری Multi-Tenancy گفته می‌شود.
چنین محیط‌هایی نیازمند تفکیک دقیق‌تر منابع و مجوزها هستند.
آیا Namespace مرز امنیتی کامل است؟
Namespace یک ابزار مهم برای سازمان‌دهی منابع و محدودسازی برخی دسترسی‌ها است.
اما به‌تنهایی جداسازی کامل امنیتی ایجاد نمی‌کند.
برای مثال، ممکن است Podهای متعلق به دو Namespace مختلف روی یک Node اجرا شوند.
همچنین بعضی منابع Kubernetes در سطح کلاستر تعریف می‌شوند.
به همین دلیل، امنیت چندمستاجری باید با ترکیب RBAC، سیاست شبکه، محدودیت Pod، جداسازی Node و سایر کنترل‌های متناسب طراحی شود.
چه زمانی باید از کلاسترهای جداگانه استفاده کرد؟
اگر چند مجموعه از نظر سطح اعتماد، حساسیت داده یا الزامات امنیتی تفاوت زیادی داشته باشند، استفاده از کلاسترهای مستقل می‌تواند انتخاب مناسب‌تری باشد.
برای مثال، اجرای Workloadهای کاملاً غیرقابل‌اعتماد در کنار سامانه‌های بسیار حساس ممکن است نیازمند جداسازی قوی‌تری باشد.
تصمیم نهایی باید با بررسی ریسک، هزینه عملیاتی و الزامات دسترس‌پذیری گرفته شود.
حفاظت از منابع کلاستر در برابر سوءاستفاده و اختلال
امنیت فقط به محرمانگی اطلاعات مربوط نیست.
دسترس‌پذیری سرویس‌ها نیز یکی از اهداف اصلی امنیت اطلاعات است.
در Kubernetes، مصرف غیرعادی منابع توسط یک Workload می‌تواند بر سایر برنامه‌های مستقر روی همان Node تأثیر بگذارد.
استفاده از Resource Requests و Limits
Requests میزان منابع موردنیاز برنامه را برای تصمیم‌گیری زمان‌بندی مشخص می‌کند.
Limits نیز می‌تواند سقفی برای مصرف بعضی منابع تعیین کند.
تنظیم صحیح حافظه و CPU می‌تواند به کنترل رقابت منابع کمک کند.
البته محدودسازی شدید CPU ممکن است باعث کاهش عملکرد یا اختلال در رفتار برنامه شود.
به همین دلیل، تنظیم منابع باید بر اساس اندازه‌گیری مصرف واقعی و آزمایش بار انجام شود.
کنترل مصرف منابع با ResourceQuota
ResourceQuota امکان محدودسازی مجموع مصرف برخی منابع در یک Namespace را فراهم می‌کند.
برای مثال، می‌توان برای محیط آزمایش سقف مشخصی از منابع تعیین کرد تا ایجاد تعداد زیادی Pod باعث مصرف نامحدود ظرفیت کلاستر نشود.
LimitRange نیز می‌تواند محدودیت‌ها یا مقادیر پیش‌فرضی برای منابع در یک Namespace تعریف کند.
این قابلیت‌ها علاوه بر مدیریت ظرفیت، در کاهش خطر بعضی الگوهای سوءاستفاده از منابع مؤثر هستند.
استفاده صحیح از Health Checkها
Kubernetes از سازوکارهایی مانند Readiness Probe و Liveness Probe برای بررسی وضعیت برنامه‌ها استفاده می‌کند.
پیکربندی صحیح این قابلیت‌ها به حفظ پایداری سرویس کمک می‌کند.
اما تنظیم نامناسب ممکن است باعث Restartهای مکرر یا خارج‌شدن بی‌دلیل سرویس از چرخه پاسخ‌گویی شود.
بنابراین، Health Check باید متناسب با رفتار واقعی برنامه طراحی شود.
امنیت Kubernetes در کلاسترهای وب و میکروسرویس‌ها
یک کلاستر وب معمولی ممکن است از Frontend، Backend، پایگاه داده، Redis، سامانه احراز هویت و ابزارهای مانیتورینگ تشکیل شده باشد.
هر سرویس باید بر اساس وظیفه خود محافظت شود.
امنیت Frontend
Frontend معمولاً یکی از سرویس‌هایی است که درخواست‌های کاربران اینترنت را دریافت می‌کند.
برای این بخش، HTTPS، محدودسازی مسیرهای مدیریتی، امنیت برنامه و کنترل دسترسی اهمیت زیادی دارد.
اگر Frontend آسیب ببیند، نباید به‌صورت پیش‌فرض دسترسی مدیریتی Kubernetes یا ارتباط آزاد با سرویس‌های حساس داشته باشد.
امنیت Backend
Backend ممکن است به پایگاه داده، صف پیام یا سرویس‌های داخلی دسترسی داشته باشد.
این ارتباطات باید به مقصدها و درگاه‌های ضروری محدود شوند.
همچنین اطلاعات محرمانه نباید داخل کد برنامه یا Image ذخیره شوند.
امنیت پایگاه داده
در بیشتر معماری‌های وب، پایگاه داده نیازی به دسترسی مستقیم کاربران اینترنت ندارد.
ارتباط با آن باید فقط برای سرویس‌های مجاز فراهم شود.
احراز هویت پایگاه داده، رمزنگاری ارتباطات در صورت نیاز، مدیریت دسترسی و تهیه نسخه پشتیبان از اقدامات اساسی هستند.
امنیت Redis و سامانه‌های Cache
سرویس‌هایی مانند Redis ممکن است داده‌های نشست، کش و اطلاعات عملیاتی مهم را نگهداری کنند.
دسترسی شبکه‌ای به این سرویس‌ها باید محدود باشد.
همچنین قابلیت‌های امنیتی و روش احراز هویت سرویس باید متناسب با نسخه و معماری آن پیکربندی شوند.
امنیت ارتباطات بین سرویس‌ها
در معماری Microservices، سرویس‌ها ممکن است دائماً با یکدیگر تبادل اطلاعات داشته باشند.
استفاده از هویت سرویس و ارتباطات رمزنگاری‌شده می‌تواند به حفاظت از داده‌ها کمک کند.
در محیط‌های پیچیده، Service Mesh ممکن است مدیریت برخی از این ارتباطات را ساده‌تر کند.
بااین‌حال، افزودن Service Mesh هزینه عملیاتی و پیچیدگی مخصوص خود را دارد و همیشه ضروری نیست.
نقش Service Mesh در امنیت Kubernetes
Service Mesh لایه‌ای زیرساختی برای مدیریت ارتباطات بین سرویس‌ها است.
راهکارهایی مانند Istio و Linkerd در این حوزه شناخته‌شده هستند.
استفاده از mTLS بین سرویس‌ها
Mutual TLS یا mTLS امکان احراز هویت متقابل دو سمت ارتباط را فراهم می‌کند.
در معماری مناسب، این قابلیت می‌تواند از ارتباطات سرویس‌به‌سرویس در برابر برخی تهدیدهای شنود و جعل هویت محافظت کند.
اما mTLS به‌تنهایی مشخص نمی‌کند کدام سرویس باید به کدام داده دسترسی داشته باشد.
برای این هدف، سیاست‌های مجوزدهی نیز لازم هستند.
آیا تمام کلاسترها به Service Mesh نیاز دارند؟
خیر.
برای کلاسترهای کوچک، استفاده از TLS مناسب در برنامه‌ها، NetworkPolicy و کنترل دسترسی ممکن است نیازهای اصلی را پوشش دهد.
Service Mesh زمانی ارزش بیشتری پیدا می‌کند که تعداد سرویس‌ها، پیچیدگی ارتباطات و الزامات هویتی افزایش یافته باشد.
بهتر است انتخاب آن بر اساس نیاز واقعی انجام شود، نه صرفاً به دلیل محبوبیت فناوری.
پشتیبان‌گیری امن و بازیابی کلاستر Kubernetes
یکی از بخش‌های مهم امنیت Kubernetes، توانایی بازیابی زیرساخت پس از حادثه است.
حتی با وجود کنترل‌های امنیتی مناسب، احتمال خطای انسانی، خرابی زیرساخت یا حمله سایبری به صفر نمی‌رسد.
چه اطلاعاتی باید پشتیبان‌گیری شوند؟
بسته به معماری، ممکن است لازم باشد از موارد زیر نسخه پشتیبان تهیه شود:
- وضعیت و داده‌های مهم Control Plane، از جمله etcd در کلاسترهای خودمدیریت
- فایل‌های پیکربندی و Manifestهای Kubernetes
- داده‌های Persistent Volume
- پایگاه‌های داده برنامه‌ها
- سیاست‌های امنیتی و تنظیمات شبکه
- اطلاعات موردنیاز برای بازیابی اعتبارنامه‌ها و کلیدهای رمزنگاری
پشتیبان‌گیری از وضعیت Kubernetes لزوماً معادل پشتیبان‌گیری سازگار از داده‌های پایگاه داده نیست.
برای سامانه‌های داده‌محور ممکن است روش‌های تخصصی Backup و بازیابی موردنیاز باشند.
محافظت از فایل‌های Backup
نسخه پشتیبان ممکن است شامل اطلاعات محرمانه یا تنظیمات حساس باشد.
بنابراین، باید دسترسی به آن محدود شود و در صورت نیاز با رمزنگاری محافظت شود.
نگهداری نسخه‌های مستقل و مقاوم در برابر حذف یا تغییر غیرمجاز می‌تواند به کاهش خطر حملات باج‌افزاری کمک کند.
آزمایش فرایند بازیابی
داشتن Backup بدون آزمایش بازیابی، تضمین‌کننده آمادگی عملیاتی نیست.
بهتر است فرایند Restore در محیط کنترل‌شده به‌صورت دوره‌ای آزمایش شود.
در این بررسی باید مشخص شود چه مدت زمان برای بازیابی لازم است و چه میزان از داده‌های اخیر ممکن است از دست برود.
معیارهای RTO و RPO برای تعیین این اهداف کاربرد دارند.
چگونه امنیت Kubernetes را به‌صورت مرحله‌ای افزایش دهیم؟
امن‌سازی کلاسترهای موجود بهتر است بر اساس برنامه‌ای مرحله‌ای انجام شود.
تغییر هم‌زمان تعداد زیادی از سیاست‌های امنیتی ممکن است باعث اختلال در برنامه‌ها شود.
مرحله اول: شناخت دارایی‌ها و سطح دسترسی
ابتدا باید مشخص شود چه سرویس‌هایی در کلاستر اجرا می‌شوند.
در این مرحله، فهرست Namespaceها، Workloadها، کاربران، ServiceAccountها، درگاه‌های عمومی و وابستگی‌های مهم تهیه می‌شود.
همچنین لازم است مالک عملیاتی هر سرویس مشخص باشد.
بدون شناخت اجزای زیرساخت، اولویت‌بندی ریسک دشوار خواهد بود.
مرحله دوم: بررسی دسترسی‌های مدیریتی
در این مرحله باید تنظیمات API Server، حساب‌های مدیریتی و RBAC بررسی شوند.
دسترسی‌های غیرضروری و حساب‌های غیرفعال باید شناسایی شوند.
همچنین لازم است مسیرهای دسترسی به etcd و Kubelet ارزیابی شوند.
مرحله سوم: اعمال سیاست‌های امنیتی Workload
در این بخش، تنظیمات Podها از نظر اجرای Root، مجوزهای اضافی، ServiceAccount و سیاست‌های Pod Security بررسی می‌شود.
بهتر است Workloadهای جدید از ابتدا با استانداردهای امنیتی مناسب طراحی شوند.
برای برنامه‌های قدیمی، می‌توان برنامه اصلاح مرحله‌ای تهیه کرد.
مرحله چهارم: محدودسازی ارتباطات شبکه
ابتدا الگوی ارتباطات واقعی سرویس‌ها شناسایی می‌شود.
سپس NetworkPolicyها متناسب با نیاز عملیاتی تعریف می‌شوند.
در نهایت، باید آزمایش شود که ارتباطات مجاز همچنان برقرار هستند و مسیرهای غیرضروری محدود شده‌اند.
مرحله پنجم: امنیت زنجیره تأمین
فرایند Build و Deployment باید از نظر اعتبار تصاویر، اسکن آسیب‌پذیری و مدیریت Secrets بررسی شود.
همچنین بهتر است انتشار نسخه‌های جدید با کنترل‌های امنیتی خودکار همراه باشد.
مرحله ششم: مانیتورینگ و واکنش به حادثه
پس از اعمال کنترل‌های پیشگیرانه، باید ثبت رویدادها، هشدارها و فرایند رسیدگی به حادثه تکمیل شود.
امنیت زمانی مؤثرتر خواهد بود که سازمان علاوه بر جلوگیری از تهدیدها، توانایی شناسایی و مهار آن‌ها را نیز داشته باشد.
مثال کاربردی: طراحی امنیت یک کلاستر فروشگاه اینترنتی
فرض کنیم یک فروشگاه اینترنتی از چند سرویس اصلی تشکیل شده است:
Frontend، Backend، سرویس پرداخت، پایگاه داده و Redis.
Frontend درخواست‌های کاربران را دریافت می‌کند و Backend پردازش سفارش‌ها را انجام می‌دهد.
سرویس پرداخت نیز اطلاعات حساس مرتبط با تراکنش‌ها را مدیریت می‌کند.
در یک معماری ضعیف، ممکن است تمام سرویس‌ها ارتباط شبکه‌ای آزاد داشته باشند و از اعتبارنامه‌های مشترک استفاده کنند.
در چنین شرایطی، آسیب‌دیدن یکی از سرویس‌ها می‌تواند دامنه حادثه را افزایش دهد.
اما در معماری امن‌تر، شرایط متفاوت است.
Frontend فقط با Backendهای ضروری ارتباط برقرار می‌کند.
Backend فقط به پایگاه داده و سرویس‌های موردنیاز دسترسی دارد.
سرویس پرداخت از سیاست‌های شبکه و هویتی محدودکننده‌تر استفاده می‌کند.
هر Workload دارای ServiceAccount متناسب با نیاز خود است.
داده‌های محرمانه از طریق سازوکار مدیریت Secrets ارائه می‌شوند.
تصاویر کانتینری پیش از استقرار بررسی شده‌اند و تغییر مجوزهای حساس در گزارش‌های امنیتی ثبت می‌شود.
در این وضعیت نیز امکان وقوع آسیب‌پذیری وجود دارد، اما کنترل‌های چندلایه احتمال گسترش حادثه و شدت پیامدهای آن را کاهش می‌دهند.
چک‌لیست امنیت Kubernetes برای مدیران سرور
برای ارزیابی اولیه امنیت کلاسترهای وب می‌توان موارد زیر را بررسی کرد.
کنترل دسترسی و مدیریت
- دسترسی API Server به شبکه‌ها و هویت‌های ضروری محدود شده باشد.
- حساب‌های مدیریتی قدرتمند فقط در موارد ضروری استفاده شوند.
- مجوزهای RBAC بر اساس اصل Least Privilege تعریف شده باشند.
- اتصال‌های RoleBinding و ClusterRoleBinding بررسی شوند.
- اعتبارنامه‌های مدیریتی و Kubeconfigها محافظت شوند.
- حساب‌های بلااستفاده حذف یا غیرفعال شده باشند.
امنیت Workload و Node
- اجرای کانتینرها با Root فقط در موارد ضروری انجام شود.
- Podهای معمولی بدون حالت Privileged اجرا شوند.
- Pod Security Standards متناسب با نوع سرویس اعمال شده باشد.
- قابلیت‌های غیرضروری سیستم‌عامل محدود شده باشند.
- سیستم‌عامل Nodeها و Runtime به‌روزرسانی شده باشند.
- دسترسی مدیریتی Kubelet محافظت شود.
امنیت شبکه و داده
- افزونه شبکه از اجرای NetworkPolicy پشتیبانی کند.
- ارتباطات غیرضروری بین سرویس‌ها محدود شده باشند.
- ارتباطات حساس با TLS محافظت شوند.
- Secrets با مجوزهای محدود مدیریت شوند.
- وضعیت Encryption at Rest بررسی شده باشد.
- سرویس‌های داخلی بدون ضرورت در اینترنت منتشر نشده باشند.
امنیت توسعه و مانیتورینگ
- تصاویر کانتینری از منابع مورداعتماد دریافت شوند.
- اسکن آسیب‌پذیری در فرایند Build انجام شود.
- از نسخه‌ها یا Digestهای مشخص برای تصاویر استفاده شود.
- تغییرات حساس کلاستر ثبت و پایش شوند.
- نسخه‌های پشتیبان محافظت و بازیابی آن‌ها آزمایش شود.
- مسئولیت رسیدگی به هشدارها و حوادث مشخص باشد.
این چک‌لیست نقطه شروع مناسبی است، اما جایگزین ارزیابی امنیتی تخصصی و متناسب با معماری سازمان نیست.
مهم‌ترین اشتباهات رایج در امنیت Kubernetes
بخشی از مشکلات امنیتی Kubernetes نه به دلیل نقص بنیادی پلتفرم، بلکه به علت تصمیم‌های نادرست در پیکربندی و مدیریت ایجاد می‌شوند.
استفاده گسترده از ClusterRoleBinding
گاهی برای رفع سریع خطاهای دسترسی، مجوزهای قدرتمند به حساب‌های مختلف اختصاص داده می‌شود.
این روش ممکن است مشکل فوری را برطرف کند، اما سطح ریسک را افزایش می‌دهد.
راهکار بهتر، شناسایی مجوز واقعی موردنیاز و ایجاد نقش محدود است.
فرض امن‌بودن تمام ارتباطات داخلی
قرارگرفتن یک سرویس داخل کلاستر به معنای قابل‌اعتمادبودن تمام درخواست‌های آن نیست.
اگر ارتباطات داخلی بدون محدودیت باشند، آسیب‌دیدن یک سرویس ممکن است سایر بخش‌ها را نیز در معرض خطر قرار دهد.
ذخیره Secrets داخل فایل‌های پروژه
نگهداری رمزها در فایل‌های قابل‌اشتراک‌گذاری یا مخازن کد می‌تواند باعث افشای ناخواسته اطلاعات شود.
بهتر است اعتبارنامه‌ها از طریق سامانه مدیریت اطلاعات محرمانه ارائه شوند.
اعتماد کامل به تصاویر کانتینری عمومی
محبوبیت یک تصویر لزوماً امنیت آن را تضمین نمی‌کند.
منشأ تصویر، وضعیت به‌روزرسانی، وابستگی‌ها و آسیب‌پذیری‌های شناخته‌شده باید بررسی شوند.
فعال‌کردن سیاست‌های سخت‌گیرانه بدون آزمایش
اعمال ناگهانی Restricted Pod Security یا Default Deny NetworkPolicy ممکن است ارتباطات ضروری را مختل کند.
بهتر است ابتدا سازگاری Workloadها بررسی شود و سپس محدودیت‌ها مرحله‌به‌مرحله اعمال شوند.
نادیده‌گرفتن هشدارهای Runtime
اسکن تصویر فقط وضعیت شناخته‌شده نرم‌افزار را در زمان بررسی نشان می‌دهد.
رفتار برنامه پس از استقرار نیز باید پایش شود.
اتکا به یک ابزار امنیتی
نصب WAF، اسکنر یا ابزار مانیتورینگ به معنای تکمیل امنیت Kubernetes نیست.
هر ابزار فقط بخشی از مدل تهدید را پوشش می‌دهد.
نداشتن برنامه واکنش به حادثه
حتی کلاسترهایی با کنترل‌های امنیتی پیشرفته نیز ممکن است با حادثه مواجه شوند.
نبود برنامه مشخص برای محدودسازی دسترسی، حفاظت از شواهد، بازیابی سرویس و بررسی علت حادثه می‌تواند شدت خسارت را افزایش دهد.
تفاوت امنیت Kubernetes با امنیت Docker و سرور سنتی
اگرچه Kubernetes، Docker و سیستم‌عامل میزبان در بعضی حوزه‌های امنیتی اشتراک دارند، سطح مسئولیت آن‌ها متفاوت است.
| موضوع امنیتی | Docker و کانتینر | Kubernetes | سرور سنتی |
|---|---|---|---|
| کنترل اجرای برنامه | تنظیمات کانتینر و Runtime | Pod Security و سیاست‌های استقرار | تنظیمات سیستم‌عامل و سرویس |
| مدیریت مجوزها | کاربران و دسترسی‌های میزبان یا Runtime | RBAC و ServiceAccount | کاربران و گروه‌های سیستم‌عامل |
| امنیت شبکه | شبکه کانتینری و فایروال | NetworkPolicy و کنترل سرویس‌ها | فایروال و تفکیک شبکه |
| مدیریت اطلاعات محرمانه | روش‌های مدیریت Secret وابسته به محیط | Secret API و ابزارهای جانبی | فایل‌های محافظت‌شده و Secret Manager |
| نظارت امنیتی | گزارش‌های میزبان و کانتینر | Audit Log، رخدادهای Workload و Runtime | گزارش‌های سیستم‌عامل و سرویس‌ها |
| مقیاس‌پذیری امنیت | وابسته به ابزارهای مدیریت | سیاست‌های خودکار در سطح کلاستر | معمولاً نیازمند مدیریت چند سرور |
این مقایسه نشان می‌دهد Kubernetes لایه مدیریتی و امنیتی جدیدی به محیط کانتینری اضافه می‌کند.
بنابراین، استفاده از Kubernetes نیاز به ایمن‌سازی سیستم‌عامل و برنامه را از بین نمی‌برد؛ بلکه کنترل‌های بیشتری را ضروری می‌کند.
چگونه وضعیت امنیت Kubernetes را ارزیابی کنیم؟
ارزیابی امنیت Kubernetes باید مبتنی بر شواهد و رفتار واقعی زیرساخت باشد.
بهتر است به‌جای تمرکز صرف بر تعداد تنظیمات امنیتی فعال، میزان پوشش کنترل‌ها و سطح ریسک بررسی شود.
بررسی پیکربندی کلاستر
در این مرحله، تنظیمات API Server، RBAC، Pod Security، NetworkPolicy و ServiceAccountها بررسی می‌شود.
هدف، شناسایی مواردی است که با استاندارد امنیتی سازمان سازگار نیستند.
ارزیابی امنیت Workloadها
باید مشخص شود کدام برنامه‌ها با مجوز بالا اجرا می‌شوند و کدام تصاویر دارای آسیب‌پذیری‌های مهم هستند.
همچنین ارتباطات شبکه‌ای و میزان دسترسی برنامه‌ها به اطلاعات حساس بررسی می‌شود.
بررسی سیاست‌های امنیتی
وجود یک Policy به‌تنهایی کافی نیست.
باید آزمایش شود که سیاست موردنظر واقعاً توسط زیرساخت اجرا می‌شود و در صورت مشاهده پیکربندی ناسازگار، رفتار موردانتظار رخ می‌دهد.
استفاده از ابزارهای ارزیابی
ابزارهایی مانند kube-bench می‌توانند در بررسی بخشی از تنظیمات امنیتی بر اساس معیارهای مربوط کمک کنند.
ابزارهایی مانند Kubescape نیز در ارزیابی پیکربندی‌ها و سیاست‌های امنیتی Kubernetes کاربرد دارند.
نتایج این ابزارها باید توسط متخصص بررسی شوند، زیرا همه یافته‌ها در تمام معماری‌ها شدت یا اهمیت یکسانی ندارند.
تعریف شاخص‌های قابل‌اندازه‌گیری
برای بررسی روند بهبود امنیت می‌توان شاخص‌هایی مانند موارد زیر تعریف کرد:
- درصد Workloadهایی که با سیاست امنیتی موردنظر سازگارند
- تعداد ServiceAccountهای دارای مجوزهای گسترده
- تعداد سرویس‌های حساس بدون محدودیت شبکه‌ای مناسب
- زمان اصلاح آسیب‌پذیری‌های مهم
- میزان پوشش Audit Logging
- درصد موفقیت آزمایش‌های بازیابی اطلاعات
این شاخص‌ها زمانی ارزشمند هستند که همراه با تحلیل ریسک و شناخت اهمیت سرویس‌ها بررسی شوند.
اولویت‌بندی اقدامات امنیت Kubernetes در محیط عملیاتی
تمام مشکلات امنیتی اهمیت یکسانی ندارند.
برای مثال، دسترسی عمومی ناخواسته به یک رابط مدیریتی حساس معمولاً باید زودتر از یک تنظیم کم‌خطر در محیط آزمایشی بررسی شود.
یک مدل مناسب اولویت‌بندی می‌تواند چهار عامل را در نظر بگیرد.
شدت فنی: آسیب‌پذیری یا پیکربندی ناامن چه پیامدهایی دارد؟
قابلیت دسترسی: آیا بخش آسیب‌پذیر از اینترنت یا شبکه‌های غیرقابل‌اعتماد قابل‌دسترسی است؟
سطح مجوز: سرویس یا هویت آسیب‌پذیر به چه منابعی دسترسی دارد؟
اهمیت کسب‌وکار: اختلال یا افشای اطلاعات این سرویس چه تأثیری بر سازمان می‌گذارد؟
با ترکیب این عوامل می‌توان برنامه اصلاح امنیتی واقع‌بینانه‌تری تهیه کرد.
برای مثال، یک آسیب‌پذیری با شدت متوسط در سرویس عمومی دارای دسترسی گسترده ممکن است نسبت به آسیب‌پذیری شدیدتر در یک محیط کاملاً جداشده، اولویت عملیاتی بیشتری داشته باشد.
بنابراین، امنیت Kubernetes باید مبتنی بر ریسک واقعی باشد، نه صرفاً تعداد هشدارهای اسکنر.
برنامه واکنش به حوادث امنیتی Kubernetes
هنگام وقوع حادثه، سرعت شناسایی و تصمیم‌گیری اهمیت زیادی دارد.
اما واکنش عجولانه ممکن است باعث ازبین‌رفتن شواهد یا اختلال در سرویس‌های سالم شود.
شناسایی و تحلیل اولیه
ابتدا باید مشخص شود کدام Workload، هویت یا Node رفتار غیرعادی نشان داده است.
گزارش‌های Kubernetes Audit، لاگ برنامه و اطلاعات مانیتورینگ می‌توانند به تعیین دامنه حادثه کمک کنند.
مهار دسترسی مشکوک
پس از بررسی اولیه، ممکن است لازم باشد مجوزهای مرتبط محدود شوند، اعتبارنامه‌ها باطل شوند یا Workload آسیب‌دیده از سایر بخش‌ها جدا شود.
نوع اقدام باید با توجه به اثر آن بر سرویس و ضرورت حفظ شواهد تعیین شود.
اصلاح علت اصلی
فقط راه‌اندازی مجدد Pod یا حذف کانتینر مشکوک کافی نیست.
اگر عامل اولیه حادثه، آسیب‌پذیری برنامه یا تنظیمات نادرست باشد، باید آن مشکل نیز برطرف شود.
بازیابی و بازبینی
پس از رفع مشکل، سرویس‌ها باید از منابع قابل‌اعتماد بازیابی شوند.
در ادامه، لازم است مشخص شود چه کنترل‌هایی عمل نکرده‌اند و چه تغییراتی برای جلوگیری از تکرار حادثه ضروری است.
سؤالات متداول درباره امنیت Kubernetes
امنیت Kubernetes چیست؟
امنیت Kubernetes مجموعه‌ای از کنترل‌های فنی و مدیریتی برای محافظت از Control Plane، Nodeها، Podها، شبکه، داده‌ها و فرایند استقرار برنامه‌ها است. هدف آن جلوگیری از دسترسی غیرمجاز، کاهش سطح حمله، محدودسازی گسترش نفوذ و حفظ محرمانگی، یکپارچگی و دسترس‌پذیری سرویس‌ها است.
آیا Kubernetes به‌صورت پیش‌فرض امن است؟
Kubernetes قابلیت‌های امنیتی متعددی دارد، اما فعال‌بودن یا پیکربندی مناسب همه کنترل‌ها در هر کلاستر تضمین‌شده نیست. وضعیت امنیت به نسخه، روش نصب، ارائه‌دهنده زیرساخت، تنظیمات دسترسی و سیاست‌های عملیاتی بستگی دارد. بنابراین، هر کلاستر باید جداگانه ارزیابی شود.
مهم‌ترین اقدام برای امن‌سازی Kubernetes چیست؟
یک اقدام واحد نمی‌تواند امنیت کامل ایجاد کند. بااین‌حال، محدودسازی دسترسی API Server، اجرای اصل Least Privilege در RBAC، حفاظت از Secrets، محدودسازی ارتباطات شبکه و اجرای Podهای کم‌مجوز از مهم‌ترین اولویت‌ها هستند.
RBAC در Kubernetes چه کاربردی دارد؟
RBAC برای تعیین مجوزهای کاربران و سرویس‌ها استفاده می‌شود. با این سازوکار می‌توان مشخص کرد چه هویتی مجاز به مشاهده، ایجاد، تغییر یا حذف منابع Kubernetes است. طراحی صحیح RBAC احتمال سوءاستفاده از حساب‌های کاربری و دسترسی‌های غیرضروری را کاهش می‌دهد.
NetworkPolicy چه نقشی در امنیت کلاستر دارد؟
NetworkPolicy امکان محدودسازی ارتباطات شبکه‌ای Podها را فراهم می‌کند. با این سیاست می‌توان ترافیک ورودی و خروجی را بر اساس نیاز واقعی سرویس‌ها کنترل کرد. اجرای مؤثر آن به پشتیبانی افزونه شبکه Kubernetes بستگی دارد.
آیا استفاده از Namespace برای جداسازی امنیتی کافی است؟
خیر. Namespace برای سازمان‌دهی منابع و اعمال بعضی محدودیت‌های دسترسی مناسب است، اما به‌تنهایی جداسازی امنیتی کامل ایجاد نمی‌کند. در محیط‌های حساس باید از ترکیب RBAC، NetworkPolicy، Pod Security و در صورت ضرورت جداسازی Node یا کلاستر استفاده شود.
آیا Kubernetes Secret اطلاعات را کاملاً محافظت می‌کند؟
خیر. Secret یک سازوکار مناسب برای مدیریت داده‌های حساس در Kubernetes است، اما امنیت آن به تنظیمات رمزنگاری، مجوزهای دسترسی و نحوه استفاده برنامه بستگی دارد. استفاده از Base64 نیز به معنای رمزنگاری اطلاعات نیست.
آیا Kubernetes می‌تواند جلوی حملات DDoS را بگیرد؟
Kubernetes قابلیت‌هایی برای مقیاس‌پذیری و مدیریت مصرف منابع دارد، اما یک سامانه تخصصی مقابله با DDoS نیست. برای محافظت از سرویس‌های عمومی ممکن است استفاده از CDN، کنترل ترافیک، Rate Limiting و خدمات تخصصی مقابله با DDoS ضروری باشد.
تفاوت Pod Security و RBAC چیست؟
RBAC مشخص می‌کند چه کسی اجازه انجام عملیات روی منابع Kubernetes را دارد. Pod Security مشخص می‌کند چه نوع تنظیمات امنیتی برای اجرای Podها مجاز است. این دو سازوکار مکمل یکدیگر هستند و هیچ‌کدام جایگزین دیگری نیست.
آیا کلاستر Kubernetes مدیریت‌شده به ایمن‌سازی نیاز دارد؟
بله. در سرویس‌های مدیریت‌شده، ارائه‌دهنده زیرساخت ممکن است مسئولیت نگهداری بخش‌هایی از Control Plane را بر عهده داشته باشد. بااین‌حال، امنیت برنامه‌ها، تنظیمات RBAC، مدیریت Secrets، سیاست‌های شبکه و کنترل تصاویر کانتینری همچنان باید توسط مالک Workload بررسی شوند.
آیا امنیت Kubernetes بدون ابزارهای تجاری امکان‌پذیر است؟
بله. Kubernetes قابلیت‌های داخلی متعددی برای کنترل دسترسی، محدودسازی Podها، مدیریت شبکه و ثبت رویدادها دارد. همچنین ابزارهای متن‌باز مختلفی برای اسکن، پایش و ارزیابی امنیت وجود دارند. انتخاب راهکار باید بر اساس نیاز واقعی و توانایی عملیاتی سازمان انجام شود.
هر چند وقت یک‌بار باید امنیت کلاستر بررسی شود؟
بررسی امنیت باید فرایندی مداوم باشد. تغییرات حساس بهتر است پیش از انتشار بررسی شوند و ارزیابی‌های دوره‌ای نیز بر اساس اهمیت زیرساخت انجام شوند. پس از تغییر معماری، مشاهده آسیب‌پذیری مهم یا وقوع حادثه، بررسی مجدد ضروری است.
جمع‌بندی: چگونه یک کلاستر Kubernetes امن داشته باشیم؟
امنیت Kubernetes یکی از مهم‌ترین بخش‌های مدیریت زیرساخت‌های مدرن وب است.
اگرچه این پلتفرم قابلیت‌های گسترده‌ای برای استقرار و مدیریت برنامه‌ها فراهم می‌کند، استفاده از آن بدون سیاست‌های امنیتی مناسب می‌تواند سطح حمله زیرساخت را افزایش دهد.
مهم‌ترین نکته این است که امنیت کلاستر نباید فقط به یک ابزار یا تنظیم محدود شود.
کنترل دسترسی با RBAC، حفاظت از API Server، ایمن‌سازی etcd، اجرای محدود Podها، استفاده از NetworkPolicy و مدیریت صحیح Secrets باید در کنار یکدیگر قرار گیرند.
همچنین اسکن تصاویر کانتینری، محافظت از زنجیره تأمین نرم‌افزار، ثبت رویدادها و بررسی رفتار برنامه‌ها در زمان اجرا نقش مهمی در شناسایی و کاهش تهدیدها دارند.
برای کلاسترهای وب، تفکیک سرویس‌های عمومی از اجزای حساس اهمیت ویژه‌ای دارد.
یک آسیب‌پذیری در Frontend نباید به‌صورت خودکار امکان دسترسی به پایگاه داده، Secrets یا منابع مدیریتی را فراهم کند.
از طرف دیگر، اعمال سیاست‌های بسیار سخت‌گیرانه بدون شناخت زیرساخت ممکن است باعث اختلال شود؛ بنابراین، برنامه امن‌سازی باید مرحله‌ای، قابل‌آزمایش و مبتنی بر ریسک باشد.
در نهایت، امنیت Kubernetes یک وضعیت ثابت نیست، بلکه فرایندی دائمی از ارزیابی، پیشگیری، پایش، اصلاح و بهبود است.
کلاستری امنیت بالاتری خواهد داشت که علاوه بر کاهش احتمال نفوذ، بتواند دامنه حمله را محدود کند، رفتارهای مشکوک را شناسایی کند و پس از حادثه با کمترین خسارت ممکن به وضعیت پایدار بازگردد.
مطالب مرتبط
