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

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

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

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

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

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

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

gcloud

מריצים את הפקודה הבאה:

gcloud projects describe PROJECT_ID

מחליפים את PROJECT_ID במזהה הפרויקט שרוצים להעביר.

אם המשאב parent לא מוצג בפלט, זה מאשר שהפרויקט לא משויך למשאב ארגון.

אם משאב ההורה (תיקייה או משאב ארגון) מוצג בפלט, זה מאשר שהפרויקט משויך למשאב ארגון.

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

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

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

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

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

לאחר מכן תוכלו לבצע את ההעברה.

המסוף

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

  1. פותחים את הדף IAM & admin > Settings במסוף Google Cloud .

    פתיחת דף ההגדרות

  2. לוחצים על Project picker (כלי לבחירת פרויקטים) בחלק העליון של הדף.

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

  4. בוחרים את הפרויקט שרוצים להעביר.

    צילום מסך של כלי לבחירת פרויקטים

  5. בראש הדף, לוחצים על העברה.

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

gcloud

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

gcloud beta projects move PROJECT_ID \
    --organization ORGANIZATION_ID

כאשר:

  • ‫PROJECT_ID הוא מזהה הפרויקט שרוצים להעביר למשאב הארגון.
  • ‫ORGANIZATION_ID הוא המזהה של משאב הארגון שאליו רוצים להעביר את הפרויקט.

API

באמצעות Resource Manager API, אפשר להעביר פרויקט למשאב הארגון על ידי הגדרת השדה parent למזהה משאב הארגון של משאב הארגון.

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

  • מקבלים את האובייקט project באמצעות ה-method‏ projects.get().
  • מגדירים את השדה parent למזהה משאב הארגון של משאב הארגון.
  • מעדכנים את האובייקט project באמצעות ה-method‏ projects.update().

אי אפשר לשנות את השדה parent אחרי שמגדירים אותו.

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

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

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

VPC משותף

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

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

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

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

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

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

gcloud iam roles list --organization ORGANIZATION_ID

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

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

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 Service Controls.

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

Dedicated Interconnect

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

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

Partner Interconnect

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

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

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

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

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

החלתם על project-C מדיניות ארגון עם אילוץ הגבלה לפי דומיין, שמאפשרת לו גישה רק לדומיין של organizations/12345678901.

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

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

בקשות תמיכה

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

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

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

כדי למנוע אובדן גישה לחברים במשאב של ארגון המקור:

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

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

OS Login

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

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

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

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

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

מידע נוסף על שיתוף הזמנות

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

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

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

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

  1. במסוף Google Cloud , נכנסים לדף מדיניות הארגון.

    מעבר לדף מדיניות הארגון

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

  3. בתיבת הסינון בחלק העליון של רשימת מדיניות הארגון, מזינים את הטקסט constraints/appengine.enforceServiceAccountActAsCheck.

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

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

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

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

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

מיגרציה של פרויקטים עם שיתוף

אם מעבירים את הפרויקט שמשתמש ב-BigQuery sharing (לשעבר שיתוף) למשאב ארגוני אחר, יכול להיות שתיתקלו בשגיאה. כדי לפתור שגיאות, פנו לתמיכה.

אם אוסף הנתונים לשיתוף מהארגון הקודם לא מוצג בדף 'ניהול שיתוף' בארגון החדש, צריך להשתמש ב-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.

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

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

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

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

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

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

  1. מייצאים את הטקסונומיות מפרויקט המקור באמצעות Export API.

  2. מייבאים את הטקסונומיות לפרויקט היעד באמצעות Import API.

  3. מקצים מחדש את תגי המדיניות לעמודות הרלוונטיות בטבלה ב-BigQuery.

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

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

כאן אפשר לקרוא איך לבצע את ההעברה.