טיפול במקרים מיוחדים

איך מטפלים במקרים מיוחדים כשמעבירים פרויקטים לפני שמעבירים פרויקט, צריך לוודא שיש לכם את ההרשאות הנדרשות ב-IAM (הפלטפורמה לניהול זהויות והרשאות גישה) בפרויקט, במשאב האב שלו ובמשאב היעד.

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

אפשר להעביר פרויקט שנוצר ללא משאב ארגוני משויך להיררכיה של משאב ארגוני. עם זאת, אי אפשר לבטל את התהליך הזה. כדי להחזיר פרויקט למצב No organization, צריך לפנות ל-Cloud Customer Care לקבלת עזרה.

כדי להעביר פרויקט שלא משויך למשאב ארגוני, צריך להיות לכם תפקיד roles/resourcemanager.projectIamAdmin בפרויקט. בנוסף, צריך להיות לכם תפקיד roles/resourcemanager.projectCreator במשאב הארגון של היעד.

אם אין לכם את ההרשאה resourcemanager.organizations.get במשאב הארגון הראשי, יכול להיות שהפרויקטים לא יופיעו כמו שציפיתם מתחת לארגון במסוף Google Cloud . יכול להיות שייראה כאילו הפרויקט לא משויך למשאב ארגוני. מידע נוסף זמין במאמר בנושא הגבלת הנראות של פרויקטים למשתמשים.

כדי לבדוק אם הפרויקט משויך למשאב ארגוני:

gcloud projects describe PROJECT_ID

תהליך העברת פרויקט שלא משויך למשאב ארגוני דומה לתהליך העברת פרויקט בין משאבים ארגוניים, אבל לא צריך לבצע את כל השלבים בתוכנית ההעברה. כדי להעביר פרויקט למשאב ארגון, פועלים לפי השלבים הבאים:

1. בודקים את ההשפעה על הפרויקט של המדיניות שהוא יקבל בירושה.

2. אם צריך, יוצרים תיקייה ייעודית לייבוא במשאב של ארגון היעד.

3. מקצים הרשאות בממשק לניהול הזהויות והרשאות הגישה (IAM) לפרויקט ולמשאב היעד, כמו שמתואר במאמר הקצאת הרשאות.

4. בודקים אם צריך לשנות את החשבון לחיוב.

לאחר מכן, תוכלו לבצע את ההעברה באמצעות אחת מהשיטות הבאות:

gcloud beta projects move PROJECT_ID \
    --organization ORGANIZATION_ID

    project = crm.projects().get(projectId=flags.projectId).execute()
    project['parent'] = {
        'type': 'organization',
        'id': flags.organizationId
    }

אם Cloud OS Login API מופעל בפרויקט המקור, צריך להקצות את התפקיד roles/compute.osLoginExternalUser לכל החשבונות הראשיים שיש להם גישה לפרויקט הזה.

VPC משותף

בתנאים מסוימים, אפשר להעביר פרויקטים של VPC משותף. קודם, משתמש עם התפקיד roles/orgpolicy.policyAdmin במשאב של ארגון המקור צריך להגדיר מדיניות ארגונית שמכילה את האילוץ constraints/resourcemanager.allowEnabledServicesForExport ברכיב ההורה של הפרויקט שמייצאים. במגבלה הזו צריך לציין את SHARED_VPC כallowed_value.

אין צורך להשבית את VPC משותף לפני ההעברה. עם זאת, קודם צריך להעביר את הפרויקט המארח של ה-VPC המשותף, ואז את כל פרויקטי השירות שלו. מומלץ להתאים בין כללי חומת האש במשאבי הארגון של המקור והיעד כדי לצמצם בעיות פוטנציאליות ולמנוע השבתה. אנחנו לא יכולים להבטיח את תקינות הרשת אם משאירים פרויקטים של שירותים במשאב של ארגון המקור בזמן העברת פרויקטים אחרים.

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

תפקידי IAM בהתאמה אישית

תפקידים מותאמים אישית לניהול זהויות והרשאות גישה מספקים שליטה מדויקת בגישה למשאבים ברמת משאב הארגון, אבל הם תקפים רק במשאב הארגון שבו הם נוצרו. אם מעבירים פרויקט שמכיל קישור של מדיניות הרשאה לתפקיד IAM מותאם אישית ברמת הארגון, ההעברה תיכשל. השגיאה מסבירה שהתפקיד לא קיים במשאב של ארגון היעד.

כדי להציג את כל התפקידים בהתאמה אישית ב-IAM במשאב הארגון, מריצים את הפקודה הבאה:

gcloud iam roles list --organization ORGANIZATION_ID

מחליפים את ORGANIZATION_ID במזהה של משאב הארגון. מידע נוסף מופיע במאמר איך מוצאים את מזהה משאב הארגון.

כדי לקבל מידע על תפקיד בהתאמה אישית ב-Identity and Access Management במשאב הארגון, מריצים את הפקודה הבאה:

gcloud iam roles describe --organization ORGANIZATION_ID \
    ROLE_ID

מחליפים את מה שכתוב בשדות הבאים:

• ‫ORGANIZATION_ID: המזהה של משאב הארגון
• ROLE_ID: שם התפקיד שרוצים לתאר

כדי לעקוף את השגיאה הזו, צריך ליצור תפקידים בהתאמה אישית ברמת הפרויקט ששווים לתפקידים בהתאמה אישית ברמת הארגון שמועברים בירושה. לאחר מכן, מסירים את קישורי התפקידים ב-IAM שמפנים לתפקידים בהתאמה אישית ברמת הארגון.

אחרי שמבצעים את ההעברה של הפרויקט, אפשר לעדכן את מדיניות ההרשאות כדי להשתמש בתפקידים בהתאמה אישית ברמת הארגון במשאב הארגון של היעד.

למידע נוסף, ראו יצירה וניהול של תפקידים מותאמים אישית.

נעילת קטגוריות

נעילת קטגוריה של Cloud Storage מאפשרת להגדיר מדיניות שמירת נתונים בקטגוריה של Cloud Storage. המדיניות הזו קובעת את משך הזמן שבו צריך לשמור את האובייקטים. הנעילה של קטגוריית האחסון מוגנת באמצעות מנעול למניעת מחיקה כדי למנוע מחיקה בטעות של פרויקט.

מדיניות שמירת הנתונים והמנעול למניעת מחיקה נשמרים עם הפרויקט במהלך ההעברה. המנעול למניעת מחיקה לא מונע את העברת הפרויקט.

היקפי אבטחה ב-VPC Service Controls

VPC Service Controls מצמצם את הסיכונים לזליגת נתונים על ידי הגדרת גבולות גזרה אבטחתיים מבוססי-פרויקט מסביב לשירותים שלGoogle Cloud . לא ניתן להעביר פרויקט המוגן על ידי היקף אבטחה של בקרות שירות VPC.

כדי להסיר פרויקט מגבול גזרה לאבטחה, אפשר לעיין במאמר בנושא ניהול גבולות גזרה לשירות. יכול להיות שיעברו כמה שעות או אפילו יום עד שתהליך העברת הפרויקט יסתיים אחרי שתסירו אותו מגבולות גזרה לשירות.

כללי מדיניות לבקרת גישה מבוססת-הקשר לחשבונות שירות

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

כדי למחוק מדיניות של בקרת גישה מבוססת-הקשר לחשבונות שירות, אפשר לעיין במאמר בנושא ניהול של הרשאות גישה.

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

• יצירת מדיניות: יכול להיות שמדיניות חדשה של בקרת גישה מבוססת-הקשר לא תחסום העברות באופן מיידי. העיכוב בהפצה יכול להימשך עד 24 שעות אחרי יצירת המדיניות.
• מחיקת כללי מדיניות: אחרי שמסירים את כל כללי המדיניות של בקרת הגישה מבוססת-הקשר מפרויקט, יכולות לעבור כמה שעות עד שאפשר להעביר את הפרויקט.

Dedicated Interconnect

מומלץ להעביר פרויקטים עם אובייקטים של Dedicated Interconnect ופרויקטים עם קבצים מצורפים של VLAN ביחד. פרויקטים עם האובייקטים האלה ימשיכו לפעול אחרי העברה בין משאבי ארגון. עם זאת, אי אפשר ליצור קבצים מצורפים חדשים של VLAN בין משאבים של הארגון בזמן שהם מפוצלים.

יכול להיות ששינויים בהגדרות של פרויקט מפוצל לא יועברו למשאבים של הארגון. מומלץ לא להשאיר פרויקטים מפוצלים למשך זמן רב.

Partner Interconnect

אין שיקולים מיוחדים שצריך לקחת בחשבון כשמעבירים פרויקטים עם Partner Interconnect. אין שיקולים מיוחדים שצריך לקחת בחשבון כשמעבירים פרויקטים באמצעות Partner Interconnect.

פרויקט ניהול

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

חשבונות שירות חוצי-פרויקטים

כשמעבירים חשבון שירות חוצה פרויקטים, המקרים הבאים רלוונטיים:

• אם מעבירים פרויקט עם חשבון שירות שמשויך לכמה פרויקטים, חשבון השירות ימשיך לפעול במשאב הארגון של היעד. ההגבלה הזו חלה גם אם מדיניות הארגון מגבילה את הדומיין.
• אם מעבירים פרויקט שבבעלותו חשבון שירות חוצה פרויקטים שמשמש פרויקט אחר, חשבון השירות ימשיך לפעול. עם זאת, אי אפשר להשתמש בו במשאבים שחלה עליהם מדיניות ארגון עם הגבלה לפי דומיין, שמגבילה אותם לדומיין של משאב ארגון המקור.

