دسکتاپ، Worker و محاسبات محلی · فصل ۱ — Device Identity، Tauri، Tray و Admin CLI · 178
Headless Admin CLI و Break-glass Access
اپ یا worker محلی را اجرا می‌کند اما device identity، privilege، offline state و fleet behavior را طراحی نکرده است. موضوع جاری: «Headless Admin CLI و Break-glass Access». می‌تواند «Headless Admin CLI و Break-glass Access» را برای یک node محلی با identity، state، privilege و recovery boundary مناسب طراحی کند.
خلاصهٔ درس
اپ یا worker محلی را اجرا می‌کند اما device identity، privilege، offline state و fleet behavior را طراحی نکرده است. موضوع جاری: «Headless Admin CLI و Break-glass Access».
می‌تواند «Headless Admin CLI و Break-glass Access» را برای یک node محلی با identity، state، privilege و recovery boundary مناسب طراحی کند.
خروجی این درس
می‌تواند «Headless Admin CLI و Break-glass Access» را برای یک node محلی با identity، state، privilege و recovery boundary مناسب طراحی کند.
1. مسئله: وقتی GUI نیست، کنترل نباید به یک Backdoor تبدیل شود
فرض کنید Tray و پنجره‌ی دسکتاپ بعد از یک تنظیم خراب بالا نمی‌آیند اما Worker Service هنوز در حال اجراست. تیم عملیات به مسیر Headless برای مشاهده‌ی وضعیت و یک Recovery محدود نیاز دارد. راه‌حل خطرناک، یک فلگ مثل --force-admin است که همه‌ی کنترل‌ها را کنار می‌زند. هدف این درس ساختن یک CLI بازیابی است که حتی در شرایط اضطراری هم «هر کاری مجاز است» معنی ندهد.
2. مرز مالکیت: این درس دقیقاً چه چیزی را کنترل می‌کند
LOC-005 فقط Control Plane محلیِ Headless را مالک است: تعریف Command، Effect Class، Scope، مسیر عادی مجوزدهی، Break-glass محدود، Expiry/Revocation، Confirmation و Audit. هویت پایه‌ی Node و Device، Capability/CSP، Tray behavior و OS Service lifecycle در درس‌های مجاور قرار دارند و نباید اینجا دوباره تعریف شوند.
3. Command را قبل از Authorization طبقه‌بندی کنید
هر Command باید یک نام پایدار و Effect Class صریح داشته باشد. حداقل سه دسته مفیدند: DIAGNOSTIC_READ_ONLY، RECOVERY_STATE_CHANGE و DESTRUCTIVE_OR_HIGH_RISK. طبقه‌بندی قبل از تصمیم دسترسی انجام می‌شود تا Emergency mode نتواند ماهیت یک فرمان مخرب را پنهان کند.
4. Read-only با State-changing یک Gate یکسان ندارد
مشاهده‌ی Health یا اعتبارسنجی Config می‌تواند با مسیر محلیِ عادی و کم‌اختیار انجام شود، اگر AuthN/AuthZ و Scope معتبر باشند. Rollback، Rotation یا هر تغییر State باید Evidence قوی‌تر، Confirmation و Audit کامل داشته باشد. «CLI بودن» مجوز اضافه ایجاد نمی‌کند.
5. مسیر عادی همیشه اولویت دارد
اگر Normal Admin Path در دسترس و معتبر است، همان مسیر باید استفاده شود. Break-glass جایگزین دائمی Login یا Authorization عادی نیست. حتی وقتی UI خراب است، یک AuthN محلی معتبر و یک Scope عادی می‌تواند برای Commandهای تشخیصی کافی باشد؛ بنابراین برای هر مشکل کوچک نباید Emergency mode فعال شود.
6. Break-glass یک Record محدود است، نه یک Superuser Flag
رکورد اضطراری باید Actor، Reason، Approval Reference، Scopeهای مجاز، زمان Activation و Expiry را مشخص کند. فعال‌بودن این Record فقط یک مسیر Authorization جایگزین ایجاد می‌کند؛ هیچ Commandی بدون بررسی break_glass_eligible و Scope خودش مجاز نمی‌شود.
7. Local AuthN و Local AuthZ را جدا نگه دارید
در outage ممکن است Identity Provider مرکزی در دسترس نباشد، اما این به معنی اعتماد خودکار به User محلی نیست. local_authn_state باید هویت ارائه‌شده را تأیید کند و local_authz_state باید نشان دهد Actor برای نقش موردنیاز مجاز است. STALE، UNKNOWN یا DENIED نباید به PASS تبدیل شوند.
8. Expiry و Revocation بخشی از تصمیم زمان اجرا هستند
Approval قدیمی کافی نیست. در لحظه‌ی اجرای فرمان باید زمان فعلی با expires_at مقایسه شود و Revocation نیز بررسی شود. اگر رکورد منقضی یا لغو شده است، Action باید با State تایپ‌شده‌ی EXPIRED یا REVOKED متوقف شود و نیاز به رکورد جدید داشته باشد.
9. Scope اضطراری باید از Local Administrator باریک‌تر باشد
یک Break-glass واقعی بهتر است فقط چند Recovery Action مشخص مثل Rollback کنترل‌شده یا Rotation یک Credential محلیِ آسیب‌دیده را پوشش دهد. درخواست نامرتبط مثل Purge داده، حذف Log یا تغییر گسترده‌ی Policy حتی در Emergency mode باید DENIED بماند.
10. Confirmation برای اثرهای برگشت‌ناپذیر یا حساس
برای State-changing Command باید قبل از Effect، خلاصه‌ی دقیق Target، Scope و Consequence نمایش داده و Confirmation صریح ثبت شود. Confirmation جای AuthN/AuthZ را نمی‌گیرد؛ فقط یک Gate اضافی برای جلوگیری از اجرای اشتباه روی Action مجاز است.
11. Audit باید قبل و بعد از Effect قابل پیوند باشد
هر اجرای Admin Command باید یک audit_event_id پایدار داشته باشد که Actor، Command، Scope، Authority Path، Reason، Approval، زمان‌ها و نتیجه را به هم وصل کند. اگر Action بدون Audit binding اجرا شود، نتیجه‌ی قابل حسابرسی نداریم و State باید UNBOUND بماند.
12. Post-event Review پایان واقعی Break-glass است
بعد از بازگشت سرویس هویت عادی، Emergency authority باید Revoked شود و Review ثبت کند چه چیزی اجرا شد، چرا، با کدام Evidence و آیا Follow-up لازم است. بستن Incident بدون این مرحله، Break-glass را به یک استثنای فراموش‌شده تبدیل می‌کند.
13. Fail-closed یعنی Stateهای ضعیف را حفظ کنیم
در این درس DENIED، DEFER، DEGRADED، EXPIRED، REVOKED و UNBOUND خطاهای مبهم نیستند؛ هرکدام دلیل عملیاتی مشخص دارند. اگر AuthN قدیمی است، Approval گم شده، Scope نمی‌خواند یا Audit ID وجود ندارد، سیستم نباید با یک Boolean ساده‌ی «موفق» ادامه دهد.
14. Lab: Headless Admin CLI & Break-glass Control Record v1
هشت Fixture مصنوعی دارید. باید برای هر مورد Authority Path، Scope State، Time State، Audit State، Break-glass State، Action State و تصمیم نهایی را بسازید. Expected labels در Learner package قرار ندارند. هیچ Credential واقعی، تغییر OS یا دسترسی شبکه لازم نیست؛ هدف فقط Evidence reasoning و Gateهای Deterministic است.
15. Transfer و خروج فصل: Emergency را ببندید، نه اینکه عادی‌اش کنید
در Transfer فرض کنید Identity Service بعد از Recovery برمی‌گردد. فرمان‌های بعدی باید دوباره از Normal Admin Path عبور کنند، Emergency authority لغو شود و Post-event Review ثبت شود. خروج C01 زمانی معتبر است که Headless recovery بدون GUI قابل انجام باشد اما هیچ «مسیر جادوییِ همیشه‌ادمین» باقی نماند.
ارزیابی
پاسخ‌نامه‌ی این درس در بسته‌ی آموزش وجود ندارد؛ خودت جواب بده و صادقانه علامت بزن. «نیاز به مرور» درس را به صف تکرار می‌فرستد.
Q1 boundary
Name the exact control-plane boundary owned by LOC-005 and one adjacent concern it does not own.
Q2 classification
Classify status.health, config.rollback_one, and data.purge by effect class before considering authorization.
Q3 application
Given a valid local normal path and an unavailable GUI, decide whether a read-only health command needs break-glass and justify the evidence.
Q4 diagnosis
An emergency record is active but the requested command is outside its allowed scopes. What typed decision should the control plane preserve and why?
Q5 time
Explain what must happen if the emergency record expires after approval but before execution.
Q6 audit
Why is a missing audit_event_id a control failure even if authentication and scope are otherwise valid?
Q7 transfer
After the identity service returns, describe the sequence that restores normal authorization and closes the emergency episode.
Q8 reflection
State the strongest claim this synthetic lab can support and one claim it cannot support about a real production node.
ملاک‌های ارزیابی (rubric)
A satisfactory submission must demonstrate all five critical dimensions:
- Identity and boundary — the LOC-005 control-plane boundary is explicit and adjacent lessons are not absorbed.
- Exact evidence binding — command, actor, AuthN/AuthZ, scope, emergency reason/approval, time state, confirmation, and audit evidence are bound to the decision.
- Negative and uncertain states — at least one scope denial and one stale/expired/revoked/unbound state remain typed instead of being coerced into success.
- Bounded decision — a state-changing action is never authorized only because break-glass is active; confirmation and audit remain required.
- Transfer — when normal identity service returns, emergency authority is revoked and post-event review closes the episode.
A response fails the lesson outcome if it introduces a universal force-admin bypass, treats a single identity label as full authorization, ignores expiry/revocation, or exposes expected fixture labels inside learner work.
منابع و تازگی
مطالعهٔ موارد (case studies)
فایل‌های آزمایشگاه
Implement an evaluator for the eight synthetic fixtures. Keep the normal authorization path separate from emergency authorization, preserve expiry/revocation/stale/unbound states, and require command scope plus audit evidence.
The lab does not use real credentials, network access, operating-system privilege changes, or destructive effects. The transfer case restores the normal identity path and closes the emergency episode with post-event review.