דוגמה להעברה של רשתות VPC למתחמים נפרדים

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

בדוגמה הזו, הפרויקט המארח מורכב משתי רשתות VPC. שני פרויקטים של שירותים מארחים את המשאבים שלהם ב-Cloud Storage.

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

בתרשים הארכיטקטורה מוצגים הרכיבים הבאים:

• פרויקט מארח. הפרויקט המארח מכיל שתי רשתות VPC‏: VPC1 ו-VPC2.
• פרויקטים של שירות. פרויקטי השירות service-project-1 ו-service-project-2 מכילים קטגוריות של Cloud Storage ומוגנים על ידי גבולות הגזרה לשירות.
• היקף. גבולות הגזרה לשירות perimeter-1 מגנים על כל הפרויקט המארח ועל פרויקטים של שירותים. המכונה הווירטואלית VM1 ברשת ה-VPC‏ VPC1 והמכונה הווירטואלית VM2 ברשת ה-VPC‏ VPC2 יכולות לגשת למשאבים גם ב-service-project-1 וגם ב-service-project-2.

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

בתרשים הארכיטקטורה מוצגים הרכיבים הבאים:

• Perimeter-1. ההיקף הזה מגן על רשת ה-VPC‏ VPC1 ועל פרויקט השירות service-project-1. המכונה הווירטואלית VM1 יכולה לגשת לקטגוריה של Cloud Storage ב-service-project-1 אבל לא יכולה לגשת לקטגוריה של Cloud Storage ב-service-project-2.
• ‫Perimeter-2. ההיקף הזה מגן על רשת ה-VPC‏ VPC2 ועל פרויקט השירות service-project-2. המכונה הווירטואלית VM2 יכולה לגשת לקטגוריה של Cloud Storage ב-service-project-2 אבל לא יכולה לגשת לקטגוריה של Cloud Storage ב-service-project-1.

בדוגמה הזו להעברה, השינויים בתצורה מתבצעים במצב הרצת בדיקה ואז מאומתים לפני שמחילים את התצורה של הרצת הבדיקה. התהליך הזה מבטיח שהרשתות והמשאבים של ה-VPC יהיו מוגנים, ושלא יהיו שיבושים בתעבורת הנתונים של סביבת הייצור מ-VPC1 אל service-project-1 ומ-VPC2 אל service-project-2 במהלך ההעברה.

תהליך ההעברה כולל את השלבים הבאים:

• קבלת רשתות ה-VPC ופרטי ה-perimeter
• הגדרת תצורת היקף להרצת בדיקה
• אימות ההגדרה של ההרצה היבשה
• אכיפת הגדרת הרצת הבדיקה

קבלת רשתות ה-VPC ופרטי ה-perimeter

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

הצגת רשימה של רשתות ה-VPC בפרויקט המארח

הפקודה הבאה מציגה רשימה של רשתות ה-VPC בפרויקט המארח network-host-project:

    gcloud compute networks list --project=network-host-project
  

הדוגמה הזו יוצרת את הפלט הבא:

    NAME  SUBNET_MODE  BGP_ROUTING_MODE  IPV4_RANGE  GATEWAY_IPV4
    vpc1  AUTO         REGIONAL
    vpc2  AUTO         REGIONAL
  

קבלת פרטים על service perimeter

הפקודה הבאה מחזירה את פרטי גבולות הגזרה:

    gcloud access-context-manager perimeters describe perimeter-1
  

הדוגמה הזו יוצרת את הפלט הבא:

name: accessPolicies/<access policy number>/servicePerimeters/perimeter-1
status:
…
  resources:
  - projects/<network-host-project number>
  - projects/<service-project-1 number>
  - projects/<service-project-2 number>

המספר <access policy number> משמש בדוגמה של פקודות במצב הרצה יבשה. אפשר גם להגדיר מדיניות גישה כברירת מחדל באמצעות הפקודה הבאה:

    gcloud alpha config set access_context_manager/policy<access policy number>
  

הגדרת תצורת הרצת בדיקה

בדוגמה הזו, משתמשים בפקודה לבדיקה כדי לעדכן את גבולות הגזרה perimeter-1, להסיר את network-host-project ו-service-project-2 ולהוסיף את VPC1. לאחר מכן, מריצים את הפקודה של הרצת בדיקה כדי ליצור גבולות גזרה חדשים perimeter-2 ולהוסיף את service-project-2 ואת VPC2.

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

עדכון ההגדרה של הרצת הבדיקה

הפקודה הבאה מעדכנת את גבולות הגזרה perimeter-1 כדי להסיר את network-host-project,‏ service-project-2 ומוסיפה את VPC1:

    gcloud access-context-manager perimeters dry-run update perimeter-1
     --remove-resources="projects/<network-host-project number>,projects/<service-project-2 number>"
     --add-resources="//compute.googleapis.com/projects/network-host-project/global/networks/vpc1"
     --policy=<access policy number>
  

יצירת גבולות גזרה חדשים במצב פרימטר לבדיקות

הפקודה הבאה יוצרת את גבולות הגזרה perimeter-2, מוסיפה את service-project-2 ומוסיפה את VPC2:

    gcloud access-context-manager perimeters dry-run create perimeter-2
    --title=perimeter-2 --type="regular"
    --resources="projects/<service-project-2 number>,//compute.googleapis.com/projects/network-host-project/global/networks/vpc2"
    --restricted-services="storage.googleapis.com"
    --policy=<access policy number>
  

אימות ההגדרה של הרצת הבדיקה

בדוגמה הזו, מריצים את הפקודות הבאות כדי לוודא שאין שגיאות בהרצה היבשה מ-VPC1 אל service-project-1 ומ-VPC2 אל service-project-2:

כדי לראות את הקטגוריות של Cloud Storage ב-service-project-1, מתחברים ל-VM1 שנמצא ב-VPC1 ומריצים את הפקודה הבאה:

    gcloud storage ls --project=service-project-1
  

כדי לראות את הקטגוריות של Cloud Storage ב-service-project-2, מריצים את הפקודה הבאה:

    gcloud storage ls --project=service-project-2
  

הפקודות פועלות בהצלחה כי הגדרת ההרצה היבשה לא משפיעה על תנועת הנתונים בסביבת הייצור. עם זאת, השגיאה הבאה של הרצת ניסיון מופיעה ביומני הביקורת של network-host-project לגישה אל service-project-2 מ-VM1:

    egressViolations: [
    0: {
    servicePerimeter: "accessPolicies/<access policy number>/servicePerimeters/perimeter-1"
    source: "//compute.googleapis.com/projects/network-host-project/global/networks/VPC1"
    sourceType: "Network"
    targetResource: "projects/<service-project-2 number>"
    }
    ]
  

באופן דומה, בבקשות ל-Cloud Storage מ-VM2 אל service-project-2 לא מופיעות שגיאות של הרצה יבשה, ובבקשות מ-VM2 אל service-project-1 מופיעה שגיאת ההרצה היבשה הבאה ביומני הביקורת של network-host-project:

    egressViolations: [
    0: {
    servicePerimeter: "accessPolicies/<access policy number>/servicePerimeters/perimeter-2"
    source: "//compute.googleapis.com/projects/network-host-project/global/networks/VPC2"
    sourceType: "Network"
    targetResource: "projects/<service-project-1 number>"
    }
    ]
  

אכיפת הגדרת הרצת הבדיקה

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

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

    gcloud access-context-manager perimeters dry-run enforce-all --policy=<access policy number>
  

אחרי שמפעילים את הגדרות ההרצה היבשה, מריצים את הפקודה הבאה כדי לתאר את perimeter-1:

    gcloud access-context-manager perimeters describe perimeter-1 --policy=<access policy number>
  

בדוגמה הזו נוצר הפלט הבא, שבו network-host-project ו-service-project-2 הוסרו, ו-VPC1 נוסף ל-perimeter-1.

    name: accessPolicies/<access policy number>/servicePerimeters/perimeter-1
    status:
    …
    resources:
    - projects/<service-project-1 number>
    - //compute.googleapis.com/projects/<network-host-project>/global/networks/VPC1
  

מריצים את הפקודה הבאה כדי לתאר את perimeter-2:

    gcloud access-context-manager perimeters describe perimeter-2 --policy=<access policy number>
  

בדוגמה הזו נוצר הפלט הבא, שבו הערכים service-project-2 ו-VPC2 נוספים ל-perimeter-2.

    name: accessPolicies/<access policy number>/servicePerimeters/perimeter-2
    status:
    …
    resources:
    - projects/<service-project-2 number>
    - //compute.googleapis.com/projects/<network-host-project>/global/networks/VPC2
    title: perimeter-2