کنترل دسترسی به کوبر (قسمت دوازدهم)

تو قسمت دوازدهم از مسیر بلاگ پست‌های کوبرنتیز، میریم سراغ مفاهیم کنترل دسترسی تا اینکه ببینیم چجوری به کلاستر متصل میشیم و چه فرآیندی طی میشه.

خب یه مروری کنیم پست‌های قبلی رو:

• دواپس چیه و چرا لازمه؟  اینجا در مورد دواپس و ضرورت استفاده از آن صحبت کردم.

• چطور اپلیکیشن مناسب کلاد آماده کنیم؟ و اینجا توضیح دادم که چطور می‌تونیم یه اپلیکیشن مناسب کلاد توسعه بدیم.

• چه عمقی از لینوکس برای دواپس لازمه؟ و اینجا توضیح دادم که کدوم موارد لینوکس برای دواپس الزامی هست که اول سراغ اون موارد بریم.

• خودکارش کن,مشکلاتت حل میشه در اینجا در مورد اتومیشن و اینکه انسیبل چیه و چه کمکی به ما می‌کنه صحبت کردم.

• در مسیر دواپس اینبار اجزای اصلی انسیبل تو این پست اجزای انسیبل رو معرفی کردم و آنها را شرح دادم.

• در مسیر دواپس به داکر رسیدیم (قسمت اول) تو این پست داکر رو شروع کردیم و اونو معرفی کردیم.

• در مسیر دواپس اینبار: پشت داکر چه خبره؟ (قسمت دوم) توی این پست در مورد تکنولوژی هایی که داکر ازشون استفاده میکنه توضیح دادیم.

• تست نوشتن و شروع مسیر CI/CD (قسمت اول) توی این پست انواع تست رو بررسی کردیم و با ابزارهای CI/CD آشنا شدیم و یه مقایسه بین گیت‌لب و جنکینز داشتیم.

• در مسیر CI/CD گیت رو بررسی می‌کنیم (قسمت دوم) توی این پست قبل ورود به گیت‌لب نیاز بود که گیت و ورژن کنترل سیستم ها رو یه بررسی کنیم.

• در مسیر ‌CI/CD شناخت گیت‌لب (قسمت سوم) توی این پست اجزای گیت‌لب رو بررسی کردیم و با کامپوننت‌های مختلفی که داره بیشتر آشنا شدیم.

• در مسیر ‌CI/CD پایپ‌لاین و رانر گیت‌لب (قسمت چهارم) توی این پست پایپ‌لاین و رانر گیت‌لب رو بررسی کردیم.

• در مسیر CI/CD وریبل، گیت‌آپس و جمع‌بندی (قسمت پنجم) توی این پست وریبل‌های گیت‌لب رو بررسی کردیم و یه معرفی کوتاه از گیت‌آپس و آتودواپس کردیم و در انتها یه مقدار تجربه‌های خودم رو در گیت‌لب باهاتون به اشتراک گذاشتم.

• در مسیر Observability، الک (قسمت دوم) توی این پست استک قدرتمند ELK رو بررسی کردیم.

• در مسیر Observability، جمع بندی استک الک (قسمت سوم) توی این پست بقیه کامپوننت‌های استک الک رو بررسی کردیم و fluentd و fluentbit رو مقایسه کردیم و نهایتا یه معرفی هم روی opensearch داشتیم.

• در مسیر Observability، استک پرومتئوس (قسمت چهارم) توی این پست یه معرفی اولیه داشتیم روی استک پرومتئوس.

• در مسیر Observability، استک پرومتئوس (قسمت پنجم) توی این پست یه مقدار کامپوننت های استک پرومتئوس رو بیشتر بررسی کردیم.

• در مسیر Observability، استک ویکتوریا (قسمت ششم) توی این پست استک ویکتوریا رو معرفی کردیم و سعی کردیم با پرومتئوس مقایسه‌اش کنیم.

• در مسیر Observability، می‌می‌ر (قسمت هفتم) توی این پست در مورد ابزار میمیر از ابزارهای گرافانا توضیح دادیم و کاربردش رو بررسی کردیم.

• در مسیر Observability، لوکی (قسمت هشتم) توی این پست در مورد ابزار گرافانا برای مدیریت لاگ یعنی لوکی توضیح دادیم و آخرشم یه معرفی کوتاه رو graylog داشتیم.

• در مسیر Observability، تمپو (قسمت نهم) توی این پست در مورد تریسینگ توضیح دادیم و گرافانا تمپو رو بررسی کردیم و یه معرفی کوتاه روی Jaeger داشتیم

• در مسیر Observability، گرافانا (قسمت دهم) توی این پست در مورد گرافانا و HA کردنش و همچنین یه سری از ابزارهاش مثل alloy , incident, on-call توضیح دادیم.

• آغاز مسیر کوبر (قسمت اول) تو این قدم به معرفی ابزارهای ارکستریشن پرداختیم و مدارک کوبرنتیز رو بررسی کردیم.

• کوبر سینگل ( قسمت دوم ) توی این قدم در مورد kubectl , kubeconfig توضیح دادیم و تعدادی ابزار رو معرفی کردیم که به کمک اونها میتونیم یک کوبرنتیز دمه‌دستی واسه تست‌هامون داشته باشیم.

• کامپوننت‌های کوبر ( قسمت سوم ) توی این پست کامپوننت‌های مختلف کوبرنتیز رو بررسی کردیم و اجزای نودهای مستر و ورکر رو دونه دونه بررسی کردیم و توضیح دادیم.

• پادها و مدیریت اونها در کوبرنتیز (قسمت چهارم) توی این پست در مورد پاد توی کوبرنتیز توضیح دادیم و موارد مربوط به اون رو بررسی کردیم.

• ورک‌لودهای کوبر و مدیریت منابع کوبر (قسمت پنجم) توی این پست در مورد namespaceها توی کوبر توضیح دادیم و انواع ورک‌لود کوبر رو بررسی کردیم.

• اگه لازم شد کوبر خودش گنده میشه‌! ( قسمت ششم ) توی این پست در مورد سه نوع ورک‌لود‌ مرتبط با scaling به صورت خودکار در کوبرنتیز توضیح دادیم.

• نتورک کوبر (قسمت هفتم) توی این قسمت انواع سرویس توی کوبرنتیز رو بررسی کردیم و در مورد مفاهیم اینگرس و نتورک پالیسی توضیح دادیم.

• استورج کوبرنتیز (قسمت هشتم) توی این قسمت در مورد انواع استورج توی کوبرنتیز توضیح دادیم و مفاهیم PV و PVC و Storage Class رو بررسی کردیم.

• پراب، ریکوئست و لیمیت (قسمت نهم) توی این قسمت موارد مربوط به محدود کردن منابع کانتینر توی کوبرنتیز رو بررسی کردیم و در مورد انواع ‌probe ها توی کوبرنتیز توضیح دادیم.

• پاد تو نود (قسمت دهم) توی این قسمت درمورد فرآیند انتقال پاد به نود مناسب مفاهیم پیشرفته‌تری مثل affinity و anti-affinity و taint و toleration رو بررسی کردیم.

• اولویت پاد و امنیت (قسمت یازدهم) توی این قسمت در مورد تعیین اولویت برای پادها و جنبه‌های مختلف امنیت در کوبرنتیز توضیح دادیم.

• کنترل دسترسی به کوبر (قسمت دوازدهم) توی این قسمت در مورد مراحل دسترسی به api کوبرنتیز صحبت کردیم و بعدش مفاهیمی مثل سرویس اکانت رو توضیح دادیم.

• دیزاین کلاستر (قسمت سیزدهم) توی این قسمت در مورد طراحی و دیزاین یک کلاستر و روش‌های مختلفی که داره توضیح دادیم و همچنین تفاوت روش‌های مختلف تقسیم منابع در کلاسترها را بررسی کردیم.

• مالتی تننسی در کوبر (قسمت چهاردهم) توی این قسمت چالش‌های مربوط به داشتن چند مستاجر بر روی کلاستر کوبرنتیز توضیح دادیم.

