امنیت کوبرنتیز مجموعه اقداماتی برای محافظت از کلاستر، برنامه های کانتینری و داده ها در برابر دسترسی غیرمجاز، افشای اطلاعات و سوءاستفاده از منابع است. کنترل دسترسی، محدود کردن ارتباطات شبکه، مدیریت امن اطلاعات محرمانه و کاهش دسترسی کانتینرها، بخش های اصلی امن سازی Kubernetes هستند.
راه اندازی موفق یک کلاستر به معنی امن بودن آن نیست. ممکن است برنامه بدون مشکل اجرا شود، اما یک حساب با دسترسی بیش از حد یا یک ایمیج آسیب پذیر، مسیر نفوذ به زیرساخت را باز بگذارد.
در این راهنما، مهم ترین تنظیمات امنیتی Kubernetes، اشتباهات رایج و روش بررسی اجرای کنترل ها را مرور می کنیم. هدف، ایجاد یک نقطه شروع عملی برای تیم هایی است که می خواهند امنیت کلاستر را متناسب با معماری و حساسیت سرویس های خود بهبود دهند.
خلاصه سریع
- کنترل دسترسی: مجوز کاربران و ServiceAccountها را به حداقل نیاز محدود کنید.
- امنیت پاد و شبکه: اختیارات کانتینرها و ارتباطات غیرضروری را کاهش دهید و اجرای سیاست ها را آزمون کنید.
- اطلاعات محرمانه: دسترسی به Secretها، رمزنگاری هنگام ذخیره سازی و تعویض اعتبارنامه ها را بررسی کنید؛ Base64 رمزنگاری نیست.
- ایمیج و انتشار: منبع و نسخه ایمیج را مشخص کنید و یافته های اسکن آسیب پذیری را پیگیری کنید.
- بازبینی مستمر: رویدادهای حساس را پایش کنید؛ تنظیم شدن یک کنترل به تنهایی، اثبات عملکرد صحیح آن نیست.
چرا امنیت Kubernetes به چند لایه حفاظتی نیاز دارد؟
در Kubernetes، امنیت فقط به برنامه یا سرور محدود نمی شود. کاربران، حساب های سرویس، شبکه، نودها و تنظیمات اجرای کانتینر، هر کدام می توانند بر امنیت کل محیط تاثیر بگذارند.
برای مثال، اگر یک برنامه آسیب پذیر شود، محدود بودن دسترسی آن می تواند دامنه خسارت را کاهش دهد. اما اگر همان برنامه به اطلاعات محرمانه سایر سرویس ها و امکانات مدیریتی کلاستر دسترسی داشته باشد، پیامد نفوذ گسترده تر خواهد بود.
به همین دلیل، امن سازی باید چند مسیر را همزمان پوشش دهد:
- مشخص کردن هویت کاربران و سرویس ها.
- محدود کردن مجوزهای هر هویت.
- کنترل ارتباطات میان برنامه ها.
- کاهش اختیارات کانتینرها و دسترسی آنها به میزبان.
- محافظت از اطلاعات محرمانه.
- ثبت و بررسی فعالیت های حساس.
هیچ کنترل منفردی جای همه این موارد را نمی گیرد. چک لیست امنیت نیز نقطه شروع ارزیابی است و باید با شرایط واقعی هر کلاستر تطبیق داده شود.
تهدیدهای رایج امنیت کوبرنتیز کدام اند؟
بخشی از ریسک های Kubernetes از تنظیمات نامناسب و دسترسی های اضافی ایجاد می شوند. شناخت این موارد کمک می کند بررسی امنیت از مسائل ملموس شروع شود.
| تهدید | نمونه وضعیت پرخطر | پیامد احتمالی |
|---|---|---|
| مجوز بیش از نیاز | حساب استقرار برنامه، مدیر کل کلاستر باشد | تغییر یا حذف منابع خارج از محدوده برنامه |
| افشای اطلاعات محرمانه | رمز پایگاه داده در مخزن کد قرار بگیرد | دسترسی غیرمجاز به داده ها |
| ارتباطات شبکه گسترده | همه پادها به پایگاه داده دسترسی داشته باشند | گسترش نفوذ میان سرویس ها |
| اجرای کانتینر با اختیارات زیاد | استفاده غیرضروری از حالت privileged | افزایش خطر دسترسی به میزبان |
| وابستگی آسیب پذیر | استفاده مداوم از ایمیج قدیمی | سوءاستفاده از آسیب پذیری شناخته شده |
| نبود دید عملیاتی | تغییرات حساس ثبت یا بررسی نشوند | شناسایی دیرهنگام فعالیت مشکوک |
اهمیت هر ریسک به محیط بستگی دارد. برای یک سرویس مالی، دسترسی به داده حساس ممکن است اولویت بالاتری داشته باشد؛ در یک سامانه عمومی، دسترسی اینترنتی و امکان سوءاستفاده از منابع نیز باید بررسی شود.
کنترل دسترسی در Kubernetes را چگونه محدود کنیم؟
کنترل دسترسی باید بر اصل «حداقل دسترسی لازم» استوار باشد؛ یعنی هر کاربر یا سرویس فقط مجوزهایی را دریافت کند که برای وظیفه مشخص خود نیاز دارد.
مجوزهای RBAC را متناسب با وظیفه تعریف کنید
RBAC یا کنترل دسترسی مبتنی بر نقش، مشخص می کند یک هویت چه عملیاتی را روی کدام منابع انجام دهد. برای نمونه، حسابی که فقط وضعیت برنامه را مشاهده می کند، معمولا نیازی به حذف Deployment یا خواندن Secret ندارد.
در بازبینی مجوزها:
- دسترسی
cluster-adminرا به موارد ضروری محدود کنید. - از مجوزهای کلی با علامت
*بدون نیاز روشن استفاده نکنید. - دسترسی در محدوده Namespace را در صورت کافی بودن، به دسترسی سراسری ترجیح دهید.
- حساب ها و مجوزهای بدون استفاده را حذف کنید.
برای برنامه ها ServiceAccount مشخص داشته باشید
ServiceAccount هویت مورد استفاده یک برنامه برای تعامل با Kubernetes است. جدا بودن این هویت ها، تعریف و بازبینی مجوزها را آسان تر می کند.
اگر برنامه به API کوبرنتیز نیاز ندارد، اتصال خودکار توکن ServiceAccount را بررسی و در صورت امکان غیرفعال کنید. مجوز ساخت پاد نیز باید با دقت بررسی شود؛ زیرا بسته به کنترل های محیط، ممکن است امکان استفاده از هویت یا منابع حساس دیگری را فراهم کند.
چگونه امنیت پادها و کانتینرها را افزایش دهیم؟
برای کاهش ریسک، برنامه باید با کمترین اختیارات مورد نیاز اجرا شود. دسترسی اضافی به سیستم عامل میزبان یا قابلیت های حساس، باید دلیل فنی مشخص داشته باشد.
سیاست های Pod Security را اعمال کنید
Pod Security Standards سه سطح با نام های Privileged، Baseline و Restricted تعریف می کند. این سطوح، مجموعه ای از محدودیت های امنیتی برای پادها را توصیف می کنند.
Pod Security Admission می تواند این استانداردها را در سطح Namespace بررسی کند:
warn: نمایش هشدار درباره نقض سیاست.audit: ثبت تخلف در رویداد ممیزی.enforce: جلوگیری از پذیرش پاد ناسازگار.
برای محیط موجود، ابتدا ناسازگاری ها را شناسایی و رفع کنید تا اعمال محدودیت باعث اختلال ناخواسته نشود. تنظیمات نیز باید با نسخه کلاستر هماهنگ باشند. PodSecurityPolicy راهکار قدیمی حذف شده است و نباید مبنای پیاده سازی جدید باشد.
Security Context را متناسب با برنامه تنظیم کنید
Security Context برای تنظیم بخشی از محدودیت های اجرای پاد یا کانتینر استفاده می شود. موارد قابل بررسی عبارت اند از:
- اجرای برنامه با کاربر غیر root.
- جلوگیری از افزایش سطح دسترسی با
allowPrivilegeEscalation: false. - حذف Linux capabilityهای غیرضروری.
- استفاده از پروفایل مناسب seccomp.
- تنظیم فایل سیستم ریشه به حالت فقط خواندنی، در صورت سازگاری برنامه.
برای مثال، برنامه ای که فایل موقت ایجاد می کند، ممکن است به مسیر نوشتنی جداگانه نیاز داشته باشد. محدودیت ها باید همراه با آزمون عملکرد برنامه اعمال شوند.
اجرای غیر root، به تنهایی ایزوله سازی کامل یا امن بودن کانتینر را ثابت نمی کند؛ سایر دسترسی ها نیز اهمیت دارند.
امنیت شبکه در Kubernetes چگونه تامین می شود؟
امنیت شبکه باید ارتباطات لازم را مجاز و مسیرهای غیرضروری را محدود کند. جدا کردن منابع در Namespaceهای مختلف، به تنهایی مانع ارتباط شبکه میان آنها نمی شود.
ارتباطات پادها را با NetworkPolicy محدود کنید
NetworkPolicy برای کنترل بخشی از ترافیک ورودی و خروجی پادها استفاده می شود. اجرای آن به پشتیبانی افزونه شبکه کلاستر وابسته است؛ وجود فایل سیاست، به تنهایی اثبات نمی کند که ترافیک محدود شده است.
در یک برنامه فروشگاهی، می توان ارتباط بخش وب با API و ارتباط API با پایگاه داده را مجاز کرد، در حالی که دسترسی مستقیم بخش وب به پایگاه داده محدود باشد.
رویکرد default deny می تواند مبنای تعریف ارتباطات مجاز قرار بگیرد، اما باید نیازهایی مانند DNS، مانیتورینگ و سرویس های بیرونی نیز در طراحی سیاست دیده شوند. سیاست شبکه را با آزمون ارتباط مجاز و غیرمجاز بررسی کنید.
NetworkPolicy استاندارد، جایگزین رمزنگاری ترافیک یا همه کنترل های لایه کاربرد نیست.
دسترسی به اجزای مدیریتی را کنترل کنید
دسترسی به API Server و اجزای مدیریتی باید متناسب با نیاز عملیاتی محدود شود. درباره endpointهای عمومی، علاوه بر احراز هویت و مجوزها، محدودیت شبکه و امکانات سرویس دهنده را بررسی کنید.
نباید دسترسی غیرضروری به etcd یا رابط مدیریتی نودها از اینترنت فراهم باشد. مسیر دسترسی مدیران، دسترسی اضطراری و مسئول بازبینی این تنظیمات نیز باید مشخص باشد.
مدیریت امن Secrets در Kubernetes چگونه انجام می شود؟
Secret برای نگهداری داده هایی مانند رمز عبور، توکن و کلید استفاده می شود، اما ساختن یک Secret به معنی محافظت کامل از محتوای آن نیست.
Base64 را با رمزنگاری اشتباه نگیرید
Base64 یک روش کدگذاری قابل بازگردانی است. اگر شخصی مقدار کدگذاری شده را داشته باشد، معمولا می تواند محتوای آن را بازیابی کند.
بنابراین قرار دادن مقدار Base64 در فایل YAML یا مخزن کد، راهکار امنی برای نگهداری رمز نیست. رمزنگاری داده هنگام ذخیره سازی نیز باید در تنظیمات کلاستر یا سرویس مدیریت شده بررسی شود.
دسترسی و چرخه تعویض اطلاعات محرمانه را مدیریت کنید
برای حفاظت از اطلاعات محرمانه:
- مجوز خواندن Secretها را محدود کنید.
- رمزها را در لاگ، ایمیج و مخزن کد قرار ندهید.
- برنامه تعویض و ابطال اعتبارنامه ها داشته باشید.
- در صورت نیاز از سامانه مدیریت اسرار خارجی استفاده کنید.
کاربری که می تواند پادی با دسترسی به Secret ایجاد کند، ممکن است بدون خواندن مستقیم آن از API نیز به محتوا برسد. به همین دلیل، مجوزهای استقرار و اجرای برنامه هم بخشی از حفاظت از Secret هستند.
امنیت ایمیج های کانتینر را چگونه بررسی کنیم؟
ایمیج، نقطه شروع اجرای برنامه است. بررسی منبع، نسخه و وابستگی های آن باید بخشی از فرایند انتشار باشد.
ایمیج مورد استقرار را دقیق مشخص کنید
از رجیستری و ایمیج پایه قابل اعتماد استفاده کنید و مشخص باشد هر نسخه برنامه از کدام ایمیج ساخته شده است.
تگ ها می توانند به محتوای دیگری اشاره کنند. استفاده از digest، محتوای مشخصی از ایمیج را تعیین می کند و به تکرارپذیری استقرار کمک می کند. با این حال، digest نشانه امن بودن محتوا نیست و نیاز به به روز رسانی را از بین نمی برد.
بررسی آسیب پذیری را وارد فرایند CI/CD کنید
اسکن ایمیج پیش از انتشار می تواند بخشی از آسیب پذیری های شناخته شده را آشکار کند. نتیجه اسکن باید به تصمیم عملی منتهی شود: اصلاح وابستگی، تغییر ایمیج پایه یا پذیرش مستند ریسک با مسئول و مهلت مشخص.
عبور از اسکن به معنی نبود همه آسیب پذیری ها نیست. یافته های جدید نیز باید پس از استقرار پیگیری شوند. در صورت استفاده از امضای ایمیج، اعتبار امضا و هویت منتشرکننده باید هنگام پذیرش ایمیج بررسی شود؛ صرف امضا کردن کافی نیست.
چه رویدادهایی را برای شناسایی فعالیت مشکوک ثبت کنیم؟
ثبت رویدادهای مدیریتی کمک می کند مشخص شود چه هویتی، در چه زمانی و با چه نتیجه ای با API کوبرنتیز تعامل داشته است.
Audit Log با لاگ برنامه تفاوت دارد. لاگ برنامه بیشتر رفتار داخلی سرویس را نشان می دهد؛ ممیزی API برای بررسی اقداماتی مانند تغییر منابع و مجوزها کاربرد دارد.
موارد مناسب برای طراحی هشدار عبارت اند از:
- تغییر نقش ها و اتصال مجوزها به حساب ها.
- دسترسی غیرمنتظره به منابع حساس.
- ایجاد پاد با تنظیمات پرخطر.
- فعالیت مدیریتی توسط هویت غیرمنتظره.
سطح ثبت باید متناسب با نیاز انتخاب شود؛ ثبت بیش از حد جزئیات ممکن است اطلاعات حساس را وارد لاگ کند. دسترسی به لاگ ها، مدت نگهداری و مسئول رسیدگی به هشدار نیز باید مشخص باشد.
چک لیست امن سازی کلاستر کوبرنتیز
این جدول برای شروع ارزیابی پیشنهاد می شود. وضعیت هر مورد باید با شواهد محیط واقعی مشخص شود.
| حوزه | اقدام | شاهد پیشنهادی برای بررسی |
|---|---|---|
| هویت و مجوز | محدود کردن دسترسی کاربران و سرویس ها | فهرست نقش ها و مجوزهای موثر |
| حساب برنامه | استفاده از هویت متناسب با وظیفه | تنظیمات ServiceAccount و توکن |
| پاد | اعمال سیاست امنیتی سازگار | نتیجه بررسی سیاست در Namespace |
| کانتینر | کاهش اختیارات اجرای برنامه | بررسی Security Context |
| شبکه | محدود کردن مسیرهای غیرضروری | آزمون ارتباط مجاز و غیرمجاز |
| اطلاعات محرمانه | کنترل دسترسی و روش ذخیره سازی | بررسی مجوزها و تنظیمات رمزنگاری |
| ایمیج | شناسایی دقیق محتوای استقرار | رجیستری، نسخه و digest |
| انتشار | پیگیری یافته های امنیتی | گزارش اسکن و وضعیت اصلاح |
| ممیزی | ثبت فعالیت های حساس | نمونه رویداد و هشدار قابل پیگیری |
| نگهداری | تعیین مسئول و زمان بازبینی | برنامه مستند بازبینی امنیت |
برای هر نقص، مسئول اصلاح و مهلت تعیین کنید. وضعیت «تنظیم شده» را از «آزموده شده» جدا نگه دارید؛ ممکن است یک کنترل در فایل پیکربندی وجود داشته باشد، اما در عمل نتیجه مورد انتظار را ندهد.
امن سازی Kubernetes را از کجا شروع کنیم؟
اولویت ها باید بر اساس میزان دسترسی بیرونی، حساسیت داده و دامنه خسارت احتمالی تعیین شوند. برای شروع، این مسیر پیشنهادی قابل استفاده است:
- وضعیت موجود را ثبت کنید: نسخه ها، برنامه ها، هویت ها و مسیرهای دسترسی را بشناسید.
- دسترسی های پرخطر را بررسی کنید: مجوزهای مدیریتی، اعتبارنامه های افشا شده و سرویس های در دسترس عموم را اولویت دهید.
- محدودیت ها را مرحله ای اعمال کنید: اثر تغییرات بر ارتباطات و اجرای برنامه را بسنجید.
- عملکرد کنترل ها را آزمون کنید: فقط به فایل تنظیمات اکتفا نکنید.
- بازبینی را تکرار کنید: تغییر برنامه، دسترسی افراد و وابستگی ها می تواند ریسک تازه ایجاد کند.
برای مثال، در یک برنامه شامل وب، API و پایگاه داده، ابتدا مشخص کنید هر بخش به چه ارتباط و مجوزی نیاز دارد. سپس دسترسی های اضافی را کاهش دهید و عملکرد مسیر خرید، ورود و ثبت اطلاعات را دوباره بررسی کنید.
اشتباهات رایج در امنیت Kubernetes
برخی تصمیم ها، بررسی و نگهداری امنیت را دشوار می کنند:
- دادن دسترسی مدیر برای حل سریع خطا: بهتر است مجوز مورد نیاز شناسایی شود.
- اعمال یکباره محدودیت در محیط عملیاتی: تغییر بدون آزمون ممکن است سرویس را مختل کند.
- اعتماد به تنظیمات پیش فرض: تنظیمات واقعی محیط باید بررسی شوند.
- جمع آوری گزارش بدون پیگیری: یافته بدون مسئول و مهلت، ممکن است اصلاح نشود.
- استفاده از راهنمای نامتناسب با نسخه: قابلیت ها و روش های اجرایی باید با کلاستر تطبیق داده شوند.
- اعلام امن بودن کل کلاستر با یک آزمون: نتیجه هر بررسی، فقط محدوده همان بررسی را پوشش می دهد.
سوالات متداول درباره امنیت کوبرنتیز
آیا Kubernetes به صورت پیش فرض امن است؟
Kubernetes امکانات امنیتی مختلفی دارد، اما امنیت محیط به تنظیمات و نحوه استفاده از آنها وابسته است. راه اندازی کلاستر به تنهایی، برای اثبات امن بودن برنامه ها و داده ها کافی نیست.
تفاوت RBAC و NetworkPolicy چیست؟
RBAC مجوز انجام عملیات روی منابع Kubernetes را کنترل می کند. NetworkPolicy ارتباطات شبکه پادها را محدود می کند. این دو، بخش های متفاوتی از امنیت را پوشش می دهند و مکمل یکدیگر هستند.
آیا Namespaceها برنامه ها را کاملا از هم جدا می کنند؟
خیر. Namespace برای سازماندهی و محدوده بندی بخشی از منابع کاربرد دارد. جداسازی امنیتی به کنترل های دیگری مانند مجوزها، سیاست شبکه و محدودیت های اجرای پاد نیز نیاز دارد.
آیا چک لیست امنیت کوبرنتیز برای همه کلاسترها یکسان است؟
خیر. حساسیت داده، نوع برنامه، معماری و شیوه مدیریت کلاستر بر کنترل های لازم تاثیر دارند. چک لیست عمومی باید مبنای بررسی باشد و با نیاز محیط تطبیق داده شود.
برای ارزیابی امنیت کلاستر خود چه اطلاعاتی آماده کنیم؟
اگر می خواهید وضعیت کلاستر خود را بررسی کنید، اطلاعاتی مانند شیوه میزبانی، نسخه Kubernetes، نوع برنامه ها، نحوه استقرار و نیازهای دسترسی را آماده کنید. این اطلاعات به تعیین محدوده ارزیابی و اولویت اصلاحات کمک می کند.
برای بررسی نیاز پروژه و هماهنگی درباره مدیریت و پشتیبانی زیرساخت، می توانید از طریق صفحه خدمات کوبرنتیز سربروس درخواست خود را مطرح کنید. رمزها، توکن ها و فایل های حاوی اعتبارنامه را در فرم عمومی ارسال نکنید.
منابع و مستندات فنی
برای جزئیات اجرایی، مستندات متناسب با نسخه کلاستر خود را مطالعه کنید:
