GCP למהנדסי AWS: כיצד האינסטינקטים שלכם מ-AWS מתורגמים (והיכן הם נשברים)

אם אתם שולטים ב-AWS וכעת מביטים ב-Google Cloud, החדשות הטובות הן שכ-80% מהאינסטינקטים שלכם עוברים ישירות: יש היררכיה לארגון דברים, דרך מבוססת תפקידים להענקת גישה, סיפור OIDC עבור CI ללא מפתחות, ו- "אתחול קר של ה-state backend" (cold-start your state backend) ריקוד אתחול. החדשות הרעות הן 20% הנותרים - והם מרוכזים בכמה נקודות עמוסות שבהן ביצוע הדבר ה"AWS-י" מייצר הכחשה מבלבלת במקום שגיאה ברורה. פוסט זה הוא שכבת התרגום: אותן עבודות שאתם עושים ב-AWS, מבוצעות ב-GCP, עם המלכודות שצוינו.

הגרסה הקצרה, אם אתם קוראים רק פסקה אחת: ההיררכיה של GCP (organization -> folder -> project -> resource) מתורגמת בצורה נקייה ל-AWS Organizations -> OU -> account -> resource, אך שלושה דברים שוברים את זיכרון השריר שלכם. IAM הוא מדיניות "אפשר בלבד" (allow-only) הקשורה לעץ המשאבים ויורדת כלפי מטה - אין מדיניות המצורפת למשתמש. ה-APIs של השירותים בפרויקט מתחילים כולם כבויים, ושום דבר לא עובד עד שתפעילו כל אחד מהם. ואתם לא מבצעים assume roles, אתם מתחזים ל-service accounts, שהם עצמם משאבים עם מדיניות גישה משלהם. כל מה שלמטה מרחיב את אלה.

השינוי הגדול ביותר: הרשאות חיות על העץ, לא על זהויות

ב-AWS, המודל המנטלי הוא "צרף מדיניות לזהות". אתם יוצרים user או role, מצמידים אליו JSON, ו- ההרשאה עוברת עם ה-principal. מדיניות משאבים קיימת, אך המדיניות המצורפת לזהות היא מרכז הכובד.

GCP הופך את זה. מדיניות IAM היא קבוצה של bindings - זוגות (member, role) - המצורפים לצומת בהיררכיית המשאבים (organization, folder, project, או משאב בודד). המדיניות חיה על הדבר שאליו ניגשים, לא על הזהות שמבצעת את הגישה. הגישה האפקטיבית שלכם בכל נקודה היא האיחוד של כל binding שעבר בירושה מהשורש ועד לצומת זה. העניקו roles/compute.admin לקבוצה ברמת ה-folder וכל project תחת אותו folder יורש אותה.

אם נגעתם ב-Azure RBAC זה ירגיש מוכר - זה role-at-a-scope עם ירושה כלפי מטה. הכלל שיציל אתכם:

כאשר GCP מכחיש משהו, הפסיקו לחפש "את המדיניות על המשתמש". חפשו את ה-binding על ה-org, folder, project, או resource - וזכרו שהוא יורש למטה, כך שההענקה החשובה עשויה להיות שלוש רמות למעלה.

כמה פרטים ספציפיים השונים מ-AWS:

• תפקידים מגיעים בשלוש דרגות. תפקידים פרימיטיביים (roles/owner, roles/editor, roles/viewer) הם השלישייה הישנה והגסה - הימנעו מהם בסביבות אמיתיות. תפקידים מוגדרים מראש (Predefined) הם התפקידים המפורטים לכל שירות שאתם אמורים להשתמש בהם בפועל (roles/storage.objectViewer, roles/compute.instanceAdmin.v1, ...). תפקידים מותאמים אישית (Custom) הם שלכם ליצור כאשר הסט המוגדר מראש רחב מדי.
• המודל הבסיסי הוא תוספתי ו"אפשר בלבד" (allow-only). אין Effect: Deny לכל statement השזור בכל מדיניות כפי שיש ב-AWS. גישה אפקטיבית היא פשוט איחוד של allows.
• Deny הוא שכבה נפרדת. כאשר אתם כן זקוקים ל"לעולם לא, ללא קשר להרשאות," אתם כותבים IAM deny policy - אובייקט נפרד המצורף ל-org/folder/project המוערך לפני allows. זה הדבר הקרוב ביותר ל-Deny statement inline, אך הוא בכוונה מחוץ לתחום.
• Guardrails הם דבר שלישי שוב: ה-Organization Policy Service. אילוצים כמו constraints/compute.vmExternalIpAccess או constraints/iam.disableServiceAccountKeyCreation הם האנלוג של GCP ל-SCPs. הם מצורפים ברמת ה-org/folder/project, יורשים כלפי מטה, ומגבילים מה יכול להתקיים או להיות מוגדר ולא מי יכול לקרוא למה. חשבו "guardrail בצורת SCP", לא "IAM role".

אז היכן ש-AWS נותן לכם דקדוק אחד של allow/deny בתוך IAM, GCP מפזר את העבודה על פני allow bindings, deny policies, ו- org-policy constraints. אותן תוצאות, שלושה מנגנונים.

הכל הוא project - וה-APIs שלו מתחילים כבויים

ה-project הוא היחידה הבסיסית של GCP. הוא האנלוג הגס של AWS account: גבול בידוד, היקף IAM, ויעד חיוב הכל יחד. אבל project הוא הרבה יותר קל מ-account - זול ליצירה, קל למחיקה, מיועד להיעשות בעשרות. התבנית האידיומטית היא project אחד לכל workload לכל environment (app-qa, app-prod), לא קומץ חשבונות משותפים המחולקים לפי tags.

שלושה דברים לגבי projects שאין להם מקבילה נקייה ב-AWS:

• ל-project יש שלושה מזהים, וההבדלים נושכים. ה- project ID הוא מחרוזת ייחודית גלובלית, שנבחרה על ידי אדם, בלתי ניתנת לשינוי (acme-app-prod-7f3a) - זה מה שאתם מכניסים כמעט לכל פקודה ונתיב משאב. ה- project number הוא מספר שלם ייחודי גלובלית ש-GCP מקצה. ה- display name ניתן לשינוי וקוסמטי. בחרו את ה-ID בזהירות; לעולם לא תוכלו לשנות אותו.
• Service APIs כבויים כברירת מחדל. זוהי ההיתקלות הנפוצה ביותר ביום הראשון. לפני שתוכלו ליצור VM, אתם מפעילים את compute.googleapis.com; לפני bucket, את storage.googleapis.com; וכן הלאה, לכל project. ה- "הכחשה" הראשונה שלכם ב-GCP היא בדרך כלל לא חוסר ב-IAM role כלל - זו API [compute.googleapis.com] not enabled on project. ב-AWS, שירותים פשוט קיימים; ב-GCP, כל project הוא לוח חלק ואתם מפעילים בדיוק את המשטח שאתם מתכוונים להשתמש בו. (ב-Terraform זה google_project_service; מה-CLI, gcloud services enable.)
• Projects הם גבול רדיוס הפיצוץ והמכסה הטבעי. מכסות, תקציבים ורוב ברירות המחדל הם לכל project, כך שלהקים project חדש לניסוי זו הפעולה הרגילה והזולה - לא הטקס ש-AWS account הוא.

Service accounts: אתם מתחזים, אתם לא מבצעים assume

ב-AWS, role הוא קבוצה של הרשאות ש-principal מבצע assume דרך STS, מוגבל על ידי trust policy. ב-GCP ה-workhorse המקביל הוא ה-service account (SA), והוא עובד אחרת באופן שמכשיל כל מהנדס AWS.

Service account הוא גם זהות וגם משאב. יש לו אימייל (deployer@acme-app-prod.iam.gserviceaccount.com), הוא חי בתוך project, ו- - באופן מכריע - יש לו מדיניות IAM משלו הקובעת מי רשאי להשתמש בו. החצי השני הזה הוא החלק שאין לו רפלקס AWS:

• כדי לפעול כ- service account, principal זקוק ל-role על ה-SA עצמו - roles/iam.serviceAccountTokenCreator (כדי ליצור tokens קצרי מועד ולהתחזות אליו) או roles/iam.serviceAccountUser (כדי לצרף אותו למשאב שאתם יוצרים, כמו VM או Cloud Run service). זוהי ההענקה הדו-צדדית שאנשי AWS שוכחים: מתן זכויות project רחבות ל-CI principal שלכם חסר תועלת אם הוא לא יכול להפוך ל-deployer SA.
• אתם מתחזים ל-SA על ידי בקשת token (generateAccessToken), לא על ידי ביצוע assume role עם trust-policy handshake. ההרשאה להתחזות חיה כ-IAM binding רגיל על משאב ה-SA - אין מסמך trust נפרד.
• Service account keys קיימים ואתם צריכים להימנע מהם ברוב המקרים. מפתח JSON שהורד הוא credential ארוך טווח וקטור דליפה קלאסי; ארגונים רבים משביתים יצירת מפתחות ברמת הארגון באמצעות האילוץ שהוזכר קודם. החלופות ללא מפתחות הן אלה שצריך להשתמש בהן.
• Keyless CI הוא Workload Identity Federation - אותו רעיון OIDC כמו OIDC federation של AWS. ה-GitHub Actions שלכם או workload חיצוני מציג OIDC token, workload identity pool בוטח ב-issuer, ו-GCP מחזיר credentials קצרי מועד עבור SA. אין secret מאוחסן. (בתוך GKE, האנלוג הוא Workload Identity, המקשר Kubernetes service account ל-Google service account - המקבילה הישירה של IRSA של AWS.)

התרגום בשורה אחת: AWS role שאתם מבצעים assume דרך trust policy הופך ל-GCP service account שאתם מתחזים אליו דרך token-creator binding על ה-SA.

תחום הזהויות: Cloud Identity, Workspace, וה-org

GCP אכן מפריד זהות ממשאבים, אך בעדינות רבה יותר מאשר Azure. ה-organization node נוצר כנגד domain מאומת שבבעלות חשבון Cloud Identity או Google Workspace. ספרייה זו - users ו-groups - מנוהלת ב-Admin console (admin.google.com), משטח שונה מ-Cloud console שבו אתם מנהלים משאבים.

• Users ו-groups נוצרים בספרייה; גישה ניתנת ב-IAM. אתם לא יוצרים "GCP user" באותה דרך שבה אתם יוצרים IAM user ב-AWS. האדם קיים ב-Cloud Identity/Workspace (או מאוחד מ-IdP שלכם), ואתם מפנים אליו - באופן אידיאלי כ-group - ב-IAM bindings על עץ המשאבים. שיטות עבודה מומלצות הן bindings לקבוצות, לעולם לא למשתמשים בודדים.
• אין "IAM users" store עצמאי כמו שיש ל-AWS. IdPs חיצוניים (Okta, Entra ID, וכן הלאה) מתאחדים ל- Cloud Identity; זו הנורמה לגישת כוח אדם.
• שני "footguns" לזכור: ה-members המיוחדים allUsers (פשוטו כמשמעו כל אחד באינטרנט, לא מאומת) ו- allAuthenticatedUsers (כל אחד עם כל חשבון Google). קישור role לאחד מהם הוא הדרך שבה buckets הופכים בטעות לציבוריים. התייחסו אליהם באותה דרך שבה אתם מתייחסים ל-Principal: "*" במדיניות S3 bucket.

האנלוגיה הרופפת: ה-organization בתוספת ה-Cloud Identity domain שלה היא בערך "AWS Organization המאוחד עם הספרייה של IAM Identity Center" - אך עבודת המשאבים היומיומית מתרחשת באמצעות IAM bindings על העץ, לא באמצעות מדיניות המצורפת לזהות.

חיוב הוא אובייקט נפרד שאתם מקשרים ל-projects

billing account ב-GCP הוא משאב משלו - הוא אינו צומת בהיררכיית org -> folder -> project. Projects מקשרים ל-billing account (כל project לאחד בלבד), ו-billing account יחיד יכול לממן projects רבים.