• هلم (قسمت پانزدهم) توی این قسمت پکیج منیجر معروف کوبرنتیز یعنی Helm رو بررسی کردیم و در موردش ویژگی‌ها و کاربردهاش توضیح دادیم.

• سی آر دی و اُپراتور (قسمت شانزدهم) توی این قسمت در مورد اینکه چطوری یه ریسورس کاستوم شده به کلاستر اضافه کنیم توضیح دادیم و مفهوم اُپراتور رو توی کوبر بررسی کردیم.

• نصب کلاستر با kubeadm (قسمت هفدهم) توی این قسمت قدم به قدم نحوه نصب یک کلاستر کوبرنتیز رو با استفاده از ابزار kubeadm توضیح دادیم.

• نصب کلاستر با kubespray (قسمت هجدهم) توی این قسمت نحوه نصب کلاستر با یه پروژه خیلی خوب به نام کیوب اسپری که یه انسیبل خفن برای ستاپ کلاستر رائه میده رو توضیح دادیم.

• نصب کلاستر با rancher (قسمت نوزدهم) توی این قسمت توضیح دادیم که چطور با استفاده از ابزار RKE یک کلاستر کوبرنتیز راه‌اندازی کنیم.

توصیه می‌کنم که حتما این پست‌ها رو هم مطالعه کنید. بریم که ادامه بدیم.

کنترل دسترسی به API کوبرنتیز

کنترل دسترسی به API کوبرنتیز از اهمیت ویژه‌ای برخوردار است، چرا که تضمین می‌کند تنها کاربران و برنامه‌های مجاز به منابع حساس دسترسی پیدا کنند. این فرآیند شامل مراحل احراز هویت، مجوزدهی، کنترل پذیرش و ممیزی است. در ادامه، هر مرحله با جزئیات بیشتر و به زبان ساده توضیح داده شده است.

همانطور که در تصویر بالا میبینید کاربر برای دسترسی گرفتن به api کوبرنتیز از سه مرحله احراز هویت، مجوزدهی و کنترل پذیرش عبور می‌کند که در ادامه هر مورد را توضیح میدهیم.

احراز هویت (Authentication)

احراز هویت اولین مرحله از فرآیند کنترل دسترسی است که هدف آن شناسایی کاربر یا برنامه‌ای است که درخواست ارسال کرده است. پس از برقراری ارتباط امن TLS، درخواست HTTP به این مرحله وارد می‌شود.

ادمین کلاستر یا اسکریپت ساخت کلاستر تنظیمات لازم را برای اجرای یک یا چند ماژول احراز هویت در api-server اعمال می‌کند. ورودی این مرحله، کل درخواست HTTP است، اما معمولاً فقط بخش‌هایی مثل هدرها یا گواهی‌نامه کلاینت بررسی می‌شوند.

ماژول‌های احراز هویت شامل موارد زیر هستند:

- گواهی‌نامه‌های کلاینت (Client Certificates): این گواهی‌ها برای شناسایی امن کلاینت‌ها استفاده می‌شوند.

- رمز عبور و توکن‌های ساده: برای دسترسی سریع به منابع کاربرد دارند.

- توکن‌های بوت‌استرپ: برای ارتباطات اولیه در کلاستر استفاده می‌شوند.

- توکن‌های وب (JWT): این توکن‌ها معمولاً برای حساب‌های کاربری سرویس‌ها به کار می‌روند.

در صورت پیکربندی چند ماژول احراز هویت، هر ماژول به ترتیب بررسی می‌شود تا یکی از آنها موفق به احراز هویت شود. اگر هیچ ماژولی نتواند درخواست را تایید کند، درخواست با کد وضعیت HTTP 401 رد می‌شود. به زبان ساده، اگر سیستم نتواند کاربر را شناسایی کند، به او اجازه ادامه کار نمی‌دهد. همان‌طور که بالاتر گفتم می‌تونیم چندین ماژول برای احراز هویت کاربر به صورت همزمان داشته باشیم. هم می‌تونیم وصلش کنیم به SSO خودمون هم با کلاینت سرتیفیکیت و توکن به افرادی دسترسی بدیم. کوبرنتیز یا بهتر بگیم api-server هم‌زمان همه‌ی آنها رو بررسی می‌کنه و اگر با یکی تونست تایید کنه به کاربر اجازه می‌ده که لاگین کنه.

مجوزدهی (Authorization)

بعد از احراز هویت، نوبت به مجوزدهی می‌رسد. در این مرحله، بررسی می‌شود که آیا کاربر مجاز به انجام عملی است که درخواست داده است یا خیر. درخواست باید شامل اطلاعات زیر باشد:

- نام کاربری: کاربری که درخواست را ارسال کرده است.

- عملیات: کاری که کاربر قصد انجام آن را دارد (مثلاً ایجاد یا حذف یک پاد).

- منبع: آبجکت یا منبعی که قرار است عملیات روی آن انجام شود.

مجوزدهی در کوبرنتیز از طریق چندین ماژول انجام می‌شود که شامل موارد زیر هستند:

- (مجوزدهی نود) Node Authorization: این روش برای مجوزدهی درخواست‌های ارسال شده توسط kubelet‌ها طراحی شده و به کاربران معمولی مربوط نمی‌شود.

- (کنترل دسترسی مبتنی بر ویژگی) ABAC : در این روش، سیاست‌ها بر اساس ویژگی‌های کاربر یا درخواست تعریف می‌شوند. این روش قدیمی شده و به جای آن از RBAC استفاده می‌شه که در ادامه توضیح می‌دیم.

- (کنترل دسترسی مبتنی بر نقش) RBAC : دسترسی‌ها بر اساس نقش‌هایی که به کاربران اختصاص داده شده است مدیریت می‌شوند. روش خیلی مرسوم و متداولی که سرویس‌های دیگه هم ازش استفاده می‌کنند. ما دسترسی‌ها رو به roleها می‌دیم و role ها رو به کاربرها و آدم‌ها متصل می‌کنیم. نقش اصلی کنترل دسترسی تو کوبرنتیز بر عهده‌ی RBAC هست و معمولا همه از آن استفاده می‌کنند.

- روش Webhook: در این روش، درخواست‌ها به یک سرویس خارجی ارسال می‌شوند تا تایید شوند.

- (همیشه مجاز) AlwaysAllow: تمامی درخواست‌ها را بدون بررسی تایید می‌کند (برای محیط‌های توسعه مناسب است). البته که همون محیط توسعه هم باید با دسترسی منطقی و درستی کار بکنه تا بتونه روی پروداکشن به خوبی استقرار پیدا کنه. کلا چیز خوبی نیست که همه چیز رو allow کنیم. بهتره با محیط تست و تمرین کنیم که قراره بعدا باهاش مواجه بشیم.

- (همیشه رد)AlwaysDeny: تمامی درخواست‌ها را بدون بررسی رد می‌کند (برای محیط‌های بسیار امن مناسب است). اینم بگم که کاربردی نیست اونقدر بالاخره نیاز داریم که یکی یا چیزی با سیستم و سرویس‌ کار کنه. برای همین نه به اون بی نمکی قبلی و نه به این شوری این.

کی تصمیم می‌گیره؟

مدیر کلاستر مشخص می‌کند که کدام یک از این ماژول‌ها فعال باشند. اگر چند ماژول مجوزدهی فعال باشد، کوبرنتیز درخواست را به ترتیب به هر ماژول ارسال می‌کند. اگر یکی از ماژول‌ها درخواست را تایید کند، عملیات مجاز خواهد بود. در غیر این صورت، درخواست با کد وضعیت HTTP 403 رد می‌شود. دقت کنید یکی از اون چند تا اگر اوکی باشه اکسپت می‌کنه و درخواست رو اعمال می‌کنه. ممکنه موقعیتی پیش بیاد که یه درخواست با یکی از این ابزارها و سیستم‌ها اوکی باشه و با یکی دیگه نه ولی چون اجتماع آنها هست با هر کدوم که اوکی بشه روال می‌کنه و کوبرنتیز درخواست رو اوکی می‌کنه. این موضوع هم تو احراض هویت و هم تو اعمال دسترسی برقرار هست.

پیکربندی حالت‌های مجوزدهی

برای پیکربندی حالت‌های مجوزدهی در کوبرنتیز، فایل تنظیمات kube-apiserver.yaml را ویرایش کنید که معمولاً در مسیر /etc/kubernetes/manifests/ قرار دارد. در این فایل، حالت‌های مجوزدهی مورد نظر خود را به پرچم --authorization-mode اضافه کنید و حالت‌ها را با کاما جدا کنید.

مثال:

--authorization-mode=RBAC,Webhook

پس از اعمال تغییرات، سرور API را ری‌استارت کنید تا تغییرات اعمال شوند.

استفاده از چندین حالت مجوزدهی

کوبرنتیز این امکان را فراهم می‌کند که چندین حالت مجوزدهی به صورت همزمان فعال شوند. در این حالت، هر درخواست به ترتیب توسط تمامی حالت‌ها بررسی می‌شود تا یکی از آنها درخواست را تایید یا رد کند. اگر تمامی حالت‌ها درخواست را رد کنند، دسترسی داده نمی‌شود.

کنترل پذیرش (Admission Control)

کنترل پذیرش مرحله‌ای است که پس از مجوزدهی اجرا می‌شود. در این مرحله، درخواست‌ها ممکن است تغییر داده شوند یا رد شوند. ماژول‌های کنترل پذیرش به درخواست‌هایی که برای ایجاد، تغییر، حذف، یا اتصال به یک آبجکت هستند، پاسخ می‌دهند. اما به درخواست‌هایی که صرفاً برای خواندن اطلاعات هستند، توجهی نمی‌کنند.

کنترل‌کننده‌های پذیرش به دو دسته تقسیم می‌شوند:

- کنترل‌کننده‌های تغییر‌دهنده (Mutating Admission Controllers): این کنترل‌کننده‌ها درخواست‌ها را قبل از پردازش تغییر می‌دهند. به عنوان مثال، کنترل‌کننده ServiceAccount به صورت خودکار یک حساب کاربری سرویس پیش‌فرض به پاد اضافه می‌کند. با mutations ما می‌تونیم درخواست رو تغییر بدیم. مثلا اینکه دیفالت سرویس اکانت رو به پادها اضافه کنیم.

- کنترل‌کننده‌های اعتبارسنجی (Validating Admission Controllers): این کنترل‌کننده‌ها درخواست‌ها را بررسی می‌کنند تا اطمینان حاصل شود که با قوانین تعیین شده مطابقت دارند.

ممیزی (Auditing)

ممیزی در کوبرنتیز ابزاری است که یک مجموعه زمانی از رویدادهای امنیتی را ثبت می‌کند. این رویدادها شامل فعالیت‌های کاربران، برنامه‌ها، و خود سیستم کنترل مرکزی می‌شوند. رکوردهای ممیزی اطلاعات مهمی مانند زمان، مکان، و نوع عملیات را مستند می‌کنند. به عبارت دیگه تمام عملکردی که داخل کوبرنتیز در جریان است رو می‌تونیم با استفاده از Audit لاگ کنیم و به زبان ساده Audit log کوبرنتیز رو داشته باشیم و درست کانفیگ کرده باشیم می‌تونیم تمام اتفاقاتی که تو کلاستر افتاده رو با جزئیات کامل بدونیم. برای همین خیلی نقش کلیدی و مهمی برای بررسی رخدادهای داخل کلاستر کوبرنتیز داره.

به طور کلی، ممیزی به سوالات زیر پاسخ می‌دهد:

• چه اتفاقی افتاد؟

• چه زمانی اتفاق افتاد؟

• چه کسی آن را آغاز کرد؟

• بر روی چه چیزی انجام شد؟

• از کجا مشاهده شد؟

• از کجا آغاز شد؟

• به کجا رفت؟

سطوح ممیزی

کوبرنتیز چندین سطح برای ثبت رویدادها ارائه می‌دهد:

• سطح None: هیچ رویدادی ثبت نمی‌شود.

• سطح Metadata: فقط متادیتای درخواست (مانند کاربر درخواست‌کننده، زمان، منبع، و فعل) ثبت می‌شود.

• سطح Request: متادیتای رویداد به همراه بدنه درخواست ثبت می‌شود.

• سطح RequestResponse: متادیتای رویداد، بدنه درخواست، و بدنه پاسخ ثبت می‌شوند.

هر کدوم از این سطوح رو می‌تونیم بر اساس فعلی (Create,Delete,Get,...) که انجام می‌شه و کسی که انجام می‌ده داخل آدیت لاگ داشته باشیم. به این نکته توجه کنید که تو کلاسترهای بزرگ حجم این لاگ خیلی می‌تونه زیاد بشه و اگر درست کانفیگ نشه حتی می‌تونه که api-serverها رو با مشکل مواجه کنه. برای همین باید دقیق بدونیم که برای کجا می‌خواهیم اون رو فعال کنیم و سطح آن رو هم کامل مشخص کنیم. مثلا افعال get,watch,list عموما زیاد مهم نیست که بدونیم کی انجام داده. در اکثر اوقات می‌تونی این افعال رو none بزاریم تا بتونیم حجم لاگ و میزان اون رو منطقی کاهش بدیم.

کنترل دسترسی به API کوبرنتیز یک فرآیند چندمرحله‌ای است که امنیت و مدیریت دسترسی را تضمین می‌کند. با استفاده از احراز هویت، مجوزدهی، کنترل پذیرش، و ممیزی، می‌توان دسترسی به منابع کلاستر را به طور دقیق مدیریت کرد. این مراحل به مدیران امکان می‌دهند تا با اطمینان بیشتری منابع حساس را محافظت کنند و دسترسی‌ها را بر اساس نیازهای خاص تنظیم کنند.

کنترل دسترسی مبتنی بر نقش (RBAC) در کوبرنتیز

کنترل دسترسی مبتنی بر نقش یا RBAC (Role-Based Access Control) یکی از کلیدی‌ترین ابزارهای امنیتی در کوبرنتیز است که اطمینان می‌دهد کاربران و ورک‌لودها فقط به منابعی دسترسی داشته باشند که برای اجرای وظایفشان نیاز دارند. این مکانیزم به مدیریت دقیق سطوح دسترسی کمک می‌کند و از دادن مجوزهای غیرضروری به کاربران جلوگیری می‌نماید.

معرفی آبجکت‌های RBAC

در RBAC چهار نوع آبجکت اصلی تعریف می‌شود:

1. Role

2. ClusterRole

3. RoleBinding

4. ClusterRoleBinding

این آبجکت‌ها را می‌توان مانند سایر منابع کوبرنتیز با ابزارهایی مانند kubectl مشاهده و ویرایش کرد.

آبجکت‌های Role و ClusterRole به عنوان مجموعه‌ای از قوانین دسترسی تعریف می‌شوند که اجازه‌ی دسترسی به منابع خاص را مشخص می‌کنند. توجه داشته باشید که مجوزهای RBAC فقط افزایشی هستند؛ یعنی امکان تعریف قانون «رد کردن دسترسی» وجود ندارد. این نکته‌‌ی خیلی مهمی است که باید بهش دقت کنیم. به زبان ساده با role و clusterrole ما داریم می‌گیم چه ریسورسی (مثلا پاد یا سرویس یا هرچی ) چه فعلی (مثلا ساختن یا پاک کردن یا ادیت کردن یا هر چی) رو داشته باشیم. اینجا فقط این دو تا رو داریم مشخص می‌کنیم.

Role:

یک Role همیشه مجوزهای دسترسی را فقط در فضای نام (Namespace) مشخص‌شده تنظیم می‌کند. به همین دلیل هنگام ایجاد Role باید حتماً فضای نام مربوط به آن را مشخص کنید.

مثال ایجاد یک Role در نیم‌اسپیس dev:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

در مثال فوق، Role مجوز مشاهده و لیست‌کردن Podها را در فضای نام dev فراهم می‌کند.

Cluster Role:

آبجکت ClusterRole برخلاف Role، به صورت غیرمربوط به فضای نام (Cluster-wide) تعریف می‌شود و می‌تواند دسترسی به منابع در کل کلاستر را کنترل کند.

مثال تعریف یک ClusterRole:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: node-reader
rules:
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get", "list", "watch"]

در اینجا، ClusterRole مجوز مشاهده و لیست کردن Nodeها را در سطح کل خوشه فراهم می‌کند.

RoleBinding:

آبجکت RoleBinding یک Role را به یک یا چند موضوع (Subjects) مانند کاربرها، گروه‌ها یا حساب‌های کاربری سرویس (ServiceAccounts) متصل می‌کند. ما تو رول تعریف کردیم چه ریسورسی رو چی کار بتونیم بکنیم و با رول بایندینگ اون رو به یه کاربر یا گروه یا سرویس‌ اکانت متصل می‌کنیم.

آبجکت RoleBinding مجوزهای مربوط به Role را در فضای نام مشخصی به موضوعات (subject) می‌دهد. همچنین می‌تواند به ClusterRole اشاره کند و مجوزهای مربوط به ClusterRole را به یک فضای نام خاص محدود کند.

نمونه RoleBinding:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods-binding
  namespace: dev
subjects:
- kind: User
  name: mamad
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

در مثال فوق، کاربر mamad می‌تواند Podها را در فضای نام dev بخواند.

ClusterRoleBinding

آبجکت ClusterRoleBinding دقیقاً مانند RoleBinding عمل می‌کند، اما مجوزهای ClusterRole را در کل کلاستر (Cluster-wide) به موضوعات مشخص‌شده اعطا می‌کند.

مثال:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: node-reader-binding
subjects:
- kind: User
  name: admin
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: node-reader
  apiGroup: rbac.authorization.k8s.io

در این مثال، کاربر admin مجوز مشاهده Nodeها در کل کلاستر را دریافت می‌کند.

پس عملا اینجا ما با دو تا موضوع مواجه هستیم یکی در سطح یک namespace و یکی در سطح کل کلاستر که هر دو عملکرد یکسان هست ولی حوزه‌ی فعالیتشون باهم متفاوت است.

ServiceAccount

یک سرویس اکانت هویتی برای فرآیندهایی که در Podها اجرا می‌شوند فراهم می‌کند.

زمانی که به API Server کوبرنتیز احراز هویت می‌کنید، خود را به عنوان یک کاربر مشخص معرفی می‌کنید. با این حال، کوبرنتیز خودش دارای یک User API نیست و هویت کاربران معمولاً در یک سیستم خارجی مدیریت می‌شود.

مثال تعریف ServiceAccount:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-service-account
  namespace: dev

سپس می‌توانید این ServiceAccount را به یک Pod اختصاص دهید:

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
  namespace: dev
spec:
  serviceAccountName: my-service-account
  containers:
  - name: my-container
    image: my-image

در اینجا، Pod با استفاده از my-service-account احراز هویت خواهد شد.

کنترل دسترسی مبتنی بر نقش (RBAC) در کوبرنتیز یکی از مهم‌ترین ابزارهای مدیریت امنیتی است که به شما اجازه می‌دهد دسترسی‌های دقیقی برای کاربران و فرآیندهای مختلف تعریف کنید. با استفاده از Role، ClusterRole، RoleBinding و ClusterRoleBinding می‌توان سطوح دسترسی مناسب در نیم‌اسپیس یا در کل کلاستر ایجاد کرد.

با طراحی مناسب RBAC می‌توانید به امنیت و کارایی بیشتر در مدیریت منابع کوبرنتیز دست پیدا کنید.

در بلاگ پست‌های بعدی مسیرمون رو ادامه میدیم و بیشتر و بیشتر در مورد کوبرنتیز یاد می‌گیریم.

مراقب خودتون باشید. 🌹🐳🌹

خوبه که داکرمی رو تو جاهای مختلف فالو کنید. پذیرای نظرات شما هستیم.

🫀 Follow DockerMe 🫀

🔔 Follow YouTube 🔔

📣 Follow Instagram 📣

🖇 Follow LinkedIn DockerMe🖇

🔎 Follow Linkedin Ahmad Rafiee 🔎

🕊 Follow Twitter 🕊