فهرست عناوین
عملکرد ماژول Keystone در OpenStack چگونه است؟
در اینسری از آموزشها قصد بررسی ماژول Keystone در OpenStack را داریم؛
در ابتدا یک بررسی کلی از ماژول Keystone خواهیم داشت. در این بررسی نشان میدهیم که Keystone:
– چگونه به کاربر یا گروهها، برای پروژهها یا Domainها به منظور دادن مجوز یا دسترسی، Role تخصیص میدهد؟
– چگونه برای تحقق این امر از توکنها استفاده میکند و Service Catalog را ارائه میدهد؟
– انواع سرویسهای Identity را معرفی میکنیم و در آخر، در مورد مدیریت دسترسیها و مجوزها صحبت خواهیم کرد.
مفهوم Keystone
Keystone حاوی چندین مفهوم هست که چگونگی ارتباط آن با OpenStack را مشخص میکند. این مفاهیم شامل احراز هویت مجوزها میباشند که تمرکز اصلی روی نحوهی مجوزدهی، مدیریت آن و کشف سرویسها میباشد.
1. پروژه
پروژه شامل مفهومی است که در آن منابعی مانند سرورها، ایمیجها و … را برای دیگر سرویسها، گروهبندی یا ایزوله میکنیم. در واقع به بیان عادلانه؛ مهمترین هدف سرویس Keystone، ثبت پروژهها و تعیین کسانی که باید به پروژهها دسترسی داشته باشند، میباشد. لذا باید به کاربران یا گروهها، برای دسترسی به یک پروژه از مفهومی به نام تخصیص Role استفاده کرد. این تخصیص Role با نام Grant در داکیومنت OpenStack آورده شده است.
2. Domain
قبلا در OpenStack هیچ مکانیزمی به منظور محدود کردن پروژهها برای کاربران سازمانهای مختلف نبود تا ابرهای OpenStack به طور هم زمان بتوانند چندین سازمان را پشتیبانی کنند؛ که سبب اختلال در نامگذاری پروژهها و ایجاد پروژههایی با نام مشابه میشد.
همچنین همین مسئله برای نامهای کاربران اتفاق میافتاد؛ لذا نیاز شد تا پروژهها و کاربران را درون یک NameSpace تعریف کنند تا قادر به ایزوله کردن آنها باشد؛ اینجا بود که مفهوم Domain به وجود آمد. در واقع Domain، امکان دستهبندی منابع درون کلود را فراهم میآورد؛ به عنوان مثال یک کلود میتواند دو Domain داشته باشد که منابع هر Domain کاملا از هم، مجزا هستند.
3. کاربران و گروههایی از کاربران (Actorها)
کاربران و گروهها به عنوان استفادهکنندگان نهایی از ابر محسوب میشوند و به آنها Actor گفته میشود که میتوان آنها را با تخصیص مجوز و دادن Role، به Domain یا پروژه اضافه کرد.
همانطور که مشاهده میکنید کاربران، گروهها و پروژهها در داخل Domianها محدود میشوند، لذا میتوانند در بین Domainها مشترک باشند. برای مثال در هر دو Domainها، کاربری با نام Alireza و گروه Administrators میتوان تعریف کرد.
نکتهی قابل ذکر این است که هر Entity مانند کاربر یا گروه دارای یک UUID منحصربهفرد هست، لذا میتوان از آن برای پیدا کردن منابع استفاده کرد. ولی برای نامشان این منحصربهفردی ضمانت نمیشود و برای استفاده به منظور یافتن منابع، نیاز است که همراه آن از Domain استفاده شود. همچنین Roleها طبق شکل فوق، محدود به Domain نیستند اما شاید در آینده این اتفاق رخ دهد.
4. Roleها
Roleها در Keystone، برای مجوزدهی مورد استفاده قرار میگیرند. یک Actor (کاربر یا گروه) میتواند چندین Role برای هدف داشته باشد. به عنوان مثال Role ادمین، میتواند برای پروژه Development به کاربر Alireza تخصیص داده شود.
5. Assignment
ترکیب سه تایی (یا بیشتر) Actor، هدف و Role، تخصیص یا Assignment نامیده میشود. Role Assignmentها میتوانند اعطا یا ابطال شوند و یا بین گروهها، کاربران، پروژهها و Domainها ارث برده شوند.
6. هدف یا Targetها
پروژهها و Domainها از نظر دادن دسترسی به کاربر و گروهها شبیه به هم، عمل میکنند. به عبارت دیگر یک کاربر یا گروه، با استفاده از Role Assignment، به پروژه یا Domain، دسترسی دارد؛ و چون پروژهها و دامنهها خصوصیات مشابه دارند هر دوی آنها را به عنوان هدف در نظر میگیریم.
7. توکن
برای فراخوانی هر کدام از APIهای سرویسهای درون OpenStack، نیاز است تا احراز هویت و مجوز فراخوانی API توسط کاربر مورد بررسی قرار گیرد که این امر توسط توکن انجام میشود و سرویس Keystone مسئول تولید کردن این توکنها میباشد.
به محض موفق بودن عملیات احراز هویت توسط Keystone، کاربر این توکن را دریافت میکند. هر توکن حاوی ID (که به ازای هر ابری یکتاست) و Payload که حاوی اطلاعات کاربر است، میباشد. در مثال زیر، توکنی برای یک کاربر به منظور دسترسی به یک پروژه، نشان داده شده است.
همانطور که مشاهده میکنید اطلاعاتی همچون زمان ایجاد و منقضی شدن، Role، پروژهای که کاربر به آن دسترسی دارد و Catalog، در توکن وجود دارد.
8. Catalog
این سرویس برای ابر OpenStack ضروری میباشد و شامل تمام URLها و Endpointهایی از سرویسهای OpenStack است که دسترسی آن به کاربر داده شده است. بدون آن، کاربران و اپلیکیشنها مثلا برای ایجاد کردن ماشینهای مجازی، اطلاعی از مسیر یا URL برای درخواست دادن آنها ندارند.
این Service Catalog، شامل لیستی از Endpointهاست که هر Endpoint شامل Admin URL، Internal URL و Public URLl که ممکن است مقادیر یکسانی داشته باشند، میباشد.
در شکل زیر یک Service Catalog که شامل دو سرویس Identity و آبجکت Storage میباشد، آورده شده است.
سرویس Identity
این سرویس در Keystone برایActorها فراهم شده است و میتواند از انواع مختلفی چون SQL، LDAP و Federated Identity Provider و … باشد.
SQL
Keystone کاربران و گروهها را در SQL ذخیره میکند. دیتابیسهای پشتیبانی شده شامل MySQL، PostgresSQL و DB2 میباشد. Keystone اطلاعاتی چون نام، پسورد و Description را ذخیره میکند و میتوان در فایل پیکربندی Keystone این تنظیمات را مشخص نمود.
Keystone به عنوان یک فراهمکنندهی سرویس Identity عمل میکند و ممکن است برای سازمانها و مشتریان Best Case نباشد. در زیر مزایا و معایب استفاده از SQL برای سرویس Identity آورده شده است:
مزایا:
- قادر به پشتیبانی همزمان چندین LDAP برای اکانت کاربران و SQL Backend برای اکانتهای مربوط به سرویس.
- استفاده از LDAP موجود در سازمان برای Identity
معایب:
- تنظیمات پیچیده برای راهاندازی
- احراز هویت برای اکانتهای مربوط به کاربران باید درون همان Domain و توسط LDAP مربوطه انجام شود.
فراهمکنندگان Identity
در نسخهی Icehouse، ماژول Keystone قادر است عملیات احراز هویت را به وسیله یک سرویس خارجی که به عنوان فدورال (Federate) شناخته میشود از طریق ماژول آپاچی انجام دهد. این سرویس Identity در فایل پیکربندی Keystone قابل تعریف میباشد.
اطلاعات کاربران در سرویسهای خارج از سازمان (در ابر دیگر) قرار دارد و از دید Keystone، این سرویسها، یک فراهمکننده برای Identityهاست که میتواند نرمافزارهای Backendای چون LDAP، اکتیودایرکتوری یا MongoDB و یا حتی سیستمهای احراز هویت شبکههای اجتماعی مانند گوگل، فیسبوک، توئیتر باشد.
همچنین نرمافزارهایی چون SMAL، OpenID Connect برای تبدیل خروجی نرمافزارهای Backend (همان مشخصات کاربران) به فرمت پروتکل Federate استاندارد، مورد استفاده قرار میگیرد.
در زیر مزایا و معایب این روش بیان شده است:
مزایا:
- قادر به استفاده از زیرساخت موجود برای احراز هویت و بازیابی اطلاعات کاربران.
- تفکیک بیشتر بین Keystone و اداره کردن اطلاعات مربوط به سرویس Identity.
- مهیا کردن امکانات جدید در حوزهی ابرهای فدورال مانند احراز هویت و ابر ترکیبی.
- پسورد کاربران برای Keystone قابل مشاهده نیست.
- سرویسهای Identity فرایند احراز هویت را به طور کامل انجام میدهند و دسترسی Keystone به پسورد و گواهیها، غیرضروری و بی معنی تلقی میشود.
معایب:
راهاندازی سرویسهای Identity با پیچیدگی بیشتری روبرو میباشد.
Use Case مناسب استفاده از روشهای بیان شده برای سرویس Identity، در جدول زیر آمده است:
Use case | Identity Source |
---|---|
Use this if you’re testing or developing with OpenStack – Small set of users – OpenStack-specific accounts (service users) – |
SQL |
Use this if it’s already in place in your business –
Use only LDAP if you are able to create the service accounts necessary in the LDIP – |
LDAP |
Preferred approach for most enterprises –
Use if service users are not allowed in LDAP – |
Multiple backend |
You want to take advantage of the new Federated Identity mechanisms –
Use this if an identity provider already exists (for single sign-on) – Keystone is unable to access LDAP – |
Identity provider |
احرازهویت
روشهای مختلفی برای احزار هویت در Keystone وجود دارد که در حال حاضر دو روش رایج میباشند. در این بخش این دو روش را معرفی کرده و دادههای لازم برای ارسال درخواست POST برای Keystone را بیان میکنیم.
1. پسورد
روش رایج برای احراز هویت کاربر، استفاده از پسورد است؛ در زیر یک نمونه از درخواست POST به سمت Keystone را مشاهده میکنید.
توسط اطلاعات ارسال شده در شکل بالا، باید بتوان کاربر را پیدا و احراز هویت کرد و بسته به سطح دسترسی کاربر، یک Service Catalog را برای کاربر ارسال کرد.
در قسمت User باید اطلاعات Domain (نام یا ID آن) برای جستجوی کاربر قرار داشته باشد، مگر اینکه از ID سرتاسری کاربر، استفاده شود؛ دلیل این موضوع، پیادهسازیهای چندین Domain میباشد که میتواند کاربرهایی با نام یکسان در Domainهای مختلف وجود داشته باشد.
قسمت Scope در درخواست بالا اختیاری است اما در بیشتر مواقع این قسمت آورده میشود و کاربر قادر به مشاهده Service Catalog خود است و مشخص میکند که با کدام پروژه قرار است کار کند. در پاسخ به این درخواست، اگر کاربر هیچ Roleای برای این پروژه نداشته باشد، درخواست Reject میشود.
مشابه قسمت User، این قسمت هم باید شامل اطلاعات لازم برای یافتن پروژه باشد، بنابراین باید Domain هم مشخص شده باشد، زیرا نام پروژهها مانند نام کاربران و گروهها ممکن است در Domainهای مختلف مشابه باشد. (اگر از ID سرتاسری پروژه استفاده کنیم دیگر نیازی به مشخص کردن Domain نیست).
همانطور که در شکل مقابل، مشاهده میکنید کاربر برای دریافت توکن، نام کاربری، پسورد و مشخصات پروژه (همان قسمت Scope مربوط به درخواستی که برای Keystone میفرستیم) را ارسال میکند. سپس این توکن بدست آمده، میتواند توسط سایر سرویسهای OpenStack مورد استفاده قرار گیرد.
2. توکن
مشابه مورد بالا کاربر میتواند به همراه درخواست خود، توکن فعلی را ارسال و توکن جدید دریافت کند. این درخواست POST حاوی Payload کمتری نسبت به مورد قبلی میباشد.
دلایل زیادی برای درخواست توکن جدید وجود دارد، مثلا برای موقعی که توکن قرار هست Expire شود و باید آن را رفرش کرد یا اینکه به توکن، قسمت Scope باید اضافه شود و توکن جدیدی را دریافت کرد. در شکل زیر ساختار توکن نشان داده شده است.
مدیریت دسترسیها و مجوزها
یکی از دلایل لازمهی وجود ماژول Keystone در OpenStack، تعیین مجوزها و دسترسیها برای APIهاست. رویکرد Keystone برای این مورد، ایجاد پالیسیهایی به نام Role Base Access Control میباشد که روی Endpointهای پابلیک اعمال میشوند.
این پالیسیها در فایلی به نام Policy.Json، که از هدفها و Rulesها تشکیل شدهاند ذخیره میشوند. همانطور که در شکل پایین، قسمتی از این فایل پیکربندی را مشاهده مینمایید، Keyها، هدفها و Valueها، Ruleها میباشند.
هر Rule با واژهی Identity شروع میشود و یک کنترلر محافظت شده را مشخص میکند تا یک API را مدیریت کند. همانطور که مشاهده میکنید سه هدف با نامهای Admin_Required، Owner، Admin_or_Owner تعریف شدهاند که این هدفها دسترسی هدفهای بعدی را مشخص میکنند.
به عنوان مثال برای مشاهده لیست همهی پروژهها تنها به ادمین نیاز است، اما برای مشاهده لیست همهی پروژههای کاربر، علاوه بر ادمین به Owner نیز، نیاز میباشد.
در جدول زیر آدرس هر API، با یک هدف آورده شده است:
API | Policy Target |
---|---|
GET/ V3/ Projects | Identity:List_Projects |
POST/ V3/ Projects | Identity:Create_Projects |
DELETE/ V3/ Projects/ {Project_ID} | Identity:Delete_Projects |
GET/ V3/ Users/ {User_ID}/ Projects | Identity:List_User_Projects |
ثبت ديدگاه