• יש לו IAM משלו. roles/billing.admin, roles/billing.user, roles/billing.creator חיים על ה-billing account, בנפרד מתפקידי המשאבים שלכם. בפרט, כדי לצרף project חדש ל-billing account אתם זקוקים ל- roles/billing.user על אותו billing account - זכויות project רחבות לבדן לא יספיקו.
• "אני יכול לפרוס" לא אומר לכם כלום על "אני יכול ליצור project בר חיוב". כדי להקים project שיכול לצבור חיובים אתם זקוקים גם ל-resourcemanager.projectCreator (ברמת ה-org/folder) וגם ל-billing.user (על ה-billing account). אם תפספסו את השני, יצירת ה-project תצליח למחצה ל-project שלא יכול באמת להריץ שום דבר.

זה רך יותר מקיר ה-commerce-plane הקשיח של Azure - חיוב GCP אכן מחובר ל-Cloud IAM, כך שהוא מופיע באותם משטחי gcloud ו-Terraform במקום עולם נפרד לחלוטין. אבל זה עדיין אובייקט נפרד עם תפקידים נפרדים, וזו ההפתעה השנייה הנפוצה ביותר של "אבל אני אדמין" אחרי APIs לא מופעלים.

שמות, מזהים, והפתעת רשת אחת

