Node Control Grants و Bounded Automation

1. Authentication با Authorization یکی نیست

اینکه Coordinator یا اپراتور با موفقیت احراز هویت شده، فقط می‌گوید «چه کسی» درخواست را فرستاده است؛ نمی‌گوید این actor مجاز است هر actionای را روی هر node و با هر parameter اجرا کند. در LOC-013 خروجی اصلی Node Control Grant & Action Authorization Ledger v1 است: رکوردی صریح که actor، نسل identity، node هدف، action مجاز، scope، زمان اعتبار، generation و revocation را کنار درخواست واقعی قرار می‌دهد.

2. مرز مالکیت LOC-013

این درس فقط authorization برای action محلی را مالک است. محدودیت CPU/memory/I/O متعلق به LOC-014 و sleep/shutdown/Wake-on-LAN متعلق به LOC-015 است. Grant می‌تواند اجازه‌ی worker.restart بدهد، اما خودش درباره‌ی resource budget یا امکان سخت‌افزاری wake تصمیم نمی‌گیرد. این separation جلوی authority پنهان و تصمیم‌های غیرقابل ممیزی را می‌گیرد.

3. Grant باید content-bound باشد

Grant خوب یک token مبهم با نقش «admin» نیست. حداقل باید grant_id، grant_generation، actor_identity، actor_generation، target_node_id، action_allowlist، resource_scope، parameter_scope، condition_set، not_before و expires_at را ثبت کند. هرچه request مهم‌تر است، binding باید مشخص‌تر باشد. اگر request از این مرزها بزرگ‌تر شود، باید رد شود نه اینکه scope به‌صورت خودکار widen شود.

4. RFC 9396 یک الگوی مفید برای مجوز fine-grained است

RFC 9396 در OAuth Rich Authorization Requests، authorization_details را برای بیان نیازهای مجوز دقیق‌تر تعریف می‌کند و برای type یا field نامعتبر الزام به خطا دارد. از این ایده برای discipline طراحی استفاده می‌کنیم: درخواست authorization باید ساختارمند و قابل اعتبارسنجی باشد. اما این RFC transport یا policy داخلی MAKNOW را تعریف نمی‌کند.

5. Allowlist باید از request واقعی جدا باشد

در Ledger، «چیزی که grant اجازه می‌دهد» را از «چیزی که request می‌خواهد» جدا نگه دارید. اگر allowlist فقط worker.restart دارد و request برابر node.shutdown است، نتیجه DENY است حتی اگر actor مدیر سیستم باشد. Ambient authority نباید grant را silently گسترش دهد.

6. Target node یک boundary مستقل است

Grant برای node-A نباید روی node-B معتبر تلقی شود. actor می‌تواند درست باشد، action هم در allowlist باشد، اما target mismatch به‌تنهایی برای DENY کافی است. این تفکیک مخصوصاً در fleet automation مهم است، چون اشتباه در routing می‌تواند یک grant سالم را روی دستگاه اشتباه اجرا کند.

7. Resource و parameter scope را صریح نگه دارید

Action ممکن است درست باشد ولی parameterها خارج از scope باشند. مثال: grant اجازه‌ی restart سرویس worker-alpha را می‌دهد اما request می‌خواهد تمام serviceهای node restart شوند. resource_scope و parameter_scope باید independently match شوند. «نام command درست است» دلیل کافی برای اجازه نیست.

8. Lifetime و generation را هم‌زمان بررسی کنید

issued_at، not_before و expires_at مرز زمانی grant هستند. grant_generation و actor_generation نیز جلوی استفاده از authority قدیمی بعد از rotation را می‌گیرند. grantی که هنوز از نظر clock منقضی نشده می‌تواند به‌دلیل generation جدید یا revocation دیگر معتبر نباشد. زمان و نسل دو evidence جدا هستند.

9. Revocation باید fail-closed باشد

اگر generation هفت revoke شده است، cached request با همان generation نباید فقط چون expires_at هنوز نرسیده اجرا شود. revocation_state باید پیش از ALLOW بررسی شود و event ردشدن در audit ثبت شود. Reauthorization مسیر درست recovery است؛ bypass کردن revocation نیست.

10. One-shot و replay را از ابتدا طراحی کنید

برای actionهای حساس، grant می‌تواند one-shot باشد و grant_nonce داشته باشد. پس از consumption، replay همان nonce باید رد شود. برای automation دوره‌ای، به‌جای reuse مبهم یک one-shot grant، یک grant renewable یا grant generation جدید با policy روشن تعریف کنید. Idempotency برنامه با authorization replay یکی نیست.

11. Condition set بخشی از مجوز است

Grant می‌تواند شرط داشته باشد: maintenance window باز باشد، node در group مشخص باشد، یا ticket/change record معتبر وجود داشته باشد. اگر شرط تعیین‌کننده UNKNOWN است، نتیجه را ALLOW نکنید؛ DEFER یا UNKNOWN را حفظ کنید و recheck trigger بدهید. Missing evidence همان false نیست، اما success هم نیست.

12. Denial reason باید قابل ممیزی باشد

DENY فقط یک boolean نیست. denial_reason باید دقیق باشد: EXPIRED_GRANT، WRONG_NODE، WRONG_ACTION، SCOPE_MISMATCH، REVOKED_GRANT، ACTOR_GENERATION_MISMATCH یا مشابه. audit_event نیز grant id/generation، request و timestamp ارزیابی را نگه می‌دارد تا retry و incident review قابل بازسازی باشد.

13. مثال کارشده: restart محدود

فرض کنید actor ops-bot/v12 برای node-17 grant generation 8 دارد. Allowlist فقط worker.restart است، scope فقط worker-alpha و parameter برابر mode=safe است؛ grant از 20:00 تا 20:20 معتبر و revocation=ACTIVE است. Request در 20:07 دقیقاً همان node/action/scope را می‌خواهد؛ نتیجه ALLOW است. اگر همان request به node-18 route شود، actor همچنان معتبر است اما نتیجه DENY / WRONG_NODE می‌شود.

14. Failure Probeهای تعیین‌کننده

چهار shortcut را رد کنید: (1) actor+node درست ولی grant منقضی → DENY/EXPIRED_GRANT؛ (2) grant current ولی node اشتباه → DENY/WRONG_NODE؛ (3) grant فقط restart ولی request shutdown → DENY/WRONG_ACTION؛ (4) grant generation revoke شده ولی cache هنوز آن را دارد → DENY/REVOKED_GRANT. Lab expected labelها را به learner نشان نمی‌دهد.

15. Transfer به maintenance زمان‌بندی‌شده

همان contract را از restart تعاملی به automation زمان‌بندی‌شده ببرید. Trigger تغییر می‌کند و شاید grant از one-shot به renewable تبدیل شود، اما actor/node/action/scope/lifetime/revocation invariantها باقی می‌مانند. baseline decision را کپی نکنید؛ زمان اجرا، generation فعلی، condition set و revocation را در هر evaluation دوباره بسازید. Automation bounded یعنی authority همیشه از evidence جاری کوچک‌تر یا مساوی است، نه از ambient privilege بزرگ‌تر.