במיגרציה של פרויקט, צריך להעריך איך המיגרציה תשפיע על השירותים שפועלים בתוך הפרויקט. ב-Resource Manager API, משאב הפרויקט וכל השירותים שפועלים תחתיו נחשבים ליחידה אחת, כלומר לא יחולו שינויים בהגדרות בתוך הפרויקט.
ההעברה לא תגרום לשינויים ישירים בהגדרות של הפרויקט, אבל השינוי בהיררכיית המשאבים צפוי להשפיע על הפונקציונליות של הפרויקט ועל השירותים הפועלים בו. כללי מדיניות מסוג Allow, Deny או Organization שמועברים בירושה ולא מצורפים ישירות לפרויקט לא יועברו עם הפרויקט במהלך ההעברה. מדיניות הארגון וחשבונות השירות שמצורפים ישירות למשאב יועברו. יכול להיות שזה יגרום להתנהגות לא צפויה אחרי שההעברה תושלם.
העברת הפרויקט עלולה לגרום גם להפרות של מדיניות הארגון, בהתאם למדיניות הארגון של משאב הארגון ביעד.
לפני שמעבירים פרויקט בין משאבי ארגון, כדאי ליצור תוכנית העברה כדי לקבוע את המוּכנוּת של משאב הארגון ושל הפרויקטים שרוצים להעביר. בתוכנית ההעברה הזו, כדאי לערוך רשימה של כל השירותים שהפרויקט מפעיל, ושל כל שירות אחר שעשוי להיות מושפע מההעברה או מהיררכיית המשאבים ביעד של הפרויקט.
סקירה כללית של מלאי שטחי הפרסום
אפשר להשתמש במאגר משאבי הענן כדי ליצור סקירה כללית של המשאבים שבשימוש, כולל מדיניות ההרשאות. אתם יכולים להשתמש בסקירה הכללית הזו כדי לתכנן את תהליך המעבר.
אפשר גם להשתמש ב-Cloud Asset Inventory כדי להעביר את הנתונים האלה ל-BigQuery. כך תוכלו להריץ שאילתות על הנתונים באמצעות SQL, שקל יותר לקרוא אותו בהשוואה לנתונים בפורמט JSON. מידע על ייצוא הנתונים האלה זמין במאמר בנושא ייצוא ל-BigQuery.
כדי לקבל רשימה של כל כללי מדיניות ההרשאות והדחייה שמשפיעים על הגישה לפרויקט, אפשר לעיין במאמר בנושא בדיקת כל כללי מדיניות ההרשאות והדחייה שחלים על המשאב.
אימות המדיניות
כשמעבירים פרויקט, הוא לא יירש יותר את המדיניות מהמקום הנוכחי שלו בהיררכיית המשאבים, והוא יהיה כפוף להערכת המדיניות האפקטיבית ביעד. מומלץ לוודא שהמדיניות האפקטיבית ביעד של הפרויקט תהיה זהה ככל האפשר למדיניות שהייתה לפרויקט במיקום המקור.
כל מדיניות שחלה ישירות על הפרויקט עדיין תצורף אחרי שההעברה תושלם. החלת מדיניות ישירות על הפרויקט היא דרך טובה לוודא שהמדיניות הנכונה חלה מהרגע שבו ההעברה מסתיימת.
כללי מדיניות ההרשאה, הדחייה ומדיניות הארגון עוברים בירושה דרך היררכיית המשאבים, ויכולים לחסום את הפעולה של שירות אם הם לא מוגדרים בצורה נכונה. כדי לוודא שהמדיניות תואמת למטרות השליטה שלכם, צריך לקבוע את המדיניות בפועל ביעד של הפרויקט בהיררכיית המשאבים.
ניהול מפתחות מוצפנים
צריך לבדוק אם בפרויקט מופעל מפתח מוצפן בניהול הלקוח או Cloud Key Management Service אחר. המפתחות הקריפטוגרפיים הם בבעלות הפרויקט, ולכן משתמש עם גישת owner לפרויקט הזה יוכל לנהל את המפתחות ב-Cloud KMS ולבצע עליהם פעולות קריפטוגרפיות בפרויקט הזה.
מידע נוסף זמין במאמר בנושא הפרדת תפקידים.
תכונות בגרסת טרום-השקה (Preview)
אפשר להפעיל תכונות בתצוגה מקדימה במשאבים של הארגון, בתיקיות או בפרויקטים. אם הפעלתם תכונת אלפא או בטא בפרויקט שאתם רוצים להעביר, התכונה הזו אמורה להמשיך לפעול אחרי ההעברה. אם תכונת התצוגה המקדימה היא פרטית ולא נכללת ברשימת ההיתרים של משאב ארגון היעד, לא תוכלו לבצע שינויים בהגדרות אחרי שההעברה תושלם.
תוכנית רולבק
אם תגלו שמשהו לא עובד באחד מהפרויקטים שהעברתם, תוכלו לשחזר אותם למיקום המקורי שלהם. כדי לעשות זאת, צריך לוודא שיש לכם את הרשאות ה-IAM הנדרשות ולהגדיר את מדיניות הארגון הנדרשת כדי שתוכלו להריץ את העברת הפרויקט בכיוון ההפוך.
רשימת ההרשאות הנדרשות מופיעה במאמר הקצאת הרשאות. במאמר הגדרת מדיניות הארגון מוסבר אילו הגדרות צריך לבצע במדיניות הארגון כדי לאפשר העברת פרויקט.
תיקיות ייעודיות לייבוא ולייצוא
העברת מדיניות בירושה עלולה לגרום להשפעות לא רצויות כשמעבירים פרויקט, גם במשאבי הארגון במקור וגם במשאבי הארגון ביעד. כדי לצמצם את הסיכון הזה, אפשר ליצור תיקיות ספציפיות שיכילו רק פרויקטים לייצוא ולייבוא, ולוודא שהתיקיות בשני משאבי הארגון יורשות את אותן מדיניות. אפשר גם להגדיר הרשאות בתיקיות האלה, שהפרויקטים שיועברו לתוכן יירשו אותן. כך אפשר לזרז את תהליך העברת הפרויקטים.
כשמתכננים העברה, כדאי קודם להגדיר תיקיית מקור ייעודית.
כדי לעשות זאת, יוצרים תיקייה לכל משאב של ארגון היעד שאליו מתכננים לייצא פרויקטים. לאחר מכן, מגדירים מדיניות ארגונית בתיקיות האלה, כשכל אחת מהן כוללת את האילוץ constraints/resourcemanager.allowedExportDestinations שמוגדר למשאב הארגוני היחיד שאליו רוצים לייצא פרויקטים.
לדוגמה, אפשר להגדיר תיקיות Export to Marketing Org ו-Export to Sales Org, ולקבוע לכל אחת מהן את ההגבלות המתאימות של מדיניות הארגון.
באופן דומה, מגדירים תיקיות ייעודיות לייבוא במשאב של ארגון היעד, אחת לכל משאב של ארגון שממנו רוצים לייבא פרויקטים. כדי לעשות את זה, יוצרים תיקייה לכל משאב של ארגון מקור שממנו מתכננים לייבא פרויקטים. לאחר מכן, מגדירים מדיניות ארגונית בתיקיות האלה, כשכל אחת מהן כוללת את האילוץ constraints/resourcemanager.allowedImportSources שמוגדר למשאב הארגוני היחיד שממנו רוצים לייבא פרויקטים.
לדוגמה, אפשר להגדיר תיקיות Import from Marketing Org ו-Import from App Development Org, ולקבוע לכל אחת מהן את ההגבלות המתאימות של מדיניות הארגון.
בכל אחת מהתיקיות של הייבוא והייצוא, מקצים את התפקיד roles/resourcemanager.projectMover לאדם שיעביר את הפרויקטים. התפקיד הזה עובר בירושה לכל הפרויקטים שנמצאים בתיקיות האלה, ומאפשר למשתמש לבצע את פעולות ההעברה בכל פרויקט שמועבר לתיקיות האלה.
אחרי שמסיימים את העברת הפרויקט, צריך להסיר את התיקיות הייעודיות האלה.
מידע על הגדרת מדיניות הארגון מופיע במאמר הגדרת מדיניות הארגון.
המאמרים הבאים
במאמר הקצאת תפקידים והרשאות בניהול זהויות וגישה מוסבר איך להקצות תפקידים והרשאות בניהול זהויות וגישה כדי להעביר פרויקטים בין ארגונים.