RBAC در کوبرنتیز یکی از اصلیترین مکانیزمهای کنترل دسترسی در کوبرنتیز است که تعیین میکند هر کاربر، سرویس یا برنامه چه عملیاتی را روی منابع کلاستر میتواند انجام دهد. این سیستم با تکیه بر نقشها (Role و ClusterRole) و اتصال آنها به هویتها (RoleBinding و ClusterRoleBinding)، لایه Authorization در API Server را مدیریت میکند و نقش کلیدی در پیادهسازی اصل حداقل سطح دسترسی دارد. در این مقاله، ساختار، نحوه عملکرد، اجزای اصلی، مثال عملی پیادهسازی و محدودیتهای RBAC کوبرنتیز را بهصورت دقیق بررسی میکنیم.
RBAC در کوبرنتیز چیست؟
RBAC مخفف Role-Based Access Control یا «کنترل دسترسی مبتنی بر نقش» است. این مکانیزم امنیتی در کوبرنتیز مشخص میکند که هر کاربر، سرویس یا برنامه چه عملیاتی را روی کدام منابع کلاستر میتواند انجام دهد.
در کوبرنتیز، تمام درخواستها از طریق API Server پردازش میشوند و سیستم RBAC کوبرنتیز وظیفه دارد سطح دسترسی این درخواستها را کنترل کند. بهکمک این مکانیزم میتوان تعیین کرد که یک هویت مشخص چه منابعی را مشاهده کند، چه عملیاتی انجام دهد و این دسترسی در کدام Namespace یا در سطح کل کلاستر معتبر باشد. برای مثال، با استفاده از RBAC در کوبرنتیز میتوان به یک توسعهدهنده فقط اجازه مشاهده Podها در Namespace توسعه (Dev) را داد؛ بدون اینکه به منابع محیط Production دسترسی داشته باشد.
سیستم RBAC کوبرنتیز فقط برای کاربران انسانی استفاده نمیشود و برنامهها و Podهای داخل کلاستر نیز از طریق Service Accountها با همین مکانیزم احراز دسترسی میشوند.
بهطور کلی، RBAC استانداردترین روش مدیریت دسترسی کاربران در کوبرنتیز است و نقش مهمی در پیادهسازی اصل Least Privilege یا «حداقل سطح دسترسی» دارد.
تفاوت Authentication و Authorization در Kubernetes
برای درک جایگاه RBAC در کوبرنتیز، ابتدا باید تفاوت Authentication (احراز هویت) و Authorization (تعیین سطح دسترسی) را بدانید. هر درخواستی که به API Server کلاستر ارسال میشود، ابتدا هویت فرستنده را بررسی میکند و سپس سطح دسترسی او را میسنجد.
مرحله اول، Authentication: کوبرنتیز مشخص میکند درخواست از طرف چه کاربری، سرویس یا برنامهای ارسال شده است. این فرایند معمولاً با استفاده از توکنها، Client Certificateها یا سرویسهای هویت خارجی انجام میشود. اگر هویت فرستنده تأیید نشود، درخواست با خطای HTTP 401 Unauthorized رد خواهد شد.
مرحله دوم، Authorization: پس از تأیید هویت، مرحله Authorization یا آغاز میشود. در این مرحله، کوبرنتیز بررسی میکند که آیا این هویت، اجازه انجام عملیات موردنظر را دارد یا خیر. اینجاست که RBAC کوبرنتیز وارد عمل میشود و بر اساس Roleها و Bindingهای تعریفشده، مجوز دسترسی را صادر یا رد میکند. در صورت نداشتن مجوز کافی، درخواست با خطای HTTP 403 Forbidden مواجه میشود.
برای درک بهتر تفاوت این دو لایه امنیتی، جدول زیر را ببینید:
| ویژگی | Authentication (احراز هویت) | Authorization (تعیین سطح دسترسی) |
| سؤال اصلی | شما چه کسی هستید؟ (تشخیص هویت) | مجاز به انجام دادن چه کاری هستید؟ (بررسی مجوز) |
| زمان اجرا | مرحله ۱: قبل از بررسی دسترسیها | مرحله ۲: پس از تأیید هویت |
| وظیفه اصلی | شناسایی هویت کاربر یا سرویس | بررسی مجوز عملیات |
| کد وضعیت HTTP در صورت شکست | 401 Unauthorized | 403 Forbidden |
| ورودیهای سیستم | هدرهای HTTP، گواهی کلاینت، توکنها | نام کاربر، نوع عملیات (Action)، منبع مورد نظر (Object) |
| خروجی فرایند | استخراج نام کاربری (Username) یا شناسه گروه | صدور اجازه دسترسی (Allow) یا رد آن (Deny) |
اجزای اصلی RBAC در کوبرنتیز
سیستم RBAC در کوبرنتیز از چند جزء اصلی تشکیل شده است که در کنار هم مشخص میکنند چه هویتی چه عملیاتی را روی کدام منابع میتواند انجام دهد. این اجزا عبارتاند از:
Role
Role مجموعهای از مجوزهاست که دسترسی به منابع را در یک Namespace در کوبرنتیز تعریف میکند. با استفاده از Role میتوان مشخص کرد که یک کاربر یا Service Account چه عملیاتی را روی منابع کوبرنتیز انجام دهد.
ClusterRole
ClusterRole نیز مجموعهای از مجوزها را تعریف میکند، اما در سطح کل کلاستر قابل استفاده است و محدود به یک Namespace مشخص نیست.
RoleBinding
RoleBinding یک Role را به یک کاربر، گروه یا Service Account متصل میکند. این اتصال فقط در همان Namespace معتبر است و مشخص میکند چه هویتی از مجوزهای تعریفشده در Role استفاده کند.
ClusterRoleBinding
ClusterRoleBinding یک ClusterRole را در سطح کل کلاستر به کاربران، گروهها یا Service Accountها متصل میکند. این نوع Binding معمولاً برای دسترسیهای سراسری استفاده میشود.
Subjects
Subjects همان هویتهایی هستند که مجوزها به آنها اختصاص داده میشود. این هویتها میتوانند کاربران، گروهها یا Service Accountهای داخل کلاستر باشند.
در تنظیمات RBAC کوبرنتیز، هر Role یا ClusterRole معمولاً شامل فیلدهایی برای تعیین منابع و نوع دسترسی است. برای مثال، فیلد verbs مشخص میکند یک هویت چه عملیاتی مانند get ،list ،create یا delete را میتواند انجام دهد.
همچنین فیلد apiGroups برای تعیین گروه API مربوط به هر منبع استفاده میشود. در منابع اصلی کوبرنتیز مانند Pod و Service معمولاً مقدار آن بهصورت رشته خالی "" نوشته میشود، اما برای منابعی مانند Deployment در کوبرنتیز از گروههایی مانند apps استفاده میشود.
تفاوت Role و ClusterRole؛ مرز میان Namespace و کلاستر
اصلیترین تفاوت Role و ClusterRole در Kubernetes، محدوده دسترسی یا Scope آنهاست. Role فقط در یک Namespace مشخص معتبر است و مجوزهای تعریفشده در آن خارج از همان Namespace اعمال نمیشوند. برای مثال، اگر کاربری در Namespace مربوط به محیط توسعه (dev) اجازه مشاهده پادها را داشته باشد، این دسترسی در Namespace محیط Production معتبر نخواهد بود.
در مقابل، ClusterRole در سطح کل کلاستر عمل میکند و به یک Namespace محدود نیست. این نوع Role معمولاً برای منابعی استفاده میشود که وابسته به Namespace نیستند؛ مانند نودها یا PersistentVolumeها. همچنین میتوان از ClusterRole برای تعریف دسترسیهای یکسان در چند Namespace مختلف استفاده کرد.
در عمل، Role و RoleBinding بیشتر برای مدیریت دسترسیهای محدود در یک Namespace استفاده میشوند، درحالیکه ClusterRole و ClusterRoleBinding برای دسترسیهای سراسری در سطح کلاستر کاربرد دارند.
نحوه عملکرد RBAC در Kubernetes
سیستم RBAC در کوبرنتیز برای بررسی دسترسیها، هر درخواست را بهصورت مرحلهبهمرحله ارزیابی میکند. زمانی که یک کاربر، Service Account یا برنامه درخواستی را به API Server ارسال میکند، کوبرنتیز مراحل زیر را برای تصمیمگیری طی میکند:
گام ۱: شناسایی هویت درخواستکننده
در ابتدا کوبرنتیز مشخص میکند درخواست از طرف چه هویتی ارسال شده است. این هویت میتواند یک کاربر، گروه یا Service Account باشد.
گام ۲: بررسی Roleها و ClusterRoleها
پس از شناسایی هویت، کوبرنتیز Roleها و ClusterRoleهای تعریفشده را بررسی میکند تا مشخص شود چه مجوزهایی برای آن هویت وجود دارد.
گام ۳: بررسی Bindingها
در ادامه، کوبرنتیز بررسی میکند که آیا Role یا ClusterRole موردنظر از طریق RoleBinding یا ClusterRoleBinding به آن کاربر یا Service Account متصل شده است یا خیر.
گام ۴: تطبیق درخواست با مجوزها
در این مرحله، کوبرنتیز نوع عملیات درخواستی (مانند get ،list یا delete) و منبع هدف (مانند Pod یا Service) را با قوانین تعریفشده در RBAC تطبیق میدهد.
گام ۵: صدور نتیجه نهایی
اگر مجوز لازم وجود داشته باشد، درخواست تأیید میشود و کاربر به منبع موردنظر دسترسی پیدا میکند. در غیر این صورت، کوبرنتیز درخواست را با خطای 403 Forbidden رد میکند.
آموزش عملی پیادهسازی RBAC در کوبرنتیز (به همراه کد)
در این مثال، یک Service Account ایجاد میکنیم که فقط اجازه مشاهده Serviceها و ConfigMapها را در یک Namespace مشخص داشته باشد.
گام ۱: ایجاد Namespace و Service Account
ابتدا یک Namespace و سپس یک Service Account اختصاصی ایجاد میکنیم:
kubectl create namespace random-numbers
kubectl create sa random-numbers-sa -n random-numbersگام ۲: تعریف Role
در این مرحله، یک Role در فایلی به نام فایل به نام role.yaml میسازیم که فقط دسترسی get و list را روی Serviceها و ConfigMapها داشته باشد.
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: random-numbers
name: client-access-role
rules:
- apiGroups: [""]
resources:
- configmaps
- services
verbs:
- get
- listبرای اعمال این Role روی کلاستر، دستور زیر را اجرا کنید:
kubectl apply -f role.yamlگام ۳: ایجاد RoleBinding
اکنون باید Role تعریفشده را به Service Account متصل کنیم. فایل yaml زیر با نام rolebinding.yaml را ایجاد کنید:
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: client-access-role-binding
namespace: random-numbers
subjects:
- kind: ServiceAccount
name: random-numbers-sa
namespace: random-numbers
roleRef:
kind: Role
name: client-access-role
apiGroup: rbac.authorization.k8s.ioبرای اعمال RoleBinding دستور زیر را اجرا کنید:
kubectl apply -f rolebinding.yamlگام ۴: راهاندازی پاد تست با سرویساکانت اختصاصی
در ادامه یک پاد میسازیم تا بتوانیم درخواستهای امنیتی را از داخل کلاستر تست کنیم. برای انجام این کار فایلی به نام pod-test.yaml بسازید و کد زیر را در آن قرار دهید:
apiVersion: v1
kind: Pod
metadata:
name: curlo
namespace: random-numbers
spec:
serviceAccountName: random-numbers-sa
containers:
- name: curlo
image: curlimages/curl
command: ["sleep","999999"]پاد را اجرا کنید:
kubectl apply -f pod-test.yamlگام ۵: بررسی سطح دسترسی
ابتدا وارد Pod شوید:
kubectl exec -it curlo -n random-numbers -- /bin/shسپس توکن Service Account را برای ارسال درخواست به API Server تنظیم کنید:
export TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
export CURL_CA_BUNDLE=/var/run/secrets/kubernetes.io/serviceaccount/ca.crtآزمایش اول: بررسی دسترسی مجاز (مشاهده سرویسها)
یک درخواست به آدرس API سرویسهای این Namespace میفرستیم:
curl -k --header "Authorization: Bearer $TOKEN" \
https://kubernetes.default.svc/api/v1/namespaces/random-numbers/servicesدر صورت موفقیت، Kubernetes اطلاعات Serviceها را با پاسخ 200 OK برمیگرداند.
آزمایش دوم: بررسی دسترسی غیرمجاز
اکنون درخواست مشاهده Podها را ارسال میکنیم:
curl -k --header "Authorization: Bearer $TOKEN" \
https://kubernetes.default.svc/api/v1/namespaces/random-numbers/podsچون در Role تعریفشده مجوز دسترسی به Podها وجود ندارد، Kubernetes پاسخ 403 Forbidden را برمیگرداند:
{
"status": "Failure",
"message": "pods is forbidden: User \"system:serviceaccount:random-numbers:random-numbers-sa\" cannot list resource \"pods\" in the namespace \"random-numbers\"",
"reason": "Forbidden",
"code": 403
}بهترین روشها (Best Practices) برای پیادهسازی RBAC
پیادهسازی صحیح RBAC در کوبرنتیز نقش مهمی در کاهش ریسکهای امنیتی و کنترل دسترسی کاربران دارد. مهمترین راهکارهای این حوزه عبارتاند از:
اصل حداقل دسترسی (Least Privilege)
دسترسیها باید فقط بر اساس نیاز واقعی کاربران و سرویسها تعریف شوند. بهتر است از اعطای مجوزهای گسترده یا استفاده از وایلدکارد * در بخش منابع و عملیاتها خودداری شود.
استفاده از Role و RoleBinding در سطح Namespace
در بیشتر سناریوها، بهتر است دسترسیها در سطح Namespace مدیریت شوند. استفاده از Role و RoleBinding باعث میشود دامنه دسترسی محدود بماند و ایزولهسازی بین محیطهایی مانند dev و prod حفظ شود.
محدود کردن استفاده از ClusterRole و ClusterRoleBinding
ClusterRole و ClusterRoleBinding فقط باید برای دسترسیهای سراسری یا منابع cluster-scoped استفاده شوند. استفاده غیرضروری از آنها میتواند سطح دسترسی کاربران را بیش از حد افزایش دهد.
استفاده از Service Account اختصاصی
بهتر است هر Pod یا برنامه از Service Account اختصاصی خود استفاده کند و به Service Account پیشفرض Namespace وابسته نباشد. این کار باعث میشود دسترسی سرویسها از یکدیگر جدا شود.
همچنین در صورت عدم نیاز، میتوان قابلیت mount خودکار توکن Service Account را با تنظیم automountServiceAccountToken: false غیرفعال کرد.
بازبینی و حسابرسی دورهای
تنظیمات RBAC باید بهصورت دورهای بررسی شوند تا دسترسیهای قدیمی، RoleBindingهای بلااستفاده یا مجوزهای غیرضروری حذف شوند. همچنین دسترسیهای حساس، بهویژه اعضای گروه system:masters، باید بهصورت مستمر کنترل شوند.
اشتباهات رایج در مدیریت RBAC کوبرنتیز
در پیادهسازی RBAC، بسیاری از مشکلات امنیتی نه به دلیل ضعف ابزار، بلکه به خاطر تنظیمات نادرست رخ میدهند. مهمترین اشتباهات رایج عبارتاند از:
استفاده از ClusterRoleBinding بهجای RoleBinding
یکی از خطاهای رایج، استفاده بیدلیل از ClusterRoleBinding است. این کار میتواند باعث شود کاربری که باید فقط در یک Namespace محدود باشد، به منابع سایر Namespaceها نیز دسترسی پیدا کند.
استفاده از وایلدکارد در دسترسیها
دادن دسترسی * در منابع یا عملیاتها عملاً تمام محدودیتهای RBAC را از بین میبرد و باعث ایجاد دسترسیهای غیرقابلکنترل میشود.
استفاده از حساب cluster-admin برای کارهای روزمره
حساب cluster-admin دسترسی کامل به کل کلاستر دارد. استفاده روزمره از آن ریسک خطای انسانی را بهشدت افزایش میدهد و میتواند منجر به تغییرات مخرب در کل سیستم شود.
اضافه کردن کاربران به گروه system:masters
عضویت در این گروه باعث دور زدن کامل RBAC میشود. این سطح دسترسی عملاً معادل دسترسی روت در کل کلاستر است و باید بهشدت محدود شود.
استفاده از Service Account پیشفرض
استفاده از Service Account پیشفرض یک Namespace برای همه پادها باعث میشود سرویسهای مختلف، یک سطح دسترسی مشترک داشته باشند. این موضوع ریسک نفوذ را افزایش میدهد.
فعالسازی تنظیمات ناامن در API Server
فعال کردن گزینههایی مانند --insecure-port یا --anonymous-auth میتواند لایه احراز هویت و کنترل دسترسی را عملاً بیاثر کند.
عدم بازبینی دورهای دسترسیها
اگر Roleها و RoleBindingها بهصورت دورهای بررسی نشوند، دسترسیهای قدیمی و غیرضروری باقی میمانند و به مرور زمان سطح حمله (Attack Surface) را افزایش میدهند.
نادیده گرفتن تغییرات سازمانی
تغییر نقش افراد در سازمان یا خروج آنها باید بلافاصله در RBAC اعمال شود. عدم بهروزرسانی دسترسیها میتواند باعث انباشت مجوزهای اضافی شود.
محدودیتهای سیستم RBAC در کوبرنتیز
سیستم RBAC در کوبرنتیز ابزار اصلی کنترل دسترسی است، اما بهتنهایی برای پوشش تمام سناریوهای امنیتی کافی نیست و محدودیتهای مشخصی دارد:
۱. عدم کنترل روی محتوای منابع
RBAC فقط مشخص میکند چه کسی به یک resource دسترسی دارد، اما روی محتوای آن کنترل ندارد. برای مثال، اگر کاربری اجازه دسترسی به Secrets را داشته باشد، میتواند به محتوای رمزگذاریشده آنها دسترسی پیدا کند، بدون اینکه RBAC بتواند سطح جزئیتری از محدودیت اعمال کند.
۲. عدم جلوگیری از Privilege Escalation در سطح Pod
در صورتی که کاربر اجازه ایجاد پاد داشته باشد، میتواند از طریق اتصال Service Accountهای دارای سطح دسترسی بالاتر، به مجوزهای بیشتری دست پیدا کند. RBAC بهتنهایی جلوی این نوع ارتقا سطح دسترسی را نمیگیرد.
۳. محدودیت در کنترل منابع زیرساختی
RBAC فقط دسترسی به ایجاد یا مدیریت منابع را کنترل میکند، اما نمیتواند نوع یا رفتار دقیق برخی منابع را محدود کند. برای مثال، کاربر میتواند در صورت داشتن مجوز، نوع PersistentVolume را به شکلی انتخاب کند که ریسک امنیتی ایجاد کند.
۴. عدم کنترل روی عملیاتهای حساس خاص
برخی عملیات مانند impersonate ،bind و escalate میتوانند منجر به دور زدن سیاستهای دسترسی شوند. RBAC این عملیاتها را در سطح منطقی کنترل میکند، اما سوءاستفاده از آنها در صورت داشتن مجوز، همچنان امکانپذیر است.
۵. محدودیت در برابر حملات سطح کلاستر
RBAC توانایی محدود کردن رفتارهایی مانند ایجاد حجم بالای resource و مصرف بیش از حد etcd یا CPU را ندارد. برای این موارد باید از مکانیزمهای مکمل مانند ResourceQuota و LimitRange استفاده شود.
جمعبندی
RBAC در کوبرنتیز یکی از مهمترین لایههای امنیتی برای مدیریت دسترسی کاربران و سرویسها در کلاستر است. این مکانیزم بر پایه تعریف نقشها (Role و ClusterRole)، اتصال آنها به هویتها (RoleBinding و ClusterRoleBinding) و اعمال سیاستهای دسترسی در سطح API Server عمل میکند.
در سطح عملی، RBAC به شما اجازه میدهد دسترسیها را بهصورت دقیق و محدود در سطح Namespace یا کل کلاستر کنترل کنید و اصل Least Privilege را پیادهسازی کنید. با این حال، این سیستم بهتنهایی کافی نیست و باید در کنار سایر مکانیزمهای امنیتی مانند ResourceQuota، LimitRange و سیاستهای امنیتی تکمیلی استفاده شود.
همچنین بیشترین خطاها در پیادهسازی RBAC معمولاً ناشی از استفاده بیش از حد از دسترسیهای سراسری، بیتوجهی به Service Accountها و عدم بازبینی دورهای مجوزهاست. در نهایت، RBAC یک ابزار پایه و ضروری برای امنیت Kubernetes است، اما ارزش واقعی آن زمانی مشخص میشود که بهدرستی طراحی، محدود و در کنار سایر لایههای امنیتی استفاده شود.