לדוגמה, נניח שהקובץ project-A בקובץ organizations/12345678901 כולל את הקובץ serviceAccount-1. ‫project-B ו-project-C באותו ארגון משתמשים גם ב-serviceAccount-1.

ב-project-C יש מדיניות ארגון שמאפשרת רק את הדומיין organizations/12345678901.

אם מוסיפים את serviceAccount-1 לקשירת IAM עבור project-C לפני שמבצעים מיגרציה של project-A אל organizations/45678901234, חשבון השירות פועל.

אם מעבירים את project-A אל organizations/45678901234 ואז מנסים להוסיף את serviceAccount-1 אל הקישור של IAM אל project-C, הקישור נכשל כי הוא מפר את ההגבלה על הדומיין.

בקשות תמיכה

אם מעבירים פרויקט עם בקשת תמיכה פתוחה, צריך לעדכן את Cloud Customer Care אחרי ההעברה. לא תוכלו לראות את פניות התמיכה האלה עד ש-Cloud Customer Care יעדכן את המטא-נתונים למשאב הארגון החדש.

מסך הסכמה ל-OAuth

אם בפרויקט שלכם נעשה שימוש במסך הסכמה פנימי ל-OAuth, רק חברי צוות במשאבים של ארגון היעד יכולים לאשר בקשות אחרי ההעברה. יכול להיות שיעברו עד 24 שעות עד שהשינוי ייכנס לתוקף. עד אז, חברי המשאבים בארגון המקור עדיין יכולים לאשר בקשות.

כדי לוודא שחברי המקור לא יאבדו את הגישה, כדאי ליצור משתמשים חדשים במשאב של ארגון היעד או לעדכן את ההגדרה של מסך ההסכמה ל-OAuth:

1. מעדכנים את מסך ההסכמה ל-OAuth כך שיהיה חיצוני ולא פנימי.

2. אם האפליקציה משתמשת במידע אישי רגיש, צריך להגיש בקשה לאימות אפליקציות עבור היקפים רגישים או מוגבלים. אחרת, המשתמשים יראו מסך של אפליקציה לא מאומתת.

Cloud OS Login API

אם Cloud OS Login API מופעל בפרויקט המקור, צריך להקצות את התפקיד roles/compute.osLoginExternalUser לכל החשבונות הראשיים שיש להם גישה לפרויקט הזה. כך מבטיחים שחשבונות המשתמשים האלה לא יאבדו את הגישה למשאב הארגון ביעד.

שריינים משותפים של מכונות וירטואליות (VM)

בהזמנה משותפת, הפרויקט שיצר את ההזמנה (פרויקט הבעלים) או כל פרויקט שההזמנה שותפה איתו (פרויקט הצרכן) יכולים להשתמש בהזמנה על ידי יצירת מכונות וירטואליות. אפשר לשתף הזמנה רק עם פרויקטים באותו ארגון של הפרויקט הבעלים.

כשמעבירים פרויקט בעלים או פרויקט צרכן, קורה הדבר הבא:

• אם מעבירים את פרויקט הבעלים, מערכת Compute Engine מוחקת את כל המקומות השמורים שנוצרו על ידי הפרויקט הזה. מכונות וירטואליות שפועלות לא מושפעות.
• אם מעבירים פרויקט לצרכן, הוא מפסיק לצרוך משאבים מכל הזמנה משותפת בארגון הקודם.

מידע נוסף זמין במאמר בנושא איך פועלות הזמנות משותפות.

צירוף חשבונות שירות למשאבים

ברוב השירותים של Google Cloud , נדרשת ההרשאה iam.serviceAccounts.actAs כדי לצרף חשבון שירות למשאב. עם זאת, בעבר, שירותים מסוימים אפשרו זאת ללא הרשאות מפורשות להתחזות. הסבר על כך מופיע במאמר ההרשאה הדרושה כדי לצרף חשבונות שירות למשאבים.

אם במשאב הארגון של המקור יש את ההתנהגות הזו, אבל במשאב היעד אין, צריך להקצות את התפקיד roles/iam.serviceAccountUser למשתמשים שמצרפים את חשבונות השירות האלה. מידע נוסף על הרשאות זמין במאמר תפקידים לאימות חשבון שירות.

כדי לבדוק אם למשאב הארגוני שלכם יש את ההתנהגות של הגרסה הקודמת:

1. נכנסים לדף Organization policies במסוף Google Cloud :

   מעבר לדף Organization policies

2. בכלי לבחירת משאבים, בוחרים את המשאב הארגוני שרוצים לבדוק.

3. בתיבת הסינון, מזינים constraints/appengine.enforceServiceAccountActAsCheck.

4. אם המדיניות מופיעה, למשאב הארגון יש התנהגות מדור קודם.

5. חוזרים על שלבים 3 ו-4 לכל אחד מהאילוצים הבאים:

   • appengine.enforceServiceAccountActAsCheck
   • dataflow.enforceComputeDefaultServiceAccountCheck
   • dataproc.enforceComputeDefaultServiceAccountCheck
   • composer.enforceServiceAccountActAsCheck

אם מופיעה אחת מהמגבלות האלה, משמעות הדבר היא שמשאב הארגון משתמש בהתנהגות מדור קודם. אם בשני המשאבים של הארגון נעשה שימוש בהתנהגות מדור קודם, לא נדרשת פעולה, אבל כדאי לאכוף את המדיניות כדי למנוע התחזות לא מכוונת.

העברת פרויקטים באמצעות BigQuery sharing

אם מעבירים פרויקט שמשתמש ב-BigQuery sharing למשאב ארגוני אחר, יכול להיות שיופיעו שגיאות. כדי לפתור את הבעיות האלה, צריך לפנות ל-Cloud Customer Care.

אם משאב חילופי הנתונים מהארגון הקודם לא מוצג בדף הניהול של השיתוף בארגון החדש, צריך להשתמש ב-BigQuery Sharing API כדי לעדכן שדה (לדוגמה, description) ולהפעיל רענון של המטמון.

משתמשים בשיטה projects.locations.dataExchanges.patch.

PATCH https://analyticshub.googleapis.com/v1/projects/ \
    PROJECT_ID/locations/LOCATION/ \
    dataExchanges/DATA_EXCHANGE_ID \
    ?update_mask=UPDATE_DX_FIELD \
    -d { UPDATE_DX_FIELD:UPDATE_DX_VALUE }

מחליפים את מה שכתוב בשדות הבאים:

• ‫PROJECT_ID: המזהה הייחודי של הפרויקט
• LOCATION: המיקום של חילופי הנתונים
• ‫DATA_EXCHANGE_ID: המזהה של אוסף נתונים לשיתוף
• ‫UPDATE_DX_FIELD: השדה לעדכון, למשל description
• ‫UPDATE_DX_VALUE: הערך המעודכן

שירות Backup and DR

צריך להשבית את Backup and DR לפני שמעבירים פרויקטים למשאב ארגוני אחר. חשוב לקחת בחשבון את הסיכון להשבתה כשהשירות מושבת. אחרי שהמיגרציה תושלם, מפעילים מחדש את Backup and DR.

איחוד שירותי אימות הזהות של עומסי עבודה

איחוד שירותי אימות הזהות של עומסי עבודה מאפשר לתת לעומסי עבודה מקומיים או מרובי עננים גישה למשאבי Google Cloud . מאגרי איחוד זהויות של עומסי עבודה הם משאבים בהיקף הפרויקט.

כשמעבירים פרויקט, מאגרי הזהויות של כוח העבודה והספקים שלהם שהוגדרו בפרויקט הזה מועברים יחד עם הפרויקט. לא נדרשת פעולה נוספת כדי לשמור על הגישה לעומסי עבודה שמשתמשים במאגרי הזיכרון האלה.

תגים

תגים הם צמדי מפתח/ערך שמצורפים למשאבים. תגים שנוצרו ברמת הארגון לא מועברים.

אם בפרויקט שלכם נעשה שימוש בתגים ברמת הארגון עבור קשרי מדיניות או אילוצים, אתם צריכים ליצור מחדש את מפתחות התגים והערכים במשאב הארגון של היעד ולצרף אותם מחדש לפרויקטים שהועברו.

העברת פרויקטים עם הרשאות ירושה ב-Privileged Access Manager

לפני שמעבירים פרויקט, מומלץ לבטל את כל ההרשאות הפעילות עם היקף מוגבל בפרויקט הזה. הרשאה בהיקף מוגבל נוצרת על בסיס זכאות שעברה בירושה מתיקייה או מארגון, ואז ההיקף שלה מוגבל לפרויקט צאצא.

כשמעבירים פרויקט עם הרשאה פעילה בהיקף מוגבל, מדיניות IAM מועברת לארגון החדש, אבל ההרשאה שמנהלת אותה נשארת בארגון הקודם. סוכן השירות של Privileged Access Manager מאבד את ההרשאה לשנות את מדיניות ה-IAM בארגון החדש. כתוצאה מכך, כל פעולת ביטול או מחיקה של ההרשאה הזו תיכשל, והמבקש ישמור על הגישה עד שתוקף ההרשאה יפוג.

המאמרים הבאים

• ביצוע ההעברה