معرفی

تیم پلتفرم داده زمان واقعی Grab یا همان Coban، به عنوان یکی از بزرگترین خوشه های Kafka در تمام عموده های مختلف فعالیت داشته است و تمرکز قوی بر روی ارائه عملکرد برتر و 99.99٪ در دسترس بودن داشته است.

امنیت همیشه یکی از اولویت های اصلی Grab بوده است و به محض اینکه متقلبان ادامه می دهند، نیاز به تقویت امنیت پلتفرم جریان داده هایمان افزایش یافته است. یکی از راه های انجام این کار، انتقال از یک کنترل دسترسی مبتنی بر شبکه به امنیت و حفاظت به شکل حالت صفر اعتماد است، مانند:

تأیید هویت: اولین موردی که برای هر سیستم از راه دور - مشتریان و سرورها - تأیید و تعیین می شود، تأکید بر پیام رسان است که پیش از هر ارتباط بعدی صورت می گیرد.مجوز دهی: به Kafka بر اساس اصل کمترین امتیاز دسترسی دسترسی داده می شود؛ هیچ دسترسی به طور پیش فرض داده نمی شود. مشتریان Kafka با موضوعات Kafka سفیدلیست شده و مجوزها - مصرف یا تولید - که به طور دقیق نیاز دارند ، مرتبط هستند. همچنین، دسترسی اعطا شده قابل بررسی است.محرمانگی: تمام ترافیک در حالت انتقال رمزگذاری می شود.

راه حل

ما تصمیم گرفتیم که برای تأیید هویت و رمزگذاری از امنیت Layers Transport لزومیتا استفاده کنیم. این لایه به مشتریان امکان می دهد تا سرورها را تأیید و مشتریان جهت تأیید هویت را برعکس جواب دهد.

Kafka از سایر مکانیزم های تأیید هویت مانند OAuth یا مکانیزم احراز هویت سالت چالش پاسخ (SCRAM) پشتیبانی می کند ، اما ما به ماژول Transport Layer Security موتور OpenSSL تسلط پیدا کرده ایم زیرا قادر است هویت همتای خود را آفلاین تأیید کند. این توانایی تأیید به این معنی است که سیستم ها نیازی به اتصال فعال به یک سرور تأیید هویت ندارند تا هویت همتای خود را تعیین کنند. این امکان را فراهم می کند که در محیط های شبکه متفاوت عمل کرد که همه طرف ها به یک مرکز اصلی دسترسی ندارند.

ما برای تولید گواهی نامه های کاربران و سرورها، از Vault Hashicorp و موتور PKI آن استفاده می کنیم. این به ما امکان می دهد استفاده از گواهی نامه های با مدت زمان کوتاه برای مشتریان را مورد اجبار قرار دهیم که این یک راه برای کاهش تأثیر بالقوه یک گواهی نامه کاربر در صورت تخلف یا به اشتراک گذاری مخرب است. ما درست گفتیم صفر اعتماد؟

برای مجوز دهی، ما روی Control دسترسی الموعات مبتنی بر سیاست (PBAC) که یک راه حل قابل مقیاس می باشد نسبت به کنترل دسترسی مبتنی بر نقش (RBAC) تمرکز کردیم و OPA را به عنوان پلتفرم سیاست های ما انتخاب کردیم. از پشتیبانی گسترده انجمن OPA نیز بهره بردیم.

برای ادغام mTLS و OPA با Kafka، ما از Strimzi به عنوان اپراتور Kafka در Kubernetes استفاده کردیم. در یک مقاله پیشین، ما به Strimzi اشاره کرده و به اینکه چگونه می تواند با قابلیت مقیاس پذیری و بی طرفیت ابر کمک کند. امنیت داخلی بدون شک یکی از دلایل اصلی وجود Strimzi بود.

تأیید هویت سرور

ما ابتدا برای هر محیط (مرحله، تولید، و غیره) یک موجودیت گواهی معتبر راهبردی را تعریف می کنیم. این CA روت، که در طرح به رنگ آبی است، توسط خوشه Vault Hashicorp مدیریت می شود. باید توجه کنید که رنگ گواهی نامه ها، کلیدها، پشتیبانی بر روی پیام رسان ها و امضاها در طول این مقاله یکسان است.

برای امن کردن ارتباطات داخلی خوشه، مانند ارتباطات بین بروکر Kafka و پالایه های Zookeeper، Strimzi یک CA خوشه تنظیم می کند که توسط CA روت امضا می شود (مرحله 1). CA خوشه سپس برای امضای گواهی های کاربران و zookeeper فراداده ها استفاده می شود (مرحله 2). در نهایت، گواهی عمومی CA روت به truststore بروکر Kafka و Zookeeper داخلی استخراج می شود (مرحله 3)، بنابراین تمام پالایه ها می توانند گواهی های خود را با استفاده از هویت خود به صورت نیز معتبر کنند.

CA خوشه تعبیه شده StrimziCertificates هنگام ایجاد جدید Kafka و Zookeeper pods، چهارپایه معتبر تولید می کند. عملیات امضا کردن (مرحله 2) به صورت خودکار توسط Strimzi انجام می شود.

برای دسترسی کاربر به بروکرهای Kafka، Strimzi یک مجموعه مختلف از CA می سازد و گواهی های سرور را، همانطور که در نمودار بعدی نشان داده شده است، طبقه بندی می کند.

همان CA روت در شکل 1، یک CA میانی متفاوت طبقه بندی می کند، که جامعه Strimzi آن را CA مشتری می نامد (مرحله 1). این نامگذاری گمراه کننده است چرا که در واقع هیچ گواهی کاربری امضا نمی شود، بلکه تنها گواهی های سرور (مرحله 2) که در گوشی های جانبی بروکر Kafka قرار می گیرند. این گواهی های سرور برای مشتریان Kafka برای تأیید هویت سرور هستند. در این مرحله، گواهی عمومی CA روت در truststore کاربر Kafka وارد می شود (مرحله 3).

تأیید هویت مشتری

برای تأیید هویت مشتری، ابتدا کلاینت Kafka باید به Hashicorp Vault تأیید هویت کند و درخواستی برای گواهی گذرا از موتور PKI Vault داشته باشد (مرحله 1). Vault یک گواهی صادر کرده و آن را با استفاده از CA روت خود امضا می کند (مرحله 2). با این گواهی، کلاینت می تواند به بروکرهای Kafka تأیید هویت کند که از گواهی عمومی CA روت قبلاً در truststore خود استفاده می کنند، همانطور که قبلاً توضیح داده شد (مرحله 3).

درخت CA

اضافه کردن سه فرآیند متفاوت تأیید هویت که تازه توضیح دادیم، درخت CA هم اکنون به این شکل است. توجه کنید که این یک نمای ساده شده برای یک محیط تنها، یک خوشه تنها و دو مشتری است.

همانطور که از قبل اشاره شد، هر محیط (مرحله، تولید، و غیره) دارای CA روت خود است. در هر محیط، هر خوشه Strimzi دارای جفتی از CA های متوسطی خود است: CA خوشه و CA کاربر. در سطح برگ، pods Zookeeper و بروکر Kafka هر کدام گواهی های جداگانه ای دارند.

در سمت راست نمودار، هر کلاینت Kafka هرگاه نیاز به اتصال به Kafka داشته باشد، می تواند یک گواهی گذرا از Hashicorp Vault دریافت کند. هر تیم یا برنامه ای نقش PKI استفاده شده در Hashicorp Vault را دارا است، که محدود کننده آنچه می توان به گواهی خود درخواست کرد (مانند موضوعات، TTL و غیره) است.

مستند سازی Strimzi

ما از Terraform استفاده فراگیری برای مدیریت و فراهم کردن خوشه های Kafka و مولفه های مربوط به Kafka خود هستیم. این به ما امکان می دهد به سرعت و به صورت قابل اعتماد خوشه ها جدید ایجاد کنیم و عملیات مقیاس خوشه را انجام دهیم.

زیر پوشش ، استقرار Kafka Strimzi یک استقرار Kubernetes است. برای افزایش عملکرد و قابلیت اطمینان خوشه Kafka ، به ازای هر بروکر Kafka Strimzi و هر پالایه Zookeeper ، از پالایه های کوبرنتیز اختصاصی استفاده می کنیم با تراشه ها و قابلیت تحمل. این اطمینان حاصل می کند که تمام منابع یک پالایه تنها به طور انحصاری به یک بروکر Kafka تنها یا یک پالایه Zookeeper تنها اختصاص داده می شوند.

همچنین تصمیم گرفتیم تنها با یک خوشه Kafka توسط خوشه Kubernetes راه بیوفتیم تا مدیریت آن را آسانتر کنیم.

راه اندازی کاربر

Coban یک SDK محبوب Kafka است که به تیم های میکروسرویس های پشتیبانی شده توسط verticals Grab ارائه می دهد ، برای استانداردسازی نحوه استفاده تیم ها از خوشه های Kafka Coban. افزودن پشتیبانی mTLS در حدود آپگرید کردن SDK ما می افتد.

SDK ارتقاء یافته ما یک پیکربندی mTLS پیش فرض را فراهم می کند که برای بیشتر تیم ها به صورت آماده بکار می آید، در عین حال امکان سفارشی سازی را نیز می دهد، به عنوان مثال برای تیم هایی که به دلایل تطابق خاص خود برای Hashicorp Vault زیرساخت دارند. به طور مشابه، مشتریان می توانند از روش های اعتبارسنجی مختلف Vault مانندAWSیاKubernetesبرای تأیید هویت به Hashicorp Vault عمل کنند، یا حتی منطق خود را برای دریافت گواهی معتبر کاربر پیاده سازی کنند.

برای کاهش خطر اشتراک برداشت یا اشتراک بدخواهانه یک گواهی برنامه کاربر با برنامه های دیگر یا کاربران، حداکثر زمان بین شروع و پایان (TTL) یک گواهی مشخص محدود شده است. این همچنین هزینه حفظ لیست لغو گواهی را برداشت می کند. علاوه بر این، SDK ما گواهی و کلید خصوصی مربوطه را تنها در حافظه ذخیره می کند و هرگز بر روی دیسک قرار نمی دهد، بنابراین سطح حمله را کاهش می دهد.

در مورد ما، Vault Hashicorp یک وابستگی است. برای جلوگیری از کاهش در دسترسی بالقوه پلتفرم جریان داده هایمان، دو قابلیت به SDK ما اضافه کرده ایم - یک مکانیسم تکرار تنظیم شده و تجدید خودکار گواهی های کوتاه مدت مشتریان هنگامی که دو سوم مدت زمان باقیمانده TTL آنها رسیده است. SDK ارتقا یافته همچنین معیار های جدیدی را درمورد این فرایند تجدید گواهی تولید می کند، که باعث می شود مانیتورینگ و الارم بهتری فراهم شود.

مجوز دهی

برای مجوز دهی، OPA را به عنوان یک اجرای مستقل در خوشه Kubernetes پیکربندی کرده و Strimzi را برای ادغام بروکرهای Kafka با آن پیکربندی کرده ایم.

سیاست های OPA - نوشته شده به زبان Rego - منطق مجوز را توصیف می کنند. آنها به همراه قوانین مجوزها که منابع داده ای نامیده می شوند در یک مخزن GitLab ایجاد می شوند (مرحله 1). هر بار که یک تغییر رخ دهد، pipeline CI GitLab به طور خودکار یک باندل از سیاست ها و منابع داده را ایجاد می کند و به یک Bucket S3 فشرده می کند (مرحله 2). از آنجا، آن توسط OPA فراخوانی می شود (مرحله 3).

هنگامی که یک مشتری - با شناسایی شده توسط موضوع گواهی TLS خود - سعی در مصرف یا تولید یک رکورد Kafka دارد (مرحله 4)، ابتدا pod بروکر Kafka درخواست مجوز را به OPA صادر می کند (مرحله 5) قبل از پردازش درخواست مشتری توسط بروکر. نتیجه درخواست مجوز سپس توسط pod بروکر Kafka کش می شود تا عملکرد بهتری ارائه شود.

به عنوان اصلی ترین مؤلفه فرآیند مجوز دهی، OPA با همان قابلیت در دسترس بودن بالا Kafka خود، به عنوان مثال در تمامی Availability Zones پخش می شود. همچنین، تصمیم گرفتیم تا با یک OPA اختصاصی توسط هر خوشه Kafka به جای داشتن یک OPA جهانی یکتا راه بیاندازی کنیم که بین چندین خوشه به اشتراک گذاشته می شود. این برای کاهش انتقال ها