السحابة المتعددة: Azure وGCP

أساسيات Google Cloud Platform

18 دقيقة الدرس 5 من 28

أساسيات Google Cloud Platform

تم تصميم Google Cloud Platform حول تسلسل هرمي للموارد يختلف اختلافًا جوهريًا عن AWS وAzure. قبل أن تلمس أي آلة افتراضية أو حاوية تخزين، تحتاج إلى استيعاب مفاهيم المؤسسات (Organizations)، والمجلدات (Folders)، والمشاريع (Projects)، وإدارة الهوية والوصول (IAM) — لأن الخطأ في هذه المرحلة يسبب فوضى في الصلاحيات وإخفاقات في المراجعة ومفاجآت في الفواتير يصعب التراجع عنها على نطاق واسع. يمنحك هذا الدرس النموذج الذهني الذي يستخدمه مهندسو Google SRE والعملاء المؤسسيون منذ اليوم الأول.

التسلسل الهرمي للموارد في GCP

كل مورد في GCP ينتمي إلى مشروع (Project) واحد بالضبط. المشاريع هي الوحدة الأساسية للملكية: فهي تحمل حساب الفوترة الخاص بها، وتفعيل واجهات API، وسياسات IAM. فوق المشاريع توجد المجلدات (Folders) (اختيارية، لكنها ضرورية على النطاق المؤسسي)، والتي تجمع المشاريع في وحدات أعمال أو بيئات. في الجذر توجد المؤسسة (Organization) — المرتبطة بنطاق Google Workspace أو Cloud Identity، وهي مطلوبة لأي نشر جاد في الإنتاج.

التسلسل الهرمي ليس مجرد تنظيم — إنه الآلية التي يعمل بها توارث سياسات IAM. الدور الممنوح على مجلد ينتقل تلقائيًا إلى كل مشروع بداخله. والدور الممنوح على المؤسسة ينتقل إلى كل شيء تحته. هذا التوارث من الأعلى إلى الأسفل هو الآلية الأساسية التي تستخدمها الشركات على نطاق Google لتطبيق مبدأ الحد الأدنى من الصلاحيات دون إدارة مئات السياسات الفردية.

التسلسل الهرمي لموارد GCP — سياسات IAM المحددة على مستوى أعلى تُطبَّق تلقائيًا على جميع الموارد الفرعية أدناه.

معرّفات المشاريع عالمية الفرادة وغير قابلة للتغيير. عند إنشاء مشروع، يمنحه GCP معرّف مشروع (Project ID) (مثل api-prod-8a3f) لا يمكن تغييره أبدًا وهو فريد عبر كل GCP. اسم المشروع مقروء بشريًا ويمكن تغييره. احرص دائمًا على اشتقاق معرّف المشروع من نمط مثل {الفريق}-{البيئة}-{رمز-قصير} — ولا تعتمد على الأسماء المُوَلَّدة تلقائيًا في البنية التحتية كرمز (IaC).

إعداد التسلسل الهرمي باستخدام gcloud

عمليًا، يتم توفير المؤسسات والمجلدات عبر Google Cloud Console أو Terraform — فهي تتطلب التحقق من النطاق وتفعيل واجهة resourcemanager.googleapis.com API. أما المشاريع فهي وحدة التشغيل اليومية وتُنشأ بشكل متكرر. أداة gcloud هي الأداة الرسمية.

# المصادقة وتعيين مشروع افتراضي
gcloud auth login
gcloud config set project api-prod-8a3f

# سرد معرّف المؤسسة (مطلوب لإنشاء المجلدات/المشاريع على مستوى المؤسسة)
gcloud organizations list

# إنشاء مجلد تحت المؤسسة (يتطلب resourcemanager.folders.create)
gcloud resource-manager folders create \
  --display-name="Engineering" \
  --organization=123456789012

# إنشاء مجلد فرعي تحت Engineering (استخدم معرّف المجلد من المخرجات السابقة)
gcloud resource-manager folders create \
  --display-name="Production" \
  --folder=987654321098

# إنشاء مشروع داخل مجلد Production
gcloud projects create api-prod-8a3f \
  --name="API Service Production" \
  --folder=111222333444

# ربط حساب فوترة بالمشروع الجديد (إلزامي قبل أي موارد)
gcloud billing projects link api-prod-8a3f \
  --billing-account=XXXXXX-YYYYYY-ZZZZZZ

# تفعيل واجهات API المطلوبة في المشروع الجديد
gcloud services enable \
  compute.googleapis.com \
  container.googleapis.com \
  secretmanager.googleapis.com \
  --project=api-prod-8a3f

ربط حساب الفوترة ليس اختياريًا. المشروع غير المرتبط بحساب فوترة لا يستطيع إنشاء معظم الموارد المدفوعة — لكنه يستطيع إنشاء سياسات IAM وتفعيل واجهات API، مما قد يؤدي إلى أخطاء محيّرة لاحقًا. احرص دائمًا على ربط الفوترة كجزء من تهيئة المشروع. في Terraform، استخدم مورد google_billing_project_info مباشرةً بعد google_project.

IAM في GCP: كيف يختلف عن AWS وAzure

يستخدم GCP IAM ثلاثة مفاهيم: الأعضاء (Members)، والأدوار (Roles)، والروابط (Bindings). يُرفق الرابط دورًا بعضو على مورد محدد. يمكن أن يكون الأعضاء حسابات Google، أو حسابات خدمة، أو مجموعات Google، أو نطاقات Cloud Identity، أو الرئيسيين الخاصين allUsers / allAuthenticatedUsers.

أهم ما يميّز GCP عن AWS: لا توجد في GCP سياسات مضمّنة (inline policies). هناك فقط أدوار محددة مسبقًا (تديرها Google)، وأدوار أساسية (Owner/Editor/Viewer — لا تستخدمها في الإنتاج أبدًا)، وأدوار مخصصة (دقيقة، على مستوى المؤسسة أو المشروع). كل فحص للصلاحيات تراكمي: سياسات الرفض موجودة لكنها ميزة متقدمة؛ والإعداد الافتراضي هو السماح بغياب الرفض، بمعنى أن المبدأ الذي لا يملك أي رابط لا يملك أي وصول.

نموذج ربط IAM في GCP — يحصل العضو على دور في نطاق محدد؛ والنطاقات الأعلى تتوارث إلى الأسفل.

IAM عمليًا: حسابات الخدمة وWorkload Identity

في GCP، تتحقق التطبيقات من هويتها كـحسابات خدمة (Service Accounts) — هويات خاصة تمثل حمل العمل وليس إنسانًا. على عكس أدوار AWS IAM (التي يُفترض بها عبر STS)، فإن حسابات خدمة GCP هي موارد: لها عنوان بريد إلكتروني خاص بها (name@project-id.iam.gserviceaccount.com) ويمكن منحها أدوارًا تمامًا مثل أي مستخدم.

# إنشاء حساب خدمة لمشغّل CI
gcloud iam service-accounts create ci-runner \
  --display-name="CI/CD Runner" \
  --project=api-prod-8a3f

# منحه دور Container Developer على المشروع
gcloud projects add-iam-policy-binding api-prod-8a3f \
  --member="serviceAccount:ci-runner@api-prod-8a3f.iam.gserviceaccount.com" \
  --role="roles/container.developer"

# منحه Secret Accessor على سرّ محدد (ربط على مستوى المورد — مُفضَّل)
gcloud secrets add-iam-policy-binding db-password \
  --project=api-prod-8a3f \
  --member="serviceAccount:ci-runner@api-prod-8a3f.iam.gserviceaccount.com" \
  --role="roles/secretmanager.secretAccessor"

# عرض سياسة IAM الكاملة على المشروع (راجعها بانتظام)
gcloud projects get-iam-policy api-prod-8a3f --format=yaml

Workload Identity Federation بدلًا من مفاتيح حسابات الخدمة: لا تقم أبدًا بتنزيل ملفات مفاتيح JSON لحسابات الخدمة للأحمال التي تعمل داخل GCP (GKE، Cloud Run، Compute Engine). بدلًا من ذلك، أرفق حساب الخدمة بالمورد مباشرةً — يتولى خادم البيانات الوصفية تجديد بيانات الاعتماد تلقائيًا. بالنسبة لـGitHub Actions أو CI الخارجي، استخدم Workload Identity Federation (تبادل رمز OIDC) بدلًا من مفتاح ثابت. المفاتيح الثابتة هي أحد أكثر أسباب حوادث أمان GCP شيوعًا — تأتي ضمن الأسباب الخمسة الأولى.

قيود السياسة على مستوى المؤسسة

إلى جانب IAM، يوفر GCP قيود سياسة المؤسسة (Organization Policy constraints) — ضمانات تُفرض على مستوى المؤسسة أو المجلد وتتجاوز الإعدادات على مستوى المشروع. تشمل القيود الشائعة في الإنتاج: تعطيل عناوين IP العامة على الآلات الافتراضية (compute.vmExternalIpAccess)، وتقييد المناطق التي يمكن إنشاء الموارد فيها (gcp.resourceLocations)، وطلب تسجيل الدخول عبر OS Login (compute.requireOsLogin). يُفرض ذلك حتى لو حاول مالك المشروع تجاوزه — وهو أمر حيوي للامتثال والتحكم في التكاليف على نطاق واسع.

فكّر في سياسات المؤسسة كما تفكر في SCPs في AWS أو تعيينات Azure Policy. إنها ضوابط وقائية — حتى المالك (Owner) لا يستطيع انتهاكها. حددها على مستوى المجلد للقواعد الخاصة بالبيئة (مثل: لا IPs خارجية في الإنتاج)، وعلى مستوى المؤسسة للولايات الشاملة (مثل: تقييد المناطق الأوروبية لامتثال GDPR). عرّفها في Terraform منذ اليوم الأول لتكون خاضعة للتحكم في الإصدارات وقابلة للمراجعة.

أنماط الإخفاق في بيئات الإنتاج

أكثر أخطاء GCP IAM شيوعًا في الإنتاج: منح roles/editor لحساب خدمة بدلًا من الأدوار المحددة مسبقًا ذات النطاق الضيق؛ وإنشاء جميع الموارد في مشروع واحد بدلًا من فصل البيئات؛ وغياب ربط حسابات الفوترة الذي يسبب إخفاقات صامتة في واجهات API؛ والاعتماد على ملفات مفاتيح حسابات الخدمة التي تُجدَّد يدويًا أو لا تُجدَّد أبدًا. التسلسل الهرمي المصمم جيدًا في GCP مع Workload Identity، وأدوار محددة مسبقًا بأقل صلاحيات، وقيود سياسة المؤسسة، يلغي غالبية هذه الحوادث قبل أن تصل إلى الإنتاج.