در قسمت اول مقاله در مورد مراحل استفاده از کوبرنتیس یا Kubernetes صحبت کردیم و گفتیم که شامل مرحله یادگیری، آزمایش و تولید می باشد. همچنین اینکه استراتژی امنیت و پیاده‌سازی بار کاری در کوبرنتیس چگونه صورت می گیرد موضوع دیگری بود که راجع به آن صحبت کردیم. حال به ادامه مقاله خواهیم پرداخت.
مشاهده‌پذیری
- مشاهده‌پذیری بسیار برای مانیتورینگ و ایمن‌سازی یک سیستم توزیعی مثل Kubernetes مفید می باشد. می توان گفت کوبرنتیس جزئیات خیلی زیادی را جداسازی کرده و برای مانیتور کردن سیستمی مثل آن، نمی‌توان معیارهای سنجش مانند یک جریان شبکه واحد، یک ساخت یا حذف Pod یا افزایش ناگهانی کارکرد CPU روی یک Node را جمع‌آوری کرده و به‌صورت مجزا مبناسازی و مانیتور نموده، بلکه به راهی برای مانیتورینگ این معیارها در ساختار کوبرنتیس یا Kubernetes نیاز است. مثلاً یک Pod که با یک سرویس یا یک پیاده‌سازی ری‌استارت می‌شود و به‌عنوان یک باینری متفاوت با Peerهای خود یا یک فعالیت Pod یا شبکه، File System، تماس‌های سیستم Kernel با Podهای دیگر در پیاده‌سازی متفاوت می باشد. وقتی که به یک برنامه کاربردی فکر کنیم که چندین سرویس یا مایکروسرویس را تشکیل می‌دهد که توسط چندین Pod پشتیبانی می‌شوند، مسئله از قبل هم پیچیده‌تر می‌شود.
- مشاهده‌پذیری در عیب‌یابی و مشاهده‌پذیری امنیت بارهای کاری در کوبرنتیس بسیار مفید می باشد. مثلاً، مشاهده‌پذیری در مورد یک سرویس در کوبرنتیز به کاربران این امکان را می‌دهد که کارهای زیر را انجام دهند:
- تصویرسازی کلاستر کوبرنتیس به‌صورت یک گراف سرویس که نشان می‌دهد Podها چه ارتباطی با خدمات و جریان‌های ارتباطی بین خدمات دارند.
- برنامه کاربردی Overlay (Layer 7) و ترافیک شبکه (Layer 3/Layer 4) روی گراف سرویس به‌عنوان لایه‌های جداگانه‌ای که به کاربران این امکان را می‌دهند که با سادگی الگوهای ترافیک و بار ترافیکی را برای برنامه کاربردی و شبکه زیرین تعیین کنند.
ویدیوی آموزش تفاوت‌های میان دو تکنولوژی Docker و Kubernetes
ویدیوهای بیشتر درمورد کوبرنتیس یا Kubernetes
- مشاهده‌ی داده ها برای Nodeی که Pod در آن پیاده‌سازی شده است مثلاً CPU، حافظه یا سیستم‌عامل Host.
- مشاهده‌ی معیارهای مربوط به عملیات Pod، بار ترافیکی، میزان تأخیر برنامه کاربردی مانند مدت زمان HTTP، میزان تأخیر شبکه یا به عبارتی زمان رفت و برگشت شبکه یا عملیات Pod مانند پالیسی‌های RBAC، حساب‌های سرویس یا ری‌استارت Container.
- مشاهده‌ی فعالیت DNS کدهای پاسخ DNS، میزان تأخیر، بار برای یک سرویس به‌خصوص Podها آن سرویس را پشتیبانی می‌کنند.
- ردیابی تراکنش یک کاربر که به ارتباط روی چندین سرویس نیاز دارد؛ این امر تحت عنوان ردیابی توزیعی یاDistributed Tracing معروف می باشد.
- مشاهده‌ی ارتباطات شبکه‌ی یک سرویس به‌خصوص با نهادهای خارجی
- مشاهده‌ی Logهای فعالیت کوبرنتیز مانند Logهای ممیزی برای Podها و منابع مربوط به یک سرویس به‌خصوص.
قابلیت دید ترافیک شبکه
همانطور که اشاره شد، همیشه به راهکاری نیاز است که جریان‌های شبکه را به‌صورت یکپارچه‌سازی شده در سطح سرویس با ساختارهایی مثل Namespaceها، Labelها، حساب‌های سرویس یا پالیسی‌های شبکه فراهم کند تا فعالیت‌ها و کنترل‌های دسترسی اعمال‌شده به کلاستر به‌طور کارآمدی کنترل شوند. مثلاً تفاوت قابل‌توجهی بین این گزارش که IP1 با IP2 روی پورت 8080 ارتباط برقرار کرده است و این گزارش که Podهایی با برچسب Frontend با Podهایی با برچسب Backend روی پورت‌های به‌خصوصی یا الگوی ترافیکی بین پیاده‌سازی‌های Podها در یک کلاستر Kubernetes ارتباط برقرار کردند، وجود دارد. این گزارش‌گیری به کاربر امکان بررسی ارتباطات از سوی نهادهای خارجی و اعمال Feedهای تهدید مبتنی بر آدرس IP را می‌دهد تا فعالیت‌های آدرس‌های IP مخرب یا حتی ترافیک از مکان‌های جغرافیایی غیرمنتظره شناسایی گردد.
Logهای فعالیت DNS
Domain Name System یا DNS سیستمی است که برای ترجمه‌ی نام‌های دامین به آدرس‌های IP مورداستفاده قرار می‌گیرد. در کلاستر Kubernetes، بسیار ضروری میباشد که Logهای فعالیت DNS بررسی گردد تا فعالیت‌های غیرمنتظره شناسایی گردد، مثلاً Queryها به دامین‌های مخرب کدهای پاسخ DNS مثل NXDOMAIN و افزایش‌های غیرمنتظره در بایت‌ها و Packetها در Queryهای DNS شناخته‌شده می باشد.
بیشتر بخوانید: 11 دلیل اصلی برای ارجاع DNSها به سرویس Cisco Umbrella
قابلیت دید ترافیک برنامه کاربردی
دقت شود که جریان‌های ترافیک برنامه کاربردی برای پیدا کردن فعالیت مخرب مثل کدهای پاسخ غیرمنتظره و Headerهای HTTP مخرب شناخته شده مانندUser-Agent، پارامترهای Query بایستی بررسی گردند. HTTP متداول‌ترین پروتکلی است که در پیاده‌سازی‌های کوبرنتیس مورداستفاده قرار می‌گیرد، پس مهم است که با تیم تحقیقات امنیتی همکاری شود تا ترافیک HTTP برای پیدا کردن ترافیک مخرب مانیتور گردد. درصورتی‌که از پروتکل‌های برنامه کاربردی دیگر مانند Kafka ،MySQL استفاده می‌شود، باید این کار برای آن پروتکل‌ها نیز انجام گردد.
Logهای فعالیت کوبرنتیس
علاوه بر Logهای فعالیت شبکه، باید Logهای فعالیت کوبرنتیس یا Kubernetes نیز مانیتور گردد تا فعالیت مخرب شناسایی شود. مثلاً Logهایی که دسترسی آن‌ها رد شده است برای دسترسی به منبع و ساخت و اصلاح حساب سرویس بررسی گردند. همچنین Logهای ساخت و اصلاح Namespace باید برای فعالیت غیرمنتظره بررسی گردند. Logهای ممیزی کوبرنتیس که درخواست‌ها به Kubernetes API را ثبت می‌کنند، نیز باید بررسی شوند.
بیشتر بخوانید: بررسی و شناسایی Kubernetes Scan با Splunk و چگونگی دسترسی به کلاسترهای کوبرنتیس
امنیت و مشاهده‌پذیری
در یک محیط پویا مثل Kubernetes، می‌توان با مد نظر قرار دادن امنیت و مشاهده‌پذیری در کنار یکدیگر به پیاده‌سازی ایمن برنامه‌های کاربردی دست پیدا کرد. به‌عنوان‌مثال، باید کلاستر خود را «مشاهده» کرده تا بهترین راه برای پیاده‌سازی کنترل‌ها جهت ایمن‌سازی کلاستر را پیاده‌سازی نماییم. کوبرنتیس به‌عنوان یک موتور Orchestration بسیار مورداستفاده قرار می‌گیرد، زیرا طبیعتاً اخباری است و به کاربران اجازه می‌دهد که نتایج سطح بالاتر را مشخص کنند. Kubernetes همچنین دارای قابلیت‌های Built-In می باشد تا اطمینان حاصل شود که کلاستر طبق مشخصات عمل می‌کند. برای این کار، کوبرنتیس یا Kubernetes ویژگی‌های مختلف را مانیتور کرده و اگر ویژگی با مقدار تعیین شده برای یک دوره‌ی زمانی خاص متفاوت باشد، دست به عمل مثلاً ری‌استارت Pod خواهد زد. این جوانب کوبرنتیس باعث می‌شود که پیاده‌سازی قابلیت دید و کنترل‌های لازم برای ایمن‌سازی یک کلاستر دشوار گردد. کنترل‌هایی که پیاده‌سازی می‌شود باید با عملیات کوبرنتیز همخوانی داشته باشد. درنتیجه، قبل از اینکه فرد بخواهید کنترل‌هایی را به آن اضافه کند، مهم است که ساختار را درک کرده؛ مثلاً نمی‌توان با اعمال یک پالیسی که امکان ارتباط Pod با چیز دیگری را نمی‌دهد، آن Pod را جداسازی کرد. کوبرنتیس متوجه می‌شود که Pod نمی‌تواند با عناصر دیگر مثلاً سرور API ارتباط برقرار کند، تشخیص می‌دهد که Pod طبق مشخصات کار نمی‌کند و Pod را ری‌استارت کرده و جای دیگری در کلاستر قرار می‌دهد.
باید در ابتدا درک شود که Pod چگونه کار می‌کند و عملیات مورد انتظار آن چیست، سپس باید کنترل‌هایی اعمال گردند تا رخدادهای غیرمنتظره شناسایی شوند. سپس تعیین می‌کنیم که آیا رخداد غیرمنتظره مشکل عملیاتی است یا مشکل امنیتی و سپس اصلاح لازم را انجام می‌دهیم. برای انجام این کار، مشاهده‌پذیری و امنیت هر دو به یک اندازه اهمیت دارند: باید مشاهده کنیم تا متوجه شویم چه چیزی مورد انتظار است و کنترل‌های لازم را اعمال کنیم تا از اجرای عملیات مورد انتظار اطمینان حاصل گردد، سپس باید برای شناسایی رخدادهای غیرمنتظره و تجزیه‌وتحلیل آن‌ها مشاهده انجام گردد و کنترل‌های ضروری اضافه شوند تا هر مشکلی که به دلیل رخداد پیش آمده است، اصلاح گردد. درنتیجه، وقتی می‌خواهیم کلاسترهای خود را ایمن کنیم، به یک رویکرد جامع برای امنیت و مشاهده‌پذیری نیاز است.
به‌طور خلاصه:
- امنیت برای کوبرنتیس یا Kubernetes با امنیت قدیمی بسیار متفاوت است و نیازمند یک رویکرد امنیت و مشاهده‌پذیری جامع در تمام مراحل پیاده‌سازی بار کاری از ساخت، پیاده‌سازی تا اجرا می باشد.
- دات کوبرنتیس اخباری بوده و جزئیات عملیات بار کاری را جداسازی می‌کند و این یعنی بارهای کاری می‌توانند هر جایی روی شبکه‌ای از Nodeها اجرا گردند. همچنین بارهای کاری می‌توانند کوتاه‌مدت بوده و مجدداً روی Node متفاوتی ساخته شوند. ایمن‌سازی چنین سیستم اخباری و توزیعی نیازمند این است که در تمام مراحل به امنیت فکر کنیم.
- درنتیجه حتماً باید در هنگام طراحی و پیاده‌سازی یک رویکرد امنیتی جامع، به اهمیت همکاری بین تیم‌های برنامه کاربردی، پلتفرم و امنیت توجه گردد.
- MITRE و Threat Matrix for Kubernetes دو چارچوب امنیتی هستند که تیم‌های امنیتی بسیاری از آن‌ها استفاده می‌کنند.
مهم است که به همه‌ی این موارد کنار هم توجه شود، زیرا یک استراتژی امنیتی و مشاهده‌پذیری موفق، باید جامع باشد. در بخش‌های بعدی به امنیت زیرساخت خواهیم پرداخت.
