عملکرد ماژول 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 یا پروژه اضافه کرد.

برای درک بهتر، در شکل زیر رابطه بین 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 که حاوی اطلاعات کاربر است، می‌باشد. در مثال زیر، توکنی برای یک کاربر به منظور دسترسی به یک پروژه، نشان داده شده است.

Copy to Clipboard

 

همان‌طور که مشاهده می‌کنید اطلاعاتی همچون زمان ایجاد و منقضی شدن، Role، پروژه‌ای که کاربر به آن دسترسی دارد و Catalog، در توکن وجود دارد.

 

8. Catalog

این سرویس برای ابر OpenStack ضروری می‌باشد و شامل تمام URLها و Endpointهایی از سرویس‌‌های OpenStack است که دسترسی آن به کاربر داده شده است. بدون آن، کاربران و اپلیکیشن‌ها مثلا برای ایجاد کردن ماشین‌های مجازی، اطلاعی از مسیر یا URL برای درخواست دادن آنها ندارند.

این Service Catalog، شامل لیستی از Endpointهاست که هر Endpoint شامل Admin URL، Internal URL و Public URLl که ممکن است مقادیر یکسانی داشته باشند، می‌باشد.

در شکل زیر یک Service Catalog که شامل دو سرویس Identity و آبجکت Storage می‌باشد، آورده شده است.

Copy to Clipboard

سرویس Identity

این سرویس در Keystone برایActor‌ها فراهم شده است و می‌تواند از انواع مختلفی چون SQL، LDAP و Federated Identity Provider و … باشد.

 

1. SQL

Keystone کاربران و گروه‌ها را در SQL ذخیره می‌کند. دیتابیس‌های پشتیبانی شده شامل MySQL، PostgresSQL و DB2 می‌باشد. Keystone اطلاعاتی چون نام، پسورد و Description را ذخیره می‌کند و می‌توان در فایل پیکربندی Keystone این تنظیمات را مشخص نمود.

Keystone به عنوان یک فراهم‌کننده‌ی سرویس Identity عمل می‌کند و ممکن است برای سازمان‌ها و مشتریان Best Case نباشد. در زیر مزایا و معایب استفاده از SQL برای سرویس Identity آورده شده است:

 

مزایا:

  • نصب و راه‌اندازی آسان
  • مدیریت کاربران و گروه‌ها از طریق APIهای OpenStack

معایب:

  • Keystone نباید یک ارائه دهنده‌‌ی Identity باشد.
  • پشتیبانی از پسوردهای ضعیف.
  • عدم بازگردانی پسورد.
  • عدم امکان تغییر و ریست کردن پسورد.

 

2. LDAP

Keystone مانند هر برنامه‌ی دیگری که به LDAP درخواست ارسال می‌کند (مانند Web Application ،  Email و …) از این آپشن برای بازیابی و ذخیره‌ی Actorها (کاربران و گروه‌ها) استفاده و درخواست خود را ارسال می‌کند. همچنین تنظیمات مربوط به کانکشن LDAP در فایل پیکربندی Keystone قابل انجام می‌باشد.

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

در صورت استفاده از LDAP به صورت یک Identity پشت‌زمینه به منظور خواندن اطلاعات، Keystone به حداقل Privilege برای استفاده نیاز دارد؛ در واقع برای خواندن خصوصیات کاربران و گروه‌ها به دسترسی Read که در فایل Keystone.Conf تنظیم شده است و یک اکانت (می‌تواند Anonymous باشد) که بدون پسورد است، نیاز دارد.

مزایا و معایب استفاده از LDAP به عنوان یک سرویس Identity در زیر آورده شده است:

 

مزایا:

  • دیگر نیازی به نگهداری کپی‌های کاربران نیست.
  • Keystone به عنوان فراهم‌کننده‌ی Identity اقدام نمی‌کند.

معایب:

  • اکانت‌های مربوط به سرویس، نیاز است در جای دیگری ذخیره شوند و ادمین LDAP ممکن است با ذخیره این اکانت‌ها در LDAP موافق نباشد.
  • پسورد کاربر برای Keystone قابل مشاهده است، چون از آن برای احراز هویت توسط LDAP استفاده می‌کند.

 

3. Identityهای Backend چندگانه

در نسخه‌ی Juno ماژول Keystone برای Identity API ورژن 3، این آپشن مورد پشتیبانی قرار گرفت و از این‌رو می‌توان در هر Domain از یک سرویس Identity Backend استفاده کرد. Domain Default معمولا ازSQL Backend استفاده می‌کند که اکانت‌های مربوط به سرویس را میزبانی می‌کند.

این اکانت‌ها، مربوط به سرویس‌های دیگر OpenStack می‌باشند که با سرویس Keystone تعامل می‌کنند. برای دیگر Domianها، به تعدادشان می‌توان Identity Backendها مانند LDAP را به خدمت گرفت.

دلیل وجود چنین کاری این است که مدیران LDAP ممکن است در همان سازمانی که تیم OpenStack مستقر است نباشند و بنابراین ایجاد اکانت‌های سرویس درون LDAP غیر معمول می‌شود و به طور کلی بهتر است از LDAP به منظور خواندن اطلاعات کارمندان استفاده شود.

در زیر مزایا و معایب این روش بیان شده است:

 

مزایا:

  • قادر به پشتیبانی همزمان چندین LDAP برای اکانت کاربران و SQL Backend برای اکانت‌های مربوط به سرویس.
  • استفاده از LDAP موجود در سازمان برای Identity

معایب:

  • تنظیمات پیچیده برای راه‌اندازی
  • احراز هویت برای اکانت‌های مربوط به کاربران باید درون همان Domain و توسط LDAP مربوطه انجام شود.

 

4. فراهم‌کنندگان 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 را مشاهده می‌کنید.

Copy to Clipboard

توسط اطلاعات ارسال شده در شکل بالا، باید بتوان کاربر را پیدا و احراز هویت کرد و بسته به سطح دسترسی کاربر، یک 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 باید اضافه شود و توکن جدیدی را دریافت کرد. در شکل زیر ساختار توکن نشان داده شده است.

Copy to Clipboard

مدیریت دسترسی‌ها و مجوزها

یکی از دلایل لازمه‌ی وجود ماژول Keystone در OpenStack، تعیین مجوزها و دسترسی‌ها برای APIهاست. رویکرد Keystone برای این مورد، ایجاد پالیسی‌هایی به نام Role Base Access Control می‌باشد که روی Endpointهای پابلیک اعمال می‌شوند.

این پالیسی‌ها در فایلی به نام Policy.Json، که از هدف‌ها و Rulesها تشکیل شده‌اند ذخیره می‌شوند. همان‌طور که در شکل پایین، قسمتی از این فایل پیکربندی را مشاهده می‌نمایید، Keyها، هدف‌ها و Valueها، Ruleها می‌باشند.

Copy to Clipboard

هر 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