‏مدیریت RBAC با Terraform روی AWS، Azure و GCP

RBAC (Role-Based Access Control) یعنی تعریف مجموعه‌ای از مجوزها به‌شکل «نقش» و اختصاص اون نقش به یه هویت خاص (کاربر، گروه یا سرویس‌اکانت) روی یه محدوده مشخص (scope). محدوده می‌تونه یه ریسورس منفرد باشه یا کل یه سازمان. هر چی scope بالاتر باشه، دسترسی گسترده‌تره. Terraform این امکان رو می‌ده که همه این تنظیمات رو به‌صورت کد declarative بنویسی و در کنار بقیه زیرساخت نگه‌داری کنی.

مزایای اصلی این رویکرد اینه که همه محیط‌ها (dev، staging، production) یه مدل دسترسی یکسان دارن، تغییرات از طریق pull request بررسی می‌شن، rollback سریعه، خطای انسانی کمتره و ممیزی‌های امنیتی راحت‌تر انجام می‌شن. کنار RBAC، مفهوم ABAC (Attribute-Based Access Control) هم وجود داره که دسترسی رو بر اساس تگ‌های منابع (مثلاً ManagedBy = Terraform) کنترل می‌کنه.

Azure: روی Azure نقش‌ها با azurerm_role_assignment به هویت‌ها اختصاص می‌یابن. مثلاً برای دادن دسترسی خواندن blob به یه managed identity:

resource "azurerm_role_assignment" "storage_blob_data_reader" {
  scope                = data.azurerm_subscription.current.id
  role_definition_name = "Storage Blob Data Reader"
  principal_id         = azurerm_user_assigned_identity.spacelift.principal_id
}

اگه نقش‌های built-in کافی نبودن، می‌شه با azurerm_role_definition یه نقش سفارشی تعریف کرد. این نقش می‌تونه actions (مجوزهای management plane مثل خواندن/نوشتن ریسورس) و data_actions (مجوزهای data plane مثل خواندن blob) داشته باشه. با not_actions و not_data_actions هم می‌شه از یه مجموعه گسترده، مجوزهای خاصی رو حذف کرد.

Google Cloud: روی GCP سه نوع نقش داریم: Basic (گسترده)، Predefined (دانه‌درشت برای کارهای خاص) و Custom (تعریف‌شده توسط کاربر). نقش‌ها به service account، کاربر یا گروه اختصاص می‌یابن. منابعی که از تخصیص نقش پشتیبانی می‌کنن، نوع *_iam_member متناظر دارن — مثلاً google_project_iam_member برای سطح پروژه یا google_storage_bucket_iam_member برای یه باکت خاص. نقش‌های سفارشی با google_project_iam_custom_role ساخته می‌شن و یه فیلد stage دارن که نشون می‌ده نقش در چه مرحله‌ای از چرخه عمره (مثلاً GA برای Generally Available).

AWS: روی AWS مدل کمی متفاوته. سیاست‌های IAM (IAM Policy) تعریف می‌کنن چه عملیاتی روی چه ریسورس‌هایی مجازه، بعد به IAM Role وصل می‌شن. هر Role یه «trust policy» داره که مشخص می‌کنه کدوم principal می‌تونه اون نقش رو assume کنه. این مدل انعطاف بیشتری می‌ده چون می‌شه یه نقش واحد رو بین چند سرویس یا حساب مشترک کرد.

نکات کلیدی:

• RBAC = نقش (مجموعه مجوزها) + هویت + محدوده (scope)
• Terraform اجازه می‌ده RBAC رو به‌صورت کد نسخه‌بندی‌شده و قابل بازبینی مدیریت کنی
• Azure از azurerm_role_assignment و azurerm_role_definition استفاده می‌کنه
• GCP از منابع *_iam_member برای تخصیص نقش استفاده می‌کنه
• AWS روی ترکیب IAM Policy + IAM Role + trust policy کار می‌کنه
• اصل least-privilege رو رعایت کن: فقط مجوزهای واقعاً لازم رو بده
• ترکیب RBAC با policy as code یه لایه دفاعی چندسطحی می‌سازه