تو قسمت دوازدهم از مسیر بلاگ پستهای کوبرنتیز، میریم سراغ مفاهیم کنترل دسترسی تا اینکه ببینیم چجوری به کلاستر متصل میشیم و چه فرآیندی طی میشه.
خب یه مروری کنیم پستهای قبلی رو:
- دواپس چیه و چرا لازمه؟ اینجا در مورد دواپس و ضرورت استفاده از آن صحبت کردم.
- مسیر شغلی دواپس اینجا در مورد مسیر شغلی دواپس و موارد پیرامون آن صحبت کردم.
- چطور اپلیکیشن مناسب کلاد آماده کنیم؟ و اینجا توضیح دادم که چطور میتونیم یه اپلیکیشن مناسب کلاد توسعه بدیم.
- چه عمقی از لینوکس برای دواپس لازمه؟ و اینجا توضیح دادم که کدوم موارد لینوکس برای دواپس الزامی هست که اول سراغ اون موارد بریم.
- خودکارش کن، مشکلاتت حل میشه 🙂 در اینجا در مورد اتومیشن و اینکه انسیبل چیه و چه کمکی به ما میکنه صحبت کردم.
- در مسیر دواپس اینبار اجزای اصلی انسیبل تو این پست اجزای انسیبل رو معرفی کردم و آنها را شرح دادم.
- در مسیر دواپس به داکر رسیدم. (قسمت اول) تو این پست داکر رو شروع کردیم و اونو معرفی کردیم.
- در مسیر دواپس اینبار: پشت داکر چه خبره؟ (قسمت دوم) توی این پست در مورد تکنولوژی هایی که داکر ازشون استفاده میکنه توضیح دادیم.
- در مسیر دواپس اینبار: والیوم و نتورک داکر (قسمت سوم) توی این پست در مورد شبکه توی داکر و اینکه چطوری دیتای کانتینر رو میتونیم نگه داریم توضیح دادیم.
- در مسیر دواپس اینبار: داکر فایل ( قسمت چهارم ) توی این پست در مورد اینکه چطور با استفاده از داکر اپلیکیشن مون رو بیلد کنیم و ایمیج بسازیم توضیح دادیم.
- در مسیر دواپس اینبار: کامپوز فایل و داکر کامپوز (قسمت پنجم) توی این پست در مورد اینکه چطور روند دیپلوی کردن سرویسهامون و کانفیگ اونها رو به صورت کد داشته باشیم توضیح دادیم.
- در مسیر دواپس: اینبار داکر سوآرم (قسمت ششم) توی این پست در مورد داکر سوآرم و اینکه چطوری به کمک داکر چنتا سرور رو کلاستر کنیم، توضیح دادیم.
- در مسیر دواپس اینبار: دور و بری های داکر (قسمت هفتم) توی این پست در مورد ابزارهای جانبی که بهمون توی کار با داکر کمک میکنن توضیح دادیم.
- در مسیر دواپس: جمع بندی داکر (قسمت هشتم) توی این پست در مورد امنیت داکر توضیح دادیم و در آخر هم یه سری از بست پرکتیسها و تجربیات خودم رو گفتم.
- تست نوشتن و شروع مسیر CI/CD (قسمت اول) توی این پست انواع تست رو بررسی کردیم و با ابزارهای CI/CD آشنا شدیم و یه مقایسه بین گیتلب و جنکینز داشتیم.
- در مسیر CI/CD گیت رو بررسی میکنیم (قسمت دوم) توی این پست قبل ورود به گیتلب نیاز بود که گیت و ورژن کنترل سیستم ها رو یه بررسی کنیم.
- در مسیر CI/CD شناخت گیتلب (قسمت سوم) توی این پست اجزای گیتلب رو بررسی کردیم و با کامپوننتهای مختلفی که داره بیشتر آشنا شدیم.
- در مسیر CI/CD پایپلاین و رانر گیتلب (قسمت چهارم) توی این پست پایپلاین و رانر گیتلب رو بررسی کردیم.
- در مسیر CI/CD وریبل، گیتآپس و جمعبندی (قسمت پنجم) توی این پست وریبلهای گیتلب رو بررسی کردیم و یه معرفی کوتاه از گیتآپس و آتودواپس کردیم و در انتها یه مقدار تجربههای خودم رو در گیتلب باهاتون به اشتراک گذاشتم.
- مسیر Observability (قسمت اول) توی این پست معرفی observability رو داشتیم و مقایسه اش با مانیتورینگ و یه توضیح مختصر هم در مورد اپنتلهمتری دادیم.
- در مسیر 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 کوبرنتیز
کنترل دسترسی به 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 چهار نوع آبجکت اصلی تعریف میشود:
- Role
- ClusterRole
- RoleBinding
- 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 میتوانید به امنیت و کارایی بیشتر در مدیریت منابع کوبرنتیز دست پیدا کنید.
در بلاگ پستهای بعدی مسیرمون رو ادامه میدیم و بیشتر و بیشتر در مورد کوبرنتیز یاد میگیریم.
مراقب خودتون باشید. 🌹🐳🌹