در قسمت اول مقاله در مورد مراحل استفاده از کوبرنتیز صحبت کردیم و گفتیم که شامل مرحله یادگیری، آزمایش و تولید می باشد. اینکه استراتژی امنیت و مشاهده‌پذیری Kubernetes چگونه صورت می گیرد موضوع دیگری بود که راجع به آن صحبت کردیم.
پیاده‌سازی بار کاری در کوبرنتیز چیست؟
در این بخش به شرح چرخه عمر پیاده‌سازی بار کاری در یک کلاستر کوبرنتیز خواهیم پرداخت و همچنین شرح خواهیم داد که چطور می‌توان هر مرحله را ایمن‌سازی کرد. سه مرحله‌ی پیاده‌سازی بار کاری شامل ساختن، پیاده‌سازی و اجرا هستند. برخلاف برنامه‌های کاربردی قدیمی Client-Server که در آن‌ها یک برنامه کاربردی روی یک سرور یا کلاستری از سرورها وجود داشت،برنامه‌های کاربردی در پیاده‌سازی کوبرنتیز توزیعی هستند و شبکه کلاستر Kubernetes به‌عنوان بخشی از عملیات عادی، توسط برنامه‌های کاربردی مورداستفاده قرار می‌گیرد. به دلیل این پیکربندی باید چند مسئله را مدنظر قرار داد:
- وقتی بارهای کاری و زیرساخت ایجاد می‌شوند، باید بهترین راهکارهای امنیتی را مدنظر قرار داد. این امر مهم است، زیرا برنامه‌های کاربردی در Kubernetes با استفاده از CI/CD Pipeline پیاده‌سازی می‌گردند.
- همچنین وقتی که یک کلاستر Kubernetes پیاده‌سازی شده و برنامه‌های کاربردی وارد می‌شوند نیز باید به بهترین راهکارهای امنیتی فکر کرد.
- درنهایت، برنامه‌های کاربردی برای عملیات عادی از زیرساخت و شبکه کلاستر کوبرنتیز استفاده می‌کنند و باید در زمان اجرای برنامه‌های کاربردی نیز بهترین راهکارهای امنیتی را مدنظر داشت.
شکل زیر مراحل مختلف و جوانبی را نشان می‌دهد که باید در زمان ایمن‌سازی بارهایکاری در محیط Kubernetes مدنظر قرار گیرند.
در قسمت زیر هر مرحله، جوانب مختلف امنیت که باید برای آن مرحله مدنظر قرار گیرد توصیف شده‌اند:
- مرحله‌ی ساخت، مرحله‌ای است که نرم‌افزاری را برای بار کاری یا برنامه کاربردی خود می‌سازیم و اجزای زیرساخت Host یا ماشین‌های مجازی را برای Host کردن برنامه‌های کاربردی ایجاد می‌کنیم. این مرحله بخشی از چرخه‌ی توسعه است و در اکثر موارد، تیم توسعه مسئولیت آن را برعهده دارد. در این مرحله، امنیت را برای CI/CD pipeline مدنظر قرار می‌دهیم، امنیت را برای ذخایر Image اعمال می‌کنیم، Imageها را برای پیدا کردن آسیب‌پذیری‌ها اسکن می‌کنیم و سیستم‌عامل Host را تقویت می‌نماییم. باید اطمینان حاصل کرد که بهترین راهکارها پیاده‌سازی شده‌اند تا Image Registry ایمن شده و Imageها در Image Registry دچار نقض امنیتی نشوند. برای دستیابی به این مهم عموماً باید دسترسی به Image Registry ایمن شود، هرچند کاربران زیادی Registryهای خصوصی دارند و به Imageها از Registryهای عمومی اجازه ورود نمی‌دهند. نهایتاً باید بهترین راهکارها برای مدیریت اطلاعات مهم مدنظر قرار گیرد؛ اسراری مثل رمزهای عبوری که امکان دسترسی به منابع در کلاستر را فراهم می‌کنند. پیشنهاد می‌شود که وقتی در این مرحله به امنیت فکر می‌شود، با تیم امنیت همکاری گردد تا امنیت در این مرحله با استراتژی امنیتی کلی هماهنگی داشته باشد.
بیشتر بخوانید: پلتفرم Kubernetes چیست و چه مزایایی دارد؟ – قسمت اول
- مرحله‌ی بعدی، یعنی پیاده‌سازی، جایی است که پلتفرمی را تنظیم می‌کنیم که پیاده‌سازی کوبرنتیز را اجرا می‌کند و بارهای کاری را پیاده‌سازی می‌کنیم. در این مرحله باید به بهترین راهکارهای امنیتی برای پیکربندی کلاستر کوبرنتیز و فراهم کردن دسترسی خارجی به برنامه‌های کاربردی که درون کلاستر Kubernetes اجرا می‌شوند، فکر کرد. همچنین باید کنترل‌های امنیتی مثل پالیسی‌ها را مدنظر قرار داد تا دسترسی به بارهای کاری پالیسی‌های امنیت Pod، پالیسی‌های شبکه برای کنترل دسترسی برنامه‌های کاربردی به اجرای پلتفرم و کنترل دسترسی مبتنی بر نقش RBAC برای دسترسی به منابع مثلاً ایجاد سرویس، ایجاد Namespace و اضافه کردن یا تغییر برچسب‌ها به Podها محدود گردد. در اکثر سازمان‌ها، تیم پلتفرم مسئول این مرحله است. باید هم با تیم توسعه و هم تیم امنیت همکاری کنند تا استراتژی امنیتی پیاده‌سازی گردد.
- مرحله‌ی آخر، مرحله‌ی اجرا است که در این مرحله، برنامه کاربردی پیاده‌سازی شده و عملیاتی است. در این مرحله باید به امنیت شبکه فکر کرد که شامل کنترل با استفاده از پالیسی شبکه، دفاع در مقابل تهدید با استفاده از تکنیک‌هایی برای شناسایی و پیشگیری از فعالیت مخرب در کلاستر و کنترل‌های امنیت سازمانی مثل تطبیق‌پذیری، ممیزی و رمزگذاری است. تیم امنیت مسئول این مرحله از پیاده‌سازی است. به‌عنوان عضوی از تیم امنیت، باید با پلتفرم و تیم‌های توسعه همکاری کرده و امنیت اجرایی را پیاده‌سازی نمود. همکاری بین تیم‌ها توسعه، پلتفرم و امنیت برای ساخت یک استراتژی امنیتی کارآمد بسیار مهم است. پیشنهاد می‌شود اطمینان حاصل گردد که تمام این تیم‌ها هماهنگ هستند.
بیشتر بخوانید: معرفی و نحوه عملکرد Kubernetes در vSphere به همراه بررسی مزایای این تکنولوژی
- باید توجه شود که برخلاف استراتژی‌های امنیتی که امنیت در یک نقطه‌ی بالا مثل Perimeter قرار دارد، در مورد کلاستر Kubernetes، امنیت باید در هر مرحله اعمال شود. به‌علاوه تمام تیم‌های درگیر برنامه کاربردی، پلتفرم و امنیتپ نقش بسیار مهمی در پیاده‌سازی امنیت ایفا می‌کنند، پس کلید پیاده‌سازی یک استراتژی موفق، همکاری بین تیم‌ها است. باید به یاد داشت که امنیت مسئولیتی مشترک است. در ادامه، هر مرحله و تکنیک‌های قابل‌استفاده برای ساخت استراتژی بررسی می‌گردد.
• استراتژی زمان ساخت: حرکت به چپ
اسکن Image
در این مرحله، باید اطمینان حاصل شود که برنامه‌های کاربردی مشکلات Patchنشده‌ی اساسی نداشته باشند که در دیتابیس آسیب‌پذیری ملی تحت عنوان شمارش آسیب‌پذیری متداول یا CVE افشا شده باشد و اینکه کد و وابستگی‌های برنامه کاربردی اسکن شوند تا Exploitها و بخش‌های کد آسیب‌پذیری پیدا شوند. Imageهایی که به‌عنوان Container ساخته و ارائه می‌شوند، اسکن می‌گردند تا آسیب‌پذیری‌های حیاتی یا بزرگ که جزء CVEها هستند و Patch نشده‌اند پیدا شود. این امر معمولاً با بررسی Image ابتدایی و تمام Packageهای آن در مقابل یک دیتابیس که Packageهای آسیب‌پذیر را ردیابی می‌کند، انجام می‌شود. برای پیاده‌سازی اسکن، چندین ابزار وجود دارد، هم به‌صورت متن‌باز و هم تجاری که برای کاربران قابل‌دسترسی هستند. مثلاً Whitesource ،Snyk ،Trivy ،Anchor و حتی ارائه‌دهندگان Cloud مثل Google قابلیت اسکن کردن Imageهای Container را ارائه می‌دهند. پیشنهاد می‌شود که یک راهکار اسکن انتخاب شود که درک کند Containerها چطور ساخته می‌شوند و نه‌تنها سیستم‌عامل روی Host، بلکه Imageهای ابتدایی برای Containerها را نیز اسکن کند. با توجه به طبیعت پویای پیاده‌سازی‌های Kubernetes، بسیار مهم است که CI/CD Pipeline ایمن‌سازی گردد؛ باید اسکن کد و Image بخشی از Pipeline باشد و Imageهایی که از Image Registry ارائه می‌شوند باید برای نقض‌های امنیتی چک شوند. باید اطمینان حاصل گردد که دسترسی به Registry کنترل می‌شود تا از نقض امنیتی پیشگیری گردد. عبارت محبوبی برای توصیف این مرحله حرکت امنیت به چپ به سمت تیم توسعه است، که تحت عنوان امنیت حرکت به چپ نیز معرف است.
تقویت سیستم‌عامل Host
در اینجا باید اطمینان حاصل کرد که برنامه کاربردی که پیاده‌سازی می‌گردد محدود است به داشتن سطح دسترسی لازم روی Hostی که در آن پیاده‌سازی می‌گردد. برای دستیابی به این مهم، باید از یک سیستم‌عامل Host تقویت‌شده استفاده کرد که از کنترل‌هایی پشتیبانی می‌کند که امکان محدودیت برنامه‌های کاربردی به سطوح دسترسی ضروری مثل تماس‌های سیستم و دسترسی به سیستم فایل را فراهم کند. این امر باعث می‌شود که حملات مربوط به بالا رفتن سطح دسترسی، به‌طور کارآمدی خنثی شوند؛ در این حملات یک آسیب‌پذیری در نرم‌افزاری که در یک Container پیاده‌سازی می‌شود، مورداستفاده قرار می‌گیرد تا دسترسی به سیستم‌عامل Host حاصل شود.
به حداقل رساندن آسیب‌پذیری‌های امنیتی: Imageهای Container ابتدایی
پیشنهاد می‌شود که ترکیبات Container Image بررسی شود و Packageهای نرم‌افزاری که Image ابتدایی را می‌سازند به حداقل رسیده و فقط شامل Packageهایی باشند که برای اجرای برنامه کاربردی کاملاً ضروری هستند. در Imageهای Container مبتنی بر Dockerfile، می‌توان از یک Image والد شروع کرد و سپس برنامه‌های کاربردی را به Image اضافه نمود تا Container Image ساخته شود. مثلاً می‌توان با ساختن یک Image ابتدایی در Docker با استفاده از دستور FROM scratch شروع کرد که یک Image حداقلی می‌سازد. سپس می‌توان برنامه‌های کاربردی و Packageهای لازم را اضافه کرد که کنترل کاملی از ترکیب Container Imageها را ارائه می‌دهند و همچنین به مدیریت CVE کمک می‌کنند، زیرا دیگر لازم نیست نگران Patch کردن CVEها در یک Container Image باشیم که برای برنامه کاربردی ما الزامی نیست. درصورتی‌که ساختن یک Image از ابتدا ممکن نباشد، می‌توان از یک Distroless Image ،Image توزیعی لینوکس که ساده‌سازی شده است) یا یک Image حداقلی Alpine به‌عنوان Image ابتدایی برای Container استفاده کرد.
این تکنیک‌ها به کاربر کمک می‌کند استراتژی امنیتی زمان ساخت خود را طراحی و پیاده‌سازی کند. تیم توسعه با همکاری با تیم‌های پلتفرم و امنیت، مسئولیت طراحی و پیاده‌سازی امنیت زمان ساخت را برعهده دارد تا اطمینان حاصل شود که با استراتژی امنیتی کلی همخوانی داشته باشد. هشدار داده می‌شود که افراد باور نکنند امنیت حرکت به چپ می‌تواند کل استراتژی امنیتی باشد. این حرف نادرست است و رویکرد ساده‌لوحانه‌ای به ایمن‌سازی بارهای کاری محسوب می‌شود. جوانب مهم دیگری نیز ازجمله امنیت پیاده‌سازی و اجرا وجود دارند، که باید به‌عنوان بخشی از استراتژی امنیتی مدنظر قرار گیرند.
استراتژی زمان پیاده‌سازی
- مرحله‌ی بعدی در ایمن‌سازی بارهای کاری، ایمن‌سازی پیاده‌سازی است. برای دستیابی به این مهم، باید کلاستر کوبرنتیز که بارهای کاری در آن پیاده‌سازی می‌شوند تقویت گردد. در این زمینه به یک بررسی پرجزئیات از پیکربندی کلاستر Kubernetes نیاز است تا اطمینان حاصل گردد که با بهترین راهکارهای امنیتی همسو باشد. باید از ساخت یک مدل اعتماد برای اجزای مختلف کلاستر شروع کرد. مدل اعتماد چارچوبی است که در آن یک پروفایل تهدید و مکانیزم‌هایی برای پاسخ به آن بررسی می‌شود. باید از ابزاری مثل کنترل دسترسی مبتنی بر نقش RBAC، طبقه‌بندی‌های برچسب، نظارت روی برچسب و کنترل پذیرش استفاده شود تا این مدل اعتماد طراحی و پیاده‌سازی گردد. این موارد مکانیزم‌هایی هستند که برای کنترل دسترسی به منابع و کنترل‌ها و اعتبارسنجی اعمال‌شده در زمان ساخت منبع مورد استفاده قرار می‌گیرند. اجزای حیاتی دیگر در کلاستر Kubernetes Datastore و Kubernetes API Server هستند و باید در هنگام طراحی مدل اعتماد برای این اجزا، توجه دقیقی به جزئیاتی مثل کنترل دسترسی و امنیت داده شود. پیشنهاد می‌شود که از اطلاعات اعتباری قوی، زیرساخت کلیدی عمومی یا PKI برای دسترسی و امنیت لایه انتقال TLS رمزگذاری داده در حین انتقال استفاده گردد.
- باید به کلاستر کوبرنتیز فکر شود که در آن، بارهای کاری حیاتی پیاده‌سازی شده‌اند و سپس باید یک مدل اعتماد برای آن طراحی گردد. برای دستیابی به این هدف لازم است که کنترل‌های امنیتی در Perimeter بررسی گردد؛ کاری که به دلیل معماری‌های پیاده‌سازی Kubernetes چالش‌برانگیز خواهد بود. اکنون فرض می‌کنیم که محصولات کنونی مثل Gatewayهای کنترل دسترسی وب و فایروال‌های نسل جدید که در Perimeter پیاده‌سازی شده‌اند، نسبت به معماری Kubernetes آگاهی ندارند. پیشنهاد می‌شود که با یکپارچه‌سازی با این دستگاه‌ها به این مشکل پاسخ داده شود، این کار باعث می‌شود که آن‌ها نسبت به ساختار کلاستر Kubernetes آگاهی پیدا کنند تا در اعمال کنترل‌های امنیتی در Perimeter کارآمد باشند. اینگونه می‌توان یک استراتژی امنیتی بسیار کارآمد را ایجاد کرد که در آن دستگاه‌های امنیت Perimeter همراه با امنیت پیاده‌سازی شده درون کلاستر Kubernetes کار می‌کنند. مثلاً فرض می‌کنیم که لازم است کاری کنیم این دستگاه‌ها از هویت بارهای کاری، آدرس IP، پورت TCP/UPD و غیره آگاهی پیدا کنند. این دستگاه‌ها می‌توانند به‌طور کارآمدی از Hostهایی که کلاستر Kubernetes را می‌سازند حفاظت کنند، اما در اکثر مواقع نمی‌توانند بین بارهای کاری که روی یک Host واحد اجرا می‌شوند، تمایز قائل شوند. اگر Kubernetes در یک محیط ارائه‌دهنده‌ی Cloud اجرا شود، می‌توان از گروه‌های امنیتی که فایروال‌های مجازی هستند استفاده کرد که امکان دسترسی به گروهی از Nodeها را فراهم می‌نمایند، مثلاً Instanceهای EC2 در Amazon Web Services که بارهای کاری را Host می‌کنند. گروه‌های امنیتی بیشتر از فایروال‌ها و Gatewayهای امنیتی قدیمی با معماری Kubernetes همسو هستند؛ اما حتی این گروه‌های امنیتی هم از ساختار برای بارهای کاری که درون کلاستر اجرا می‌شوند، آگاهی ندارند.
- به‌طور خلاصه می‌توان گفت که وقتی می‌خواهیم امنیت زمان پیاده‌سازی را مدنظر قرار دهیم، باید یک مدل اعتماد را برای کلاستر کوبرنتیز پیاده‌سازی کنیم و یک یکپارچه‌سازی کارآمد را با دستگاه‌های امنیتی Perimeter بسازیم که از کلاستر حفاظت کنند.
• امنیت زمان اجرا
- حالا که یک استراتژی برای ایمن‌سازی در مراحل ساخت و پیاده‌سازی آماده شده است، باید به امنیت زمان اجرا فکر کرد. عبارت امنیت زمان اجرا برای جوانب مختلفی از ایمن‌سازی یک کلاستر Kubernetes مورداستفاده قرار می‌گیرد، مثلاً روی یک Host که نرم‌افزاری را اجرا می‌کند، اما هر پیکربندی که از Host و بارهای کاری در مقابل فعالیت غیرمجاز حفاظت می‌کند، مثلاً تماس‌های سیستم، دسترسی فایل نیز امنیت زمان اجرا نامیده می‌شود. در این بخش روی بهترین راهکارهای امنیتی موردنیاز برای اطمینان حاصل کردن از عملیات ایمن شبکه کلاستر Kubernetes تمرکز خواهد شد. Kubernetesیک تنظیم‌کننده Orchestrator است که بارهای کاری و برنامه‌های کاربردی را روی شبکه‌ای از Hostها پیاده‌سازی می‌کند. باید امنیت شبکه را به‌عنوان یکی از جوانب خیلی مهم امنیت زمان اجرا مدنظر قرار داد.
کوبرنتیز در مقایسه با پارتیشن‌بندی ایستا و آماده‌سازی سرورها یا VMها، چابکی را بالا می‌برد و استفاده‌ی کارآمدتری از منابع رایانشی انجام می‌دهد و برای این کار به‌صورت پویا بارهای کاری را روی کلاستر برنامه‌ریزی کرده و استفاده از منابع را روی هر Node مدنظر قرار می‌دهد و بارهای کاری را روی یک شبکه‌ی Flat به هم متصل می‌کند. به‌طور پیش‌فرض، وقتی که یک بار کاری پیاده‌سازی می‌شود، می‌توان Pod مربوطه را روی هر Node در کلاستر، با هر آدرس IP در حوزه‌ی آدرس IP متعلق به Pod برنامه‌ریزی کرد.
