تصویر کلی
Keystone اعتبارنامه را اعتبارسنجی و Token صادر می‌کند؛ سرویس‌های دیگر برای درخواست‌های بعدی به همین هویت و Scope تکیه می‌کنند.
برای فهم این موضوع بهتر است اجزا را به‌عنوان یک مسیر ببینیم، نه مجموعه‌ای از گزینه‌های مستقل. در Production معمولاً مشکل زمانی شکل می‌گیرد که تنظیم روی دیسک، وضعیت Runtime و فرض تیم درباره رفتار سیستم با هم یکی نیستند. به همین دلیل مشاهده وضعیت مؤثر، Log و Metric باید کنار Configuration بررسی شود.
اجزای اصلی و مرز مسئولیت
Domain مجموعه‌ای از User و Project و یک مرز مدیریتی است؛ Project معمولاً Scope منابع و تخصیص‌های سرویس را شکل می‌دهد.
در طراحی عملی، برای هر جزء یک سؤال روشن بنویسید: چه ورودی می‌گیرد، چه خروجی تولید می‌کند، چه Stateای نگه می‌دارد و در خرابی چه کسی مسئول Recovery است. این مدل ساده کمک می‌کند خطاهای شبکه، هویت، ذخیره‌سازی یا Replication به‌اشتباه به جزء دیگری نسبت داده نشوند.
خطاهای رایج
Role Assignment باید Scope مشخص داشته باشد؛ داشتن هویت به‌تنهایی به معنی مجوز انجام هر عملیات نیست.
خطای دیگر، فعال‌کردن قابلیت پیشرفته بدون تعریف معیار موفقیت است. قبل از تغییر، Baseline بگیرید؛ بعد از تغییر همان Signalها را مقایسه کنید. اگر سیستم توزیع‌شده است، Failure Modeهای قطع شبکه، Restart، Lag، Timeout و از دست‌رفتن Dependency را نیز آزمایش کنید.
چک‌لیست عملی
- نسخه و Configuration مؤثر را ثبت کنید، نه فقط فایل مورد انتظار را.
- مسیر داده و کنترل را جدا رسم کنید.
- Health، Latency، Error Rate و ظرفیت را قبل و بعد از تغییر مقایسه کنید.
- برای تغییرات Stateful، Backup/Restore یا Rollback واقعی را آزمایش کنید.
- دسترسی مدیریتی را حداقل کنید و Log تصمیم‌ها را نگه دارید.
- مستندات همان نسخه محصول را مرجع نهایی قرار دهید.
تمرین IROSG
یک محیط کوچک آزمایشی بسازید و فقط یک Failure را تزریق کنید؛ مثلاً قطع Upstream، حذف یک Replica، خطای DNS یا تغییر Route. قبل از آزمایش بنویسید انتظار دارید کدام Metric و Log تغییر کند. بعد نتیجه واقعی را با انتظار مقایسه کنید. این تمرین معمولاً سریع‌تر از حفظ‌کردن Optionها، مدل ذهنی سیستم را اصلاح می‌کند.
مرجع
این راهنما بر پایه مستندات رسمی OpenStack Keystone نوشته شده و مثال‌های عملی تحریریه برای آموزش دفاعی و عملیاتی هستند.
هویت، دامنه دسترسی و تصمیم سرویس
در یک ابر سازمانی، دانستن نام کاربر تنها نخستین مرحله است. درخواست بعدی باید روشن کند کاربر در چه محدوده‌ای عمل می‌کند و سرویس مقصد چه عملیاتی را برای او مجاز می‌داند. Keystone اطلاعات هویت و دامنه را در اختیار مسیر درخواست قرار می‌دهد، اما سیاست نهایی بسیاری از عملیات در سرویس مقصد ارزیابی می‌شود. بنابراین داشتن توکن معتبر الزاماً اجازه ساخت ماشین، تغییر شبکه یا حذف داده را نمی‌دهد. این جداسازی برای فهم خطاهای دسترسی بسیار مهم است.
فرض کنید یک کاربر در پروژه توسعه اجازه ساخت ماشین دارد ولی در پروژه مالی فقط خواننده است. ورود موفق با همان نام کاربری هر دو وضعیت را ممکن می‌کند؛ تفاوت در تخصیص نقش و دامنه درخواست است. هنگام عیب‌یابی، نام کاربر را کافی ندانید. شناسه پروژه، دامنه، نقش‌های مؤثر و نشانی سرویس مقصد را نیز ثبت کنید. دو فرمان ظاهراً یکسان ممکن است به دلیل متغیر محیطی متفاوت، با پروژه یا ناحیه دیگری اجرا شوند.
Domain برای جداسازی مدیریت هویت
Domain می‌تواند مجموعه کاربران، گروه‌ها و پروژه‌ها را در یک مرز مدیریتی سازمان دهد. این مفهوم را نباید با دامنه DNS یا شبکه مجازی یکسان گرفت. نام مشابه کاربران در دو دامنه لزوماً به یک هویت اشاره نمی‌کند. برای رفع ابهام، شناسه‌ها و دامنه مربوط را در عملیات خودکار صریح نگه دارید. تکیه بر نام نمایشی به تنهایی می‌تواند اسکریپت را در محیط چنددامنه‌ای به مقصد اشتباه ببرد.
انتخاب ساختار دامنه باید با مسئولیت مدیریت و چرخه عمر هویت هماهنگ باشد. ایجاد دامنه تازه برای هر پروژه کوچک ممکن است مدیریت را پیچیده کند، در حالی که ادغام همه واحدهای مستقل در یک مرز نیز تفویض اختیار را دشوار می‌سازد. ابتدا مشخص کنید چه کسی حق ایجاد کاربر، مدیریت گروه و تعریف پروژه دارد. سپس ساختاری انتخاب کنید که این مسئولیت‌ها را روشن کند. مرز اداری روی کاغذ باید در مجوزهای واقعی نیز دیده شود.
Project و منابع سرویس‌ها
Project معمولاً محدوده‌ای برای مالکیت یا تخصیص منابع در سرویس‌های مختلف است، اما جزئیات هر سرویس را باید جدا خواند. عضویت کاربر در پروژه به معنای داشتن همه مجوزها نیست و سهمیه نیز با نقش تفاوت دارد. کاربر ممکن است مجوز ساخت ماشین داشته باشد ولی به دلیل پر بودن سهمیه نتواند منبع تازه ایجاد کند. خطای سهمیه را با خطای احراز هویت یا سیاست اشتباه نگیرید؛ پاسخ و گزارش سرویس مقصد مسیر تشخیص را روشن می‌کند.
برای یک محیط آزمایشی، دو پروژه بسازید و یک کاربر را با نقش محدود در یکی قرار دهید. سپس عملیات خواندن و نوشتن را در هر دو پروژه امتحان کنید. فهرست منابع را نیز مقایسه کنید تا روشن شود کدام داده‌ها در هر دامنه دیده می‌شوند. هدف این آزمایش فقط گرفتن یک خطای دسترسی نیست؛ باید نشان دهد منابع و مجوزها مطابق قرارداد مورد انتظار جدا شده‌اند و تغییر پروژه در کلاینت واقعاً بر دامنه درخواست اثر دارد.
Role نامی است که سیاست به آن معنا می‌دهد
نقش در یک تخصیص، رابطه میان هویت و دامنه را بیان می‌کند. نام نقش به تنهایی توضیح کامل عملیات مجاز نیست؛ سرویس‌ها و سیاست‌های نصب‌شده تعیین می‌کنند آن نقش در هر درخواست چه معنایی دارد. بنابراین ایجاد نقشی با نام دلخواه لزوماً قابلیت تازه‌ای در همه سرویس‌ها فعال نمی‌کند. پیش از افزودن نقش، بدانید کدام سیاست آن را مصرف می‌کند و آزمون مثبت و منفی آن چیست.
تخصیص مستقیم به کاربر با تخصیص از طریق گروه نیز باید در بررسی دسترسی دیده شود. حذف یک تخصیص مستقیم ممکن است دسترسی را از بین نبرد، زیرا کاربر همان نقش را از گروه دیگری دریافت می‌کند. برای خروج کارکنان یا تغییر مسئولیت، همه مسیرهای مؤثر را بررسی کنید. گزارش دسترسی باید منشأ نقش را نشان دهد تا مدیر بتواند بفهمد چرا کاربر هنوز مجاز است. حذف تصادفی گروه‌ها بدون شناخت اثر آنها می‌تواند کاربران نامرتبط را نیز مختل کند.
توکن با دامنه و بدون دامنه
توکن می‌تواند بسته به جریان احراز هویت و نیاز، دامنه متفاوتی داشته باشد. توکن بدون دامنه را نباید معادل مجوز کار روی همه پروژه‌ها دانست. انتخاب دامنه مناسب در درخواست توکن اهمیت دارد و باید با عملیات بعدی سازگار باشد. اگر کلاینت خطای دسترسی می‌دهد، بررسی کنید واقعاً توکن برای پروژه یا دامنه مورد انتظار گرفته شده است. بسیاری از خطاهای عملیاتی از تنظیمات محیطی باقی‌مانده در پوسته یا فایل پیکربندی ناشی می‌شوند.
توکن را مانند اعتبارنامه حساس نگه دارید. چاپ کامل آن در تیکت یا گزارش می‌تواند دسترسی ناخواسته ایجاد کند. برای تشخیص مشکل معمولاً نوع دامنه، زمان اعتبار، شناسه پروژه و شناسه درخواست کافی‌تر از متن کامل توکن است. همچنین زمان ماشین‌ها و اعتبار زمانی باید بررسی شود. خطای ناشی از ساعت را با تمدید نامحدود عمر توکن حل نکنید؛ هماهنگی زمان بخش مستقلی از زیرساخت اعتماد است.
Service Catalog و انتخاب Endpoint
کاتالوگ سرویس به کلاینت کمک می‌کند نشانی رابط مناسب را پیدا کند. وجود سرویس در کاتالوگ به معنای سالم بودن شبکه یا برنامه مقصد نیست. کلاینت ممکن است میان نشانی عمومی، داخلی یا مدیریتی و ناحیه‌های مختلف انتخاب کند. اگر نشانی انتخاب‌شده از شبکه کاربر قابل دسترسی نباشد، احراز هویت موفق می‌شود ولی عملیات بعدی شکست می‌خورد. این الگو را به عنوان نشانه جداسازی مسیر هویت و مسیر سرویس در نظر بگیرید.
برای بررسی، نشانی انتخاب‌شده، ناحیه و نوع رابط را با طراحی شبکه مقایسه کنید. نام دامنه، گواهی و پورت مقصد باید از همان محل اجرای کلاینت قابل استفاده باشند. تغییر سراسری کاتالوگ برای حل مشکل یک شبکه خاص می‌تواند مصرف‌کنندگان دیگر را خراب کند. ابتدا مشخص کنید مشکل از انتخاب رابط است یا از ثبت نشانی اشتباه. آزمون از دو محل شبکه متفاوت، اغلب این تفاوت را سریع آشکار می‌کند.
حساب خودکار و اعتبارنامه محدود
اسکریپت‌های روزمره نباید بی‌دلیل با حساب مدیر انسان اجرا شوند. برای عملیات خودکار، هویت و روش اعتبارنامه مناسب با دامنه محدود انتخاب کنید و مالک آن را مشخص سازید. بسته به امکانات نسخه، سازوکارهایی مانند اعتبارنامه کاربردی می‌توانند برای برخی سناریوها مناسب باشند، اما محدودیت‌ها و چرخه لغو آنها باید از مستندات همان نسخه خوانده شود. هدف این است که توقف یک کار یا افشای یک راز، همه دسترسی مدیریتی سازمان را درگیر نکند.
در آزمایش چرخش اعتبارنامه، کار موفق عادی، اعتبارنامه منقضی یا لغوشده و تلاش برای عملیات خارج از نقش را بررسی کنید. خطای احراز هویت نباید باعث شود اسکریپت با حساب پرقدرت دیگری به طور پنهانی ادامه دهد. گزارش باید شکست را روشن نشان دهد و مالک بتواند علت را اصلاح کند. همچنین راز را در آرگومان‌های قابل مشاهده فرایند یا خروجی عمومی قرار ندهید و روش توزیع آن را با سیاست محیط هماهنگ کنید.
یک مسیر عیب‌یابی منظم
اگر درخواست شکست خورد، ابتدا مرحله را پیدا کنید: دریافت توکن، انتخاب نشانی، اتصال شبکه یا ارزیابی عملیات در سرویس. سپس شناسه درخواست را در گزارش همان مؤلفه دنبال کنید. خطای اتصال به سرویس ذخیره‌سازی با خطای نقش در Keystone یکسان نیست. در مرحله مجوز، دامنه مؤثر و سیاست سرویس را با هم ببینید. افزودن نقش مدیر برای هر خطا ممکن است مشکل واقعی را پنهان کند و دسترسی بیش از نیاز بسازد.
برای نگهداری بلندمدت، فهرست پروژه‌های بدون مالک، کاربران غیرفعال و تخصیص‌های قدیمی را بازبینی کنید. پیش از حذف، وابستگی کارهای خودکار و مالکیت منابع را بررسی کنید تا پاک‌سازی هویت به رها شدن منابع یا شکست کار حیاتی منجر نشود. خروجی بازبینی باید یک تصمیم قابل اجرا باشد: حفظ با مالک مشخص، کاهش دسترسی یا حذف برنامه‌ریزی‌شده. این چرخه است که مدل Domain، Project و Role را به کنترل عملی دسترسی تبدیل می‌کند.