לכל משאב GCP יש relative resource name כמו projects/acme-app-prod/zones/us-central1-a/instances/web-1 (וצורה מלאה //compute.googleapis.com/...). ה-project ID עובר עם כל שורת log וקריאת API - אותה עבודה ש-account של ARN עושה ב-AWS - כך, כמו ב-Azure, שמות המשאבים שלכם יכולים להשמיט את מה שה-project כבר מקודד. אותם שמות קצרים יכולים לחזור בבטחה על פני ה-projects שלכם -dev, -qa, ו--prod.

המלכודת ברשת ששווה לציין מראש, מכיוון שהיא מפרה בשקט את אינסטינקטי AWS: רשת VPC ב-GCP היא משאב גלובלי, וה-subnets שלה הם אזוריים. ב-AWS VPC מוגבל לאזור אחד; ב-GCP VPC אחד משתרע על כל אזור, ואתם מחלקים בתוכו subnets אזוריים. VPC גלובלי יחיד עם subnets אזוריים הוא ברירת המחדל, לא הגדרת multi-region אקזוטית - אל תשתמשו ב-VPC peering כדי לעשות את מה ש-subnet כבר נותן לכם.

המפה המהירה AWS -> GCP

שמרו את זה לידכם בחודש הראשון:

• Organization -> organization. אותו רעיון, אך ה-GCP org קשור ל-Cloud Identity/Workspace domain שלכם.
• Organizational Unit (OU) -> folder. צומת קיבוץ שניתן לקינון; folders יכולים להכיל folders.
• Account -> project. יחידת הבידוד, IAM והחיוב - אך קלת משקל וניתנת למחיקה, נוצרת בעשרות.
• SCP (guardrail) -> Organization Policy constraint בהיקף org/folder/project - מגביל מה יכול להתקיים או להיות מוגדר, יורש כלפי מטה.
• IAM identity-attached policy -> IAM binding (member, role) על צומת עץ. אין מדיניות על המשתמש; ההענקה חיה על המשאב ויורשת כלפי מטה.
• IAM role שאתם מבצעים assume (דרך STS + trust policy) -> service account שאתם מתחזים אליו (דרך token-creator binding על ה-SA). זכרו את ההענקה הדו-צדדית.
• Explicit Deny statement -> IAM deny policy - אובייקט נפרד, מוערך לפני allows.
• IRSA (IAM Roles for Service Accounts) -> Workload Identity (GKE) / Workload Identity Federation (CI חיצוני) - אותו רעיון OIDC, ללא מפתחות.
• "השירות פשוט זמין" -> הפעילו את ה-API שלו לכל project תחילה (google_project_service). אין מקבילה ב-AWS.
• ARN ב-logs -> ה-resource name (projects/<id>/...); הקשר ה-project מובנה, לא מקודד בשם.

אתחול Terraform state, מתורגם

הנה מקום שבו ה-runbook שלכם מ-AWS כמעט עובד, ואז נשבר בשלב אפס.

האתחול של AWS שאתם מכירים: cold-start ל-state backend בחשבון הניהול (local state, ואז העברת ה-backend לתוך עצמו), שמירת ה-state של ה-backends לכל OU ב-backend השורש הזה, ויצירת member accounts באמצעות ה-backends שלהם. האינווריאנט שהופך את זה לנקי הוא שאתם תמיד יכולים לבצע אתחול מחשבון הניהול, מכיוון שהוא תמיד קיים ויכול להכיל S3 bucket.

GCP שובר את האינווריאנט הזה בבראשית באותה דרך ש-Azure עושה: האובייקט שתמיד קיים הוא ה-organization, אך צומת org לא יכול להכיל משאבים. GCS bucket חי ב-project, ו-project זקוק ל-parent ו-(כדי לעשות משהו אמיתי) לקישור חיוב ו-APIs מופעלים. אז "חשבון השורש" של GCP הוא project seed שאתם מכתירים במודע - השם האידיומטי הוא משהו כמו prj-bootstrap או Cloud Foundation Toolkit seed project.

הזרימה המתורגמת, כאשר ה-org ו-billing account כבר קיימים (המקרה הנפוץ):

1. אתחול קר אחד, אי פעם: צרו את ה-seed project באופן אימפרטיבי (gcloud projects create), הפעילו עליו את ה-bootstrap APIs (cloudresourcemanager, cloudbilling, serviceusage, iam, storage), קשרו חיוב, וצרו את ה-GCS state bucket עם local Terraform state - ואז init -migrate-state לתוך אותו bucket.
2. Service account אתחול עם roles ברמת ה-org: העניקו לו resourcemanager.projectCreator, billing.user, ו- roles אדמין של org-policy/IAM בצומת ה-organization, כך שיוכל ליצור ולנהל כל project במורד הזרם.
3. כל השאר הוא apply רגיל: projects, folders ומשאבים נוספים נוצרים על ידי Terraform המתחזה ל-bootstrap SA הזה, ה-state של כל project חי תחת prefix ב-GCS backend האחד.

מאפס מוחלט, הסדר נכפה - seed project ראשון, state bucket שני - מכיוון ש-backend הוא GCS bucket ו-bucket זקוק ל-project כדי לחיות בו. ויש קמט קטן של "ביצה ותרנגולת" בדיוק כמו ב-Azure: ה- google provider זקוק ל-project ול-APIs מופעלים כדי לעשות משהו, אז אתם יוצרים את ה-project הראשון הזה ומפעילים את ה-APIs שלו עם קריאת gcloud אימפרטיבית, ואז מאמצים אותו ל-Terraform לאחר מכן. (המודול terraform-google-modules/bootstrap אורז בדיוק את ריקוד ה-seed-project-plus-SA הזה.)

והנה היכן ש-GCP הוא באמת פשוט יותר מזיכרון השריר של AWS: backend-in-seed-project בתוספת resources-in-member אינו זקוק לאף אחד ממנגנוני ה-trust של AWS hub-and-spoke - אין role_arn ל-backend, אין assume_role ל-provider, אין trust policies דו-צדדיות. Service account ברמת ה-org עם ה-roles הנכונים עובד ברחבי הארגון מכיוון ש-IAM יורש כלפי מטה; ה-provider "קופץ" בין projects על ידי פשוט הגדרת project; והוא הופך לזהות ה-deployer על ידי הגדרת impersonate_service_account. Cross-project הוא פרמטר, לא משא ומתן על trust. (אתם תהדקו את זה מאוחר יותר עם custom roles, SAs לכל project, וזהויות CI ייעודיות - אבל גם אז אלה role bindings בהיקפים, לעולם לא trust-policy handshake.) אם אתם רוצים להעמיק בקידוד של אחד הצדדים, בחינת HashiCorp Terraform Authoring & Operations Pro בנויה סביב בדיוק דפוסי state ו-provider אלה.

ארבעת המקומות שבהם אינסטינקטי AWS שלכם יטעו אתכם באופן פעיל

אם תשכחו הכל, זכרו את אלה:

1. אין מדיניות על המשתמש. הפסיקו לחפש את ה-JSON המוצמד לזהות. הרשאות הן bindings (member, role) על ה-org, folder, project, או resource, והן יורשות למטה. ההענקה שאתם צריכים עשויה להיות שלוש רמות למעלה.
2. שום דבר לא עובד עד שתפעילו את ה-API. ה-403 הראשון שלכם ב-project חדש הוא בדרך כלל API not enabled, לא role חסר. כל שירות כבוי עד שתפעילו אותו, לכל project.
3. אתם מתחזים ל-service accounts, אתם לא מבצעים assume roles. וה-SA הוא משאב עם מדיניות גישה משלו - מתן זכויות project רחבות ל-principal שלכם חסר תועלת ללא token-creator binding על ה-SA.
4. חיוב הוא אובייקט נפרד. "אני יכול לפרוס כל דבר" לא אומר כלום על "אני יכול ליצור project בר חיוב או לקשר billing account." משאב שונה, roles שונים - billing.user על ה-billing account, לא project admin.

אילו הסמכות מתרגלות כל צד

ניהול ענן - היררכיה, זהות, guardrails ומצב - הוא עמוד השדרה של בחינות הארכיטקטורה והניהול בשני העננים, ולכן לימוד עבורן הוא גם הדרך המהירה ביותר לגרום למושגים לעיל להיקלט. אם אתם כבר מחזיקים בהסמכת AWS, הסמכת Google Cloud באותה שורה היא הצעד הבא הטבעי שלכם.

בצד AWS (הידע שאתם מתרגמים ממנו):

• AWS Certified Cloud Practitioner (CLF-C02) - יסודות חשבונות, IAM ו-Organizations.
• AWS Certified Solutions Architect - Associate (SAA-C03) - IAM, מבנה multi-account וארכיטקטורת ליבה.
• AWS Certified Solutions Architect - Professional (SAP-C02) - Organizations מרובי חשבונות, SCPs וגישה בין חשבונות בקנה מידה.
• AWS Certified Security - Specialty (SCS-C03) - עומק IAM, SCPs וניהול מפתחות.

בצד Google Cloud (הידע שאתם מתרגמים אליו):

• Google Cloud Digital Leader - organizations, projects, IAM וחיוב ברמה בסיסית.
• Google Cloud Associate Cloud Engineer - המישור היומיומי: projects, IAM bindings, service accounts ו-gcloud.
• Google Cloud Professional Cloud Architect - היררכיית org/folder/project, תכנון landing-zone וניהול בקנה מידה.
• Google Cloud Professional Cloud Security Engineer - עומק IAM, org policy, אבטחת service-account וניהול מפתחות.

נתיב פרגמטי אם אתם מוסמכי AWS כיום: התחילו ב-Cloud Digital Leader כדי למפות את אוצר המילים, ואז קפצו ל- Associate Cloud Engineer (שחי במישור ה-project-and-IAM שבו תשתמשו הכי הרבה), והוסיפו את ה-Professional Cloud Architect או Professional Cloud Security Engineer בהתאם לשאלה אם עבודתכם נוטה לארכיטקטורה או לאבטחה.

השורה התחתונה

GCP אינו קשה יותר מ-AWS - הוא מפורק באופן שונה. AWS מצמיד הרשאות לזהויות, נותן לכם חשבון כבד עם הכל מופעל, ומקפל את רוב הסמכות לתוך IAM. GCP תולה הרשאות על עץ משאבים שיורש כלפי מטה, נותן לכם projects זולים וחד פעמיים שמתחילים כלוחות חלקים, וגורם לכם להתחזות ל-service accounts במקום לבצע assume roles. תרגמו את המושגים פעם אחת - מדיניות עוברת מזהויות לעץ, חשבונות הופכים ל-projects עם ה-APIs שלהם כבויים, roles הופכים ל-service accounts שאתם מתחזים אליהם, וחיוב הוא אובייקט נפרד שאתם מקשרים - והשאר הוא אוצר מילים. תרגלו זאת עם ההסמכות לעיל, והחלקים שהרגישו כמו הכחשות שרירותיות יתחילו להיקרא כעיצוב קוהרנטי ומכוון.