כשמעבירים פרויקטים של Google Cloud בין ארגונים, בחלק מהמשאבים וההגדרות צריך לבצע שלבים נוספים כדי לשמור על המשכיות השירות ולמנוע התנגשויות בהגדרות. המקרים המיוחדים האלה כוללים פרויקטים ללא משאב ארגון, משאבי VPC משותפים, תפקידים בהתאמה אישית וחשבונות שירות בפרויקטים שונים. לפני שמעבירים פרויקט, צריך לוודא שיש לכם את ההרשאות הנדרשות לניהול זהויות והרשאות גישה (IAM) בפרויקט, במשאב ההורה שלו ובמשאב היעד.
העברת פרויקטים שלא משויכים למשאב ארגון
אתם יכולים להעביר פרויקט שנוצר בלי משאב ארגון משויך להיררכיה של משאב ארגון. אבל אי אפשר לבטל את התהליך הזה. כדי להחזיר פרויקט למצב No organization, צריך לפנות ל-Cloud Customer Care.
כדי להעביר פרויקט שלא משויך למשאב ארגון, צריך להיות לכם התפקיד roles/resourcemanager.projectIamAdmin בפרויקט. בנוסף, צריך להיות לכם התפקיד roles/resourcemanager.projectCreator במשאב הארגון של היעד.
אם אין לכם את ההרשאה resourcemanager.organizations.get במשאב הארגון ברמה העליונה, יכול להיות שהפרויקטים שלכם לא יופיעו כמו שצריך מתחת לארגון במסוף Google Cloud . במצב כזה, יכול להיות שייראה כאילו הפרויקט לא משויך למשאב ארגון. למידע נוסף, קראו את המאמר הגבלת הרשאות הצפייה של משתמשים בפרויקטים.
כדי לבדוק אם הפרויקט משויך למשאב ארגון:
gcloud
מריצים את הפקודה הבאה:
gcloud projects describe PROJECT_ID
מחליפים את PROJECT_ID במזהה הפרויקט שרוצים להעביר.
אם משאב ההורה לא מוצג בפלט, זה מאשר שהפרויקט לא משויך למשאב ארגון.
אם משאב ההורה (תיקייה או משאב ארגון) מוצג בפלט, סימן שהפרויקט משויך למשאב ארגון.
תהליך ההעברה של פרויקט שלא משויך למשאב ארגון דומה לתהליך ההעברה של פרויקט בין משאבי ארגון, אבל לא צריך לבצע את כל השלבים בתוכנית ההעברה. כדי להעביר פרויקט למשאב ארגון, מבצעים את השלבים הבאים:
בודקים את ההשפעה על הפרויקט של כללי המדיניות שהוא יירש.
אם צריך, יוצרים תיקיית ייבוא ייעודית במשאב הארגון של היעד.
מקצים הרשאות של ניהול זהויות והרשאות גישה (IAM) לפרויקט ולמשאב ההורה של היעד, כמו שמפורט בקטע הקצאת הרשאות.
בודקים אם צריך לשנות את החשבון לחיוב.
לאחר מכן, אתם יכולים לבצע את ההעברה באחת מהשיטות הבאות:
המסוף
פותחים את הדף IAM & Admin > Settings במסוף Google Cloud .
בוחרים את הפרויקט (פרויקט עם הערך No organization) באמצעות הכלי לבחירת פרויקטים.
בחלק העליון של דף ההגדרות, לוחצים על העברה.
בתיבת הדו-שיח שמופיעה, בוחרים את המשאב הארגוני שאליו רוצים להעביר את הפרויקט ולוחצים על Migrate.
gcloud
כדי להעביר פרויקט למשאב ארגון, מריצים את הפקודה הבאה:
gcloud beta projects move PROJECT_ID \
--organization ORGANIZATION_ID
מחליפים את מה שכתוב בשדות הבאים:
- PROJECT_ID: מזהה הפרויקט שרוצים להעביר
- ORGANIZATION_ID: המזהה של משאב הארגון שאליו מעבירים את הפרויקט
API
באמצעות Resource Manager API, אתם יכולים להעביר פרויקט למשאב הארגון על ידי הגדרת השדה parent למזהה של משאב הארגון.
כדי להעביר פרויקט למשאב הארגון:
- מקבלים את האובייקט
projectבאמצעות ה-methodprojects.get(). - מגדירים את השדה
parentלמזהה של משאב הארגון. - מעדכנים את האובייקט
projectבאמצעות ה-methodprojects.update().
אי אפשר לשנות את השדה parent אחרי שמגדירים אותו.
בקטע הקוד הבא אפשר לראות את השלבים האלה:
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 במזהה של משאב הארגון. מידע נוסף זמין במאמר קבלת מזהה משאב של ארגון.
כדי לקבל מידע על תפקיד בהתאמה אישית ב-IAM במשאב הארגון, מריצים את הפקודה הבאה:
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.
כדי להסיר פרויקט מגבולות גזרה לשירות, קראו את המאמר ניהול גבולות גזרה לשירות. יכול להיות שיעברו כמה שעות או עד יום אחד לפני שתוכלו להעביר פרויקט אחרי שהסרתם אותו מגבולות הגזרה לשירות.
כללי מדיניות של בקרת גישה מבוססת-הקשר לחשבונות שירות
בקרת גישה מבוססת-הקשר מאפשרת למשתמשים להגדיר כללי מדיניות גישה למשאבים של 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:
לעדכן את מסך ההסכמה של OAuth כך שיהיה חיצוני במקום פנימי.
אם האפליקציה משתמשת בנתונים רגישים, צריך להגיש בקשה לאימות האפליקציה להיקפים רגישים או מוגבלים. אחרת, המשתמשים יראו מסך של אפליקציה לא מאומתת.
Cloud OS Login API
אם Cloud OS Login API מופעל בפרויקט המקור, מקצים את התפקיד roles/compute.osLoginExternalUser לכל חשבון ראשי שיש לו גישה לפרויקט הזה. כך תוכלו לוודא שחשבונות המשתמשים האלה לא יאבדו את הגישה למשאב הארגון ביעד.
הזמנות משותפות של מכונות וירטואליות (VM)
במקרה של הזמנה משותפת, הפרויקט שיצר את ההזמנה (הפרויקט הבעלים) או כל פרויקט שההזמנה משותפת איתו (הפרויקט הצרכן) יכולים לצרוך את ההזמנה על ידי יצירת מכונות וירטואליות. אפשר לשתף הזמנה רק עם פרויקטים באותו ארגון של הפרויקט שבבעלותכם.
כשמעבירים פרויקט של בעלים או של צרכן, קורים הדברים הבאים:
- אם תעבירו את הפרויקט הבעלים, המערכת של Compute Engine תמחק את כל המקומות השמורים שנוצרו על ידי הפרויקט הזה. מכונות וירטואליות שפועלות לא מושפעות.
- אם מעבירים פרויקט צרכן, הוא מפסיק לצרוך משאבים מכל הזמנה משותפת בארגון הקודם.
מידע נוסף זמין במאמר איך פועלים מקומות שמורים משותפים.
צירוף חשבונות שירות למשאבים
ברוב שירותי Google Cloud , צריך את ההרשאה iam.serviceAccounts.actAs כדי לצרף חשבון שירות למשאב. עם זאת, בעבר, שירותים מסוימים אפשרו זאת ללא הרשאות התחזות מפורשות. המידע הזה מתועד במאמר דרישת הרשאה כדי לצרף חשבונות שירות למשאבים.
אם למשאב הארגון של המקור יש את ההתנהגות הקודמת הזו אבל ליעד אין, צריך לתת את התפקיד roles/iam.serviceAccountUser למשתמשים שמצרפים את חשבונות השירות האלה. מידע נוסף על הרשאות זמין במאמר תפקידים לאימות חשבון שירות.
כדי לבדוק אם למשאב הארגון יש את ההתנהגות הקודמת:
נכנסים לדף Organization policies במסוף Google Cloud :
בכלי לבחירת משאבים, בוחרים את המשאב הארגוני שרוצים לבדוק.
בתיבת הסינון, מזינים
constraints/appengine.enforceServiceAccountActAsCheck.אם המדיניות מופיעה, למשאב הארגון יש את ההתנהגות מדור קודם.
חוזרים על שלבים 3 ו-4 לכל אחד מהאילוצים הבאים:
appengine.enforceServiceAccountActAsCheckdataflow.enforceComputeDefaultServiceAccountCheckdataproc.enforceComputeDefaultServiceAccountCheckcomposer.enforceServiceAccountActAsCheck
אם מופיעה אחת מהמגבלות האלה, משאב הארגון משתמש בהתנהגות הקודמת. אם שני המשאבים ברמת הארגון משתמשים בהתנהגות הקודמת, לא צריך לעשות כלום, אבל כדאי לאכוף את המדיניות כדי למנוע התחזות לא מכוונת.
העברת פרויקטים עם BigQuery sharing
אם תעבירו פרויקט שמשתמש ב-BigQuery sharing למשאב ארגוני אחר, יכול להיות שתיתקלו בשגיאות. כדי לפתור אותן, פנו ל-Cloud Customer Care.
אם המשאב של החלפת הנתונים מהארגון הקודם לא מופיע בדף Sharing administrator של הארגון החדש, צריך להשתמש ב-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 בארגון החדש. כתוצאה מכך, כל פעולות הביטול או המשיכה של ההרשאה הזו נכשלות, ולמבקש נשארת גישה עד שתוקף ההרשאה פג.