آیا شما باید بیش از یک تیم داشته باشید که از همان خوشه Kubernetes استفاده می کنند؟
آیا می توانید بارهای کاری نامعتبر را با خیال راحت از کاربران نامعتبر اجرا کنید؟
آیا Kubernetes چند اجاره ای انجام می دهد؟
این مقاله به بررسی چالش های اداره یک خوشه با چندین مستاجر می پردازد.
چند اجاره ای را می توان به موارد زیر تقسیم کرد:
- چند اجاره ای نرم برای زمانی که به مستاجران خود اعتماد دارید – مانند زمانی که یک خوشه را با تیم هایی از یک شرکت به اشتراک می گذارید.
- چند اجاره ای سخت برای زمانی که به مستاجران اعتماد ندارید
شما همچنین می توانید یک میکس داشته باشید!
بلوک اصلی برای به اشتراک گذاشتن یک خوشه بین مستاجرین، فضای نام است.
فضاهای نام منابع را به طور منطقی گروه بندی می کنند – آنها هیچ مکانیزم امنیتی ارائه نمی دهند و تضمین نمی کنند که همه منابع در یک گره مستقر شوند.
پادهای موجود در یک فضای نام همچنان می‌توانند با همه پادهای دیگر در خوشه صحبت کنند، به API درخواست دهند و از منابعی که می‌خواهند استفاده کنند.
خارج از جعبه، هر کاربری می تواند به هر فضای نامی دسترسی داشته باشد.
چگونه باید آن را متوقف کنید؟
با RBAC، می‌توانید کارهایی که کاربران و برنامه‌ها می‌توانند با و در داخل یک فضای نام انجام دهند را محدود کنید.
یک عملیات رایج اعطای مجوز به کاربران محدود است.
با Quotas و LimitRanges می توانید منابع مستقر شده در فضای نام و حافظه، CPU و غیره را که می توان از آنها استفاده کرد، محدود کنید.
اگر می خواهید کاری را که مستاجر می تواند با فضای نام خود انجام دهد، محدود کنید، این یک ایده عالی است.
به طور پیش فرض، همه پادها می توانند با هر پاد در Kubernetes صحبت کنند.
این برای چند اجاره ای عالی نیست، اما می توانید با Network Policies آن را اصلاح کنید.
خط مشی های شبکه مشابه قوانین فایروال است که به شما امکان می دهد ترافیک خروجی و ورودی را جدا کنید.
عالی، آیا فضای نام در حال حاضر امن است؟
نه خیلی سریع.
در حالی که RBAC، Network Policies، Quotas و غیره، بلوک‌های اساسی برای چند اجاره‌نشینی را به شما می‌دهند، کافی نیست.
Kubernetes چندین مؤلفه مشترک دارد.
یک مثال خوب، کنترلر Ingress است که معمولاً یک بار در هر خوشه مستقر می شود.
اگر مانیفست ورودی را با همان مسیر ارسال کنید، آخرین آن تعریف را بازنویسی می کند و تنها یکی کار می کند.
این ایده بهتر است که یک کنترلر در هر فضای نام مستقر کنید.
چالش جالب دیگر CoreDNS است.
اگر یکی از مستاجرین از DNS سوء استفاده کند چه؟
بقیه خوشه نیز آسیب خواهند دید.
می توانید درخواست ها را با یک پلاگین اضافی https://github.com/coredns/policy محدود کنید.
همین چالش در مورد سرور API Kubernetes نیز صدق می کند.
Kubernetes از مستاجر آگاه نیست، و اگر API درخواست های زیادی دریافت کند، آنها را برای همه کاهش می دهد.
نمی دانم راه حلی برای این کار وجود دارد یا نه!
با فرض اینکه شما می‌توانید منابع مشترک را مرتب کنید، چالش Kubelet و بارهای کاری نیز وجود دارد.
همانطور که Philippe Bogaerts در این مقاله توضیح می‌دهد، یک مستاجر می‌تواند گره‌های خوشه را فقط با استفاده از کاوشگرهای زنده تصاحب کند.
رفع مشکل پیش پا افتاده نیست.
می‌توانید یک لنگر را به عنوان بخشی از فرآیند CI/CD خود داشته باشید یا از کنترل‌کننده‌های پذیرش برای بررسی ایمن بودن منابع ارسال‌شده به خوشه استفاده کنید.
در اینجا یک کتابخانه یا قوانینی برای Open Policy Agent وجود دارد.
شما همچنین کانتینرهایی دارید که مکانیسم ایزوله ضعیف تری نسبت به ماشین های مجازی ارائه می دهند.
لوئیس دنهام-پاری در این ویدیو نحوه فرار از کانتینر را نشان می دهد.
چگونه می توانید این را برطرف کنید؟
می توانید از یک جعبه شنی کانتینری مانند gVisor، ماشین های مجازی سبک به عنوان کانتینر (ظروف کاتا، فشفشه + کانتینر) یا ماشین های مجازی کامل (virtlet به عنوان CRI) استفاده کنید.
امیدواریم که متوجه پیچیدگی موضوع شده باشید و سخت است که برای شبکه‌ها، بارهای کاری و کنترل‌کننده‌های مجزای مجزا در Kubernetes، مرزهای سختی ایجاد کنید.
به همین دلیل است که ارائه چند اجاره ای سخت در Kubernetes توصیه نمی شود.
اگر به چند اجاره ای سخت نیاز دارید، توصیه این است که به جای آن از چندین کلاستر یا ابزار Cluster-as-a-Service استفاده کنید.
اگر می‌توانید مدل ضعیف‌تر چند اجاره‌نشینی را در ازای سادگی و راحتی تحمل کنید، می‌توانید قوانین RBAC، سهمیه‌ها و غیره خود را اجرا کنید.
اما چند ابزار وجود دارد که این مشکلات را از شما انتزاع می کند:
و در نهایت، اگر از این موضوع لذت برده اید، ممکن است این موضوع را نیز دوست داشته باشید:
