برای هر شرکتی که پتانسیل ابر و Kubernetes را بررسی می کند، استفاده از زیرساخت به عنوان کد، امنیت به عنوان کد و اتوماسیون ضروری است.
تا همین اواخر، شرکت بیمه اتکایی جهانی ما از یک زیرساخت سنتی اولیه استفاده میکرد که تنها به سختافزار خودمان در چندین مرکز داده متفاوت در سراسر جهان متکی بود. با این حال، متوجه شدیم که این زیرساخت میتواند برخی از ابتکارات ما را که نیازمند توسعه سریعتر برنامهها و تحویل سریعتر محصولات و خدمات دیجیتال هستند، به تأخیر بیندازد.
این درک ما را بر آن داشت تا زیرساخت ابری جدید و فرآیندهای استقرار جدید را برای چندین بار کاری دنبال کنیم که باعث افزایش اتوماسیون، کاهش پیچیدگی و پشتیبانی از عملیات ناب و چابک میشود. طبیعتاً امنیت نیز در اولویت بود. با انتقال برخی از بارهای کاری حیاتی خود از شبکه عظیم منحصر به فرد خود به فضای ابری، باید اطمینان حاصل کنیم که محیط جدید ما می تواند به طور مداوم در برابر تهدیدات احتمالی سخت شود.
انتخاب ابر، منبع باز و Kubernetes
هدف تیم معماری من ایجاد شبکه های کوچک در فضای ابری بود که منابع آن در نهایت متعلق به تیم های دیگر باشد. در این نقش فعالکننده، ما مبنای زیرساختی را برای تیمها فراهم میکنیم تا به استقرار سریع برنامههای نوآورانه دست یابند و سریع به بازار برسند.
شرکت ما یک فروشگاه مایکروسافت است، بنابراین انتخاب ایجاد زیرساخت ابری جدید ما در Microsoft Azure واضح بود. انتخاب بعدی ما این بود که به سمت برنامه های کاربردی مبتنی بر میکروسرویس برویم و به امکانات اتوماسیون و هر دو زیرساخت به عنوان کد و امنیت به عنوان کد توجه کنیم.
در حالی که افسران امنیتی ما در ابتدا نسبت به راه حل های منبع باز محتاط بودند، بررسی ابزارهای ابری به سرعت ما را به این درک رساند که بهترین گزینه های موجود همه منبع باز هستند. (از نظر من نگرانی های امنیتی در مورد منبع باز منسوخ شده است. فناوری های قوی با جوامع قوی پشت سر آنها به همان اندازه ایمن هستند، اگر نه بیشتر از راه حل های اختصاصی.) بودجه پروژه هایی که زیرساخت ابری ما پشتیبانی می کند باید در نظر گرفته شود. همچنین، ما را تشویق می کند تا از هزینه های مجوز اختصاصی و قفل کردن دور شویم. این باعث شد تعهد ما به منبع باز یک انتخاب طبیعی باشد.
برای هماهنگ کردن زیرساخت های میکروسرویس ما، تیم من مشتاق بود Kubernetes را امتحان کند. با این حال، اولین پروژه ما شامل کار برای تیمی بود که اصرار داشتند از Docker Swarm دارای مجوز استفاده کنند، یک گزینه محبوب درست قبل از ظهور شهابسنگ Kubernetes. ما پروژه را با استفاده از Docker Swarm به پایان رساندیم، با ترتیبی که میتوانستیم با قرار دادن Kubernetes در همان کار آزمایش کنیم. این مقایسه به وضوح نشان داد که Kubernetes انتخاب برتر برای نیازهای ما است. سپس از Kubernetes برای همه پروژههای بعدی استفاده کردیم.
معماری خوشه Kubernetes ما در Azure
خوشههای Kubernetes که ما مستقر میکنیم با استفاده از URLهای واقعی قابل دسترسی هستند که توسط گواهیهای امنیتی محافظت میشوند. برای انجام این کار، معماری ما در Azure شامل یک متعادل کننده بار و یک منطقه DNS متعلق به پروژه، KeyVault (یک فروشگاه اسرار امن Azure) و ذخیرهسازی با استفاده از یک ذخیرهسازی شی بومی Azure است. معماری ما همچنین شامل یک صفحه کنترل در داخل خوشه است که به طور کامل توسط Azure مدیریت می شود. دسترسی خارجی به هر یک از این مؤلفهها توسط فایروالهای سنتی محافظت میشود، و دسترسی به آدرسهای IP خاص را به شدت محدود میکند. (به طور پیش فرض، دسترسی به شبکه خودمان نیز محدود است.)
چارچوب تقویت کننده ما، که از آن برای شروع پروژه های جدید استفاده می کنیم، چندین مؤلفه را در خوشه Kubernetes پیاده سازی می کند. یک کنترل کننده ورودی، دسترسی خارجی به منابع مستقر در خوشه، مانند ریزسرویس های پروژه را باز می کند. این شامل یک پروکسی OAuth است که مطمئن می شود همه ورودها توسط Azure AD مجاز است. یک سرور DNS خارجی سرویس DNS را در منطقه DNS ایجاد می کند. کنترلر اسرار ما اسرار را از Azure Key Vault (اطلاعاتی که نباید در خوشه نگهداری شود و اگر خوشه باید از بین برود نباید از بین برود) واکشی می کند. یک S3 API با منابع ذخیره سازی داده ارتباط برقرار می کند. یک مدیر گواهی، گواهیهای ویژهای را برای دسترسی TLS ایجاد میکند، در مورد ما به صورت رایگان با استفاده از Let’s Encrypt.
ما همچنین از ابزارهایی برای نظارت، ثبت و ردیابی استفاده میکنیم. برای نظارت، ما از استانداردهای صنعت Prometheus و Grafana. گزارشگیری از Grafana Loki استفاده میکند. ردیابی از Jaeger استفاده میکند. ما همچنین از Linkerd بهعنوان شبکه سرویس محافظ خود استفاده کردیم، که یک بهبود اختیاری برای استقرار Kubernetes است.
قابلیت مشاهده و اتوماسیون امنیتی Kubernetes
آنچه که اختیاری نیست، وجود راه حل امنیتی مخصوص Kubernetes است. در اینجا ما از NeuVector بهعنوان یک پلتفرم امنیتی کانتینر بومی Kubernetes برای مشاهده برنامههای انتها به انتها و مدیریت خودکار آسیبپذیری استفاده میکنیم.< /p>
وقتی برای اولین بار رویکرد خود را به امنیت در فضای ابری در نظر گرفتیم، ابزارهای اسکن آسیبپذیری و حفاظت از حجم کار برنامهها به عنوان آخرین خط دفاعی و مهمترین آنها برای اعمال صحیح برجسته بودند. خوشه Kubernetes می تواند با حملات از طریق ورود و خروج مواجه شود و زنجیره های حمله ای که در محیط افزایش می یابد.
برای محافظت از توسعه و استقرار برنامه، هر مرحله از خط لوله CI/CD باید به طور مداوم برای آسیبپذیریها یا پیکربندیهای نادرست حیاتی (از این رو NeuVector) از مرحله ساخت تا تولید اسکن شود. . برنامه ها باید از سوء استفاده های کانتینری، حملات روز صفر و تهدیدات داخلی محافظت شوند. خود Kubernetes نیز یک هدف حمله است، با آسیبپذیریهای حیاتی که در سالهای اخیر فاش شده است.
یک ابزار امنیتی مؤثر Kubernetes باید بتواند ایمنی همه اتصالات در محیط Kubernetes را تجسم و به طور خودکار تأیید کند و همه فعالیتهای غیرمنتظره را مسدود کند. همچنین باید بتوانید خطمشیهایی را تعریف کنید تا ارتباطات مورد انتظار در محیط Kubernetes را در لیست سفید قرار دهید و رفتار غیرعادی را علامتگذاری کنید یا مسدود کنید. با استفاده از این حفاظتهای زمان اجرا، حتی اگر یک مهاجم به محیط Kubernetes نفوذ کند و یک فرآیند مخرب را شروع کند، آن فرآیند بلافاصله و بهطور خودکار قبل از ایجاد خرابی مسدود میشود.
اهمیت زیرساخت به عنوان کد
استقرار Kubernetes ما از زیرساخت به عنوان کد (IaC) استفاده می کند، به این معنی که هر جزء از معماری ما که در بالا ذکر شد می تواند با استفاده از فایل های ساده YAML ایجاد و بازسازی شود. IaC ثبات و تکرارپذیری حیاتی را در پروژهها و خوشههای ما ممکن میسازد. به عنوان مثال، اگر یک خوشه به هر دلیلی نیاز به تخریب داشته باشد یا بخواهید تغییری ایجاد کنید، می توانید به سادگی آن خوشه را از بین ببرید، هر تغییری را اعمال کنید و دوباره آن را مستقر کنید. IaC همچنین برای شروع کار با خوشههای توسعه و تولید ایستاده مفید است، که از بسیاری از تنظیمات مشابه استفاده میکنند و سپس برای تکمیل فقط به تغییرات مقادیر ساده نیاز دارند.
نکته مهم این است که IaC ممیزی همه تغییرات اعمال شده در خوشه ما را نیز فعال می کند. انسان ها بیش از حد مستعد خطاها و پیکربندی های نادرست هستند. به همین دلیل است که ما اتوماسیون داریم. اتوماسیون استقرارهای امن ما را قابل تکرار می کند.
اهمیت امنیت به عنوان کد
به همان دلایل، اتوماسیون و امنیت کد (SaC) نیز برای راهاندازی حفاظتهای امنیتی Kubernetes ما ضروری است. ابزار امنیتی Kubernetes انتخابی شما باید امکان استفاده از تعاریف منابع سفارشی (CRD) را فراهم کند، اشیایی که به عنوان فایل های YAML در خوشه آپلود می کنید تا به راحتی سیاست های امنیتی را پیاده سازی و کنترل کنید. همانطور که IaC ثبات و قابلیت اطمینان زیرساخت را تضمین می کند، SaC تضمین می کند که فایروال های پیچیده و خدمات امنیتی به درستی پیاده سازی می شوند. توانایی معرفی و بازتولید حفاظتهای امنیتی بهعنوان کد، خطاها را از بین میبرد و اثربخشی را تا حد زیادی افزایش میدهد.
بعدی چیست
با نگاهی به آینده زیرساخت Kubernetes خود، قصد داریم از GitOps برای استقرار چارچوب خود با Flux به عنوان یک عامل استقرار بالقوه استفاده کنیم. همچنین قصد داریم از Gatekeeper برای ادغام Open Policy Agent با Kubernetes، ارائه کنترل خط مشی بر ایجاد کانتینر مجاز، کانتینرهای ممتاز و غیره استفاده کنیم.
برای هر سازمانی که شروع به کشف پتانسیل های ابر و Kubernetes می کند، من به شدت توصیه می کنم که معماری و گزینه های امنیتی مشابهی را که در اینجا شرح داده ام بررسی کنند، به خصوص وقتی صحبت از اتوماسیون و پیاده سازی زیرساخت به عنوان کد و امنیت به عنوان کد می شود. انجام این کار باید راهی آسانتر برای استفاده موفقیتآمیز از Kubernetes و بهرهگیری از مزایای فراوان آن باشد.
Karl-Heinz Prommer معمار فنی در Munich Re است.
—
New Tech Forum مکانی برای کاوش و بحث در مورد فناوری سازمانی نوظهور در عمق و وسعت بی سابقه ای فراهم می کند. انتخاب ذهنی است، بر اساس انتخاب ما از فناوری هایی که معتقدیم مهم هستند و برای خوانندگان InfoWorld بیشترین علاقه را دارند. InfoWorld وثیقه بازاریابی را برای انتشار نمی پذیرد و حق ویرایش تمام محتوای ارائه شده را برای خود محفوظ می دارد. همه سوالات را به newtechforum@infoworld.com ارسال کنید.
پست های مرتبط
درس های آموخته شده از ایمن سازی Kubernetes در ابر
درس های آموخته شده از ایمن سازی Kubernetes در ابر
درس های آموخته شده از ایمن سازی Kubernetes در ابر