מתן גישה למשאבים מוגנים מכתובת IP פנימית

בדף הזה נסביר איך לאפשר תעבורה מכתובות IP פנימיות ברשת VPC לגבולות גזרה לשירות באמצעות כללים לתעבורת נתונים נכנסת ויוצאת.

סקירה כללית

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

• תמיכה בתנאים של רמת גישה בסיסית כדי לאפשר טווחי כתובות IP פנימיות של רשתות VPC.

• האם לאפשר שימוש בתנאים האלה של רמת הגישה לקריאות API של תעבורת נתונים נכנסת או יוצאת אל גבולות הגזרה לשירות או מתוכם.

התכונה הזו מספקת את היתרונות הבאים:

• אתם יכולים לציין תנאים בהגדרות של VPC Service Controls כדי לאפשר גישה מכתובת IP פנימית ברשת VPC.

• תהליכי עבודה שדורשים שקריאות ל-API יעברו דרך כמה גבולות שירות יכולים להגביל את הגישה כך שתתאפשר רק לכמה רשתות משנה, במקום לאפשר גישה לכל רשת ה-VPC או הפרויקט.

• אתם יכולים להגדיר משאבים שונים מהסביבה המקומית כך שתהיה להם גישה רק למשאבים ספציפיים ב- Cloud de Confiance by S3NS . כחלק מרמת הגישה, צריך להשתמש בטווח כתובות ה-IP של רשת המשנה שמשויך למשאבים המקומיים האלה ולרשת ה-VPC של אזור הנחיתה.

איור 1 מציג דוגמה להגדרה שמאפשרת גישה לשירות מוגן ספציפי מכתובת IP פנימית מורשית.

מגבלות בשימוש בכתובת IP פנימית

כשמשתמשים בכתובת IP פנימית ב-VPC Service Controls, חלות ההגבלות הבאות:

• אפשר להפעיל כתובת IP פנימית רק עם רמות גישה בסיסיות, ולא עם רמות גישה מותאמות אישית.

• מומלץ לא לשלול רמות גישה באמצעות תנאים שמבוססים על כתובות IP פנימיות, כי זה עלול לגרום להתנהגויות לא צפויות.

• חלות גם המגבלות על הוספת רשתות VPC ל-service perimeters.

• כש-VPC Service Controls רושם ביומן הביקורת מדיניות שנדחתה, הוא מצנזר את השם של רשת ה-VPC כ-__UNKNOWN__ ביומן הביקורת.

• אין תמיכה ברשתות VPC שהערך של SUBNET_MODE מוגדר בהן כ-custom אבל אין להן תת-רשתות. כדי להפעיל כתובת IP פנימית, רשת ה-VPC צריכה להכיל לפחות רשת משנה אחת.

• אתם יכולים לציין רק 500 רשתות VPC בכל רמות הגישה במדיניות הגישה שלכם.

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

• אי אפשר להשתמש בכתובת IP פנימית כדי לאפשר גישה משירותים שמנוהלים על ידי Google. לדוגמה, Cloud SQL.

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

• כתובת ה-IP הפנימית לא תואמת לרמות הגישה שמתייחסות לאזורים גיאוגרפיים.

שימוש בכתובת IP פנימית ברמות גישה

1. מציינים את שם רשת ה-VPC ואת טווח כתובות ה-IP בשדה vpcNetworkSources של תנאי בסיסי של רמת גישה.

   • השם של רשת ה-VPC. צריך להגדיר את שם רשת ה-VPC בפורמט הבא:

     //compute.googleapis.com/projects/PROJECT_ID/global/networks/NETWORK_NAME
     

     לדוגמה, //compute.googleapis.com/projects/my-project/global/networks/my-vpc.

   • טווח כתובות IP. טווח כתובות ה-IP שצוין בשדה VpcSubNetwork של VpcNetworkSource חייב להיות בהתאם למפרט של רשת משנה של כתובות IP בפורמט בלוקים של CIDR. אפשר להשתמש בכל טווח כתובות IP שהוא טווח IPv4 תקין עבור רשתות משנה.

2. אפשר להשתמש ברמת הגישה הזו עם תנאי הרשאה ב-IngressSource או ב-EgressSource.

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

דוגמה לשימוש בכתובת IP פנימית כדי להגדיר גישה לתת-רשת

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

1. פרויקט מארח של רשת: Project1 מארח רשת VPC:‏ default. שתי המכונות הווירטואליות ב-Project1, ב-VM1 וב-VM2 משתמשות ברשת הזו כממשק רשת לשליחת תנועה דרכה.

2. פרויקט Cloud Storage: Project2 מכיל קטגוריה של Cloud Storage.

אתם יכולים להשתמש ב-VPC Service Controls כדי לאפשר רק ל-VM1 מ-Project1 לגשת לקטגוריה של Cloud Storage ב-Project2 באמצעות כתובת IP פנימית. כדי להגדיר את ההגדרה הזו, צריך לבצע את השלבים הבאים:

1. יוצרים גבולות גזרה לשירות sp1 סביב Project1 ועוד גבולות גזרה לשירות sp2 סביב Project2.

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

בתרשים הבא מוצגת ההגדרה שמתוארת בדוגמה הזו.

הגדרת מדיניות גישה ברמת הארגון

1. מוודאים שיש לכם מדיניות גישה ברמת הארגון. אם אין לכם מדיניות גישה ברמה הזו, מריצים את הפקודה הבאה ב-CLI של gcloud:

   gcloud access-context-manager policies create \
       --organization=ORGANIZATION_ID --title=POLICY_TITLE
   

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

   • ‫ORGANIZATION_ID: המזהה המספרי של הארגון.

   • ‫POLICY_TITLE: שם קריא לאנשים של מדיניות הגישה.

   מידע נוסף זמין במאמר יצירת מדיניות גישה ברמת הארגון.

2. איך מקבלים את השם של מדיניות הגישה

3. כדי להגדיר את מדיניות הגישה הזו כמדיניות ברירת המחדל, מריצים את הפקודה הבאה ב-CLI של gcloud:

   gcloud config set access_context_manager/policy POLICY_NAME
   

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

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

יצירת גבולות גזרה להגנה על פרויקט המארח של הרשת ועל פרויקט Cloud Storage

1. כדי ליצור גבולות גזרה sp1 סביב Project1, מריצים ב-CLI של gcloud את הפקודה הבאה:

   gcloud access-context-manager perimeters create sp1 --title="sp1" --resources=PROJECT_NUMBER \
       --restricted-services=storage.googleapis.com --policy=POLICY_NAME
   

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

   • ‫PROJECT_NUMBER: מספר הפרויקט של פרויקט המארח של הרשת. לדוגמה, projects/111.

   • ‫POLICY_NAME: השם המספרי של מדיניות הגישה. לדוגמה, 1234567890.

2. כדי ליצור גבולות גזרה sp2 סביב Project2 שמגבילים את שירות Cloud Storage, מריצים את הפקודה הבאה ב-CLI של gcloud:

   gcloud access-context-manager perimeters create sp2 --title="sp2" --resources=PROJECT_NUMBER \
       --restricted-services=storage.googleapis.com --policy=POLICY_NAME
   

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

   • ‫PROJECT_NUMBER: מספר הפרויקט של Cloud Storage. לדוגמה, projects/222.

   • ‫POLICY_NAME: השם המספרי של מדיניות הגישה. לדוגמה, 1234567890.

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

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

יצירת רמת גישה עם תנאי גישה שמבוסס על כתובת IP פנימית

יוצרים רמת גישה שמאפשרת רק תעבורה שמגיעה מתת-הרשת של VM1.

1. יוצרים קובץ YAML שמגדיר את תנאי הגישה. בדוגמה הבאה מוצגים רק המאפיינים שנדרשים להפעלת כתובת IP פנימית:

   echo """
   - vpcNetworkSources:
     - vpcSubnetwork:
         network: VPC_NETWORK_NAME
         vpcIpSubnetworks:
         - IP_RANGE
   
   """ > level.yaml
   

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

   • ‫VPC_NETWORK_NAME: השם של רשת ה-VPC שבה נמצא VM1. לדוגמה: //compute.googleapis.com/projects/Project1/global/networks/default.

   • ‫IP_RANGE: טווח כתובות ה-IP של רשת המשנה. לדוגמה, 10.10.0.0/24.

   משתמשים בשם רשת ה-VPC ובפורמטים של טווח כתובות ה-IP שמוסברים בהמשך.

   מידע נוסף על קובץ ה-YAML זמין במאמר basic-level-spec קובץ YAML.

2. כדי ליצור רמת גישה באמצעות קובץ YAML, מריצים את הפקודה הבאה ב-CLI של gcloud:

   gcloud access-context-manager levels create LEVEL_NAME \
       --title="TITLE" --basic-level-spec=FILE_NAME
   

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

   • ‫LEVEL_NAME: שם ייחודי לרמת הגישה. לדוגמה, allowvm1.

   • ‫TITLE: שם קצר וקריא לאנשים של רמת הגישה. לדוגמה, allowvm1.

   • ‫FILE_NAME: קובץ ה-YAML שמגדיר את תנאי הגישה לרמת הגישה. לדוגמה, level.yaml.

   מידע נוסף זמין במאמר בנושא יצירת בקרת גישה בסיסית.

הגדרת מדיניות כניסה כדי לאפשר תעבורת API נכנסת לקטגוריה של Cloud Storage

כדי לאפשר גישה רק מ-VM1, צריך להגדיר מדיניות כניסה בפרימטר VM1 כדי לאפשר לתנועה של Cloud Storage API להיכנס לפרימטר.sp2

1. יוצרים קובץ YAML שמגדיר את מדיניות הכניסה.

   echo """
   - ingressFrom:
       identityType: ANY_IDENTITY
       sources:
       - accessLevel: accessPolicies/POLICY_NAME/accessLevels/ACCESS_LEVEL_NAME
     ingressTo:
       operations:
       - methodSelectors:
         - method: '*'
         serviceName: storage.googleapis.com
       resources:
       - '*'
   
   """ > ingress.yaml
   

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

   • ‫POLICY_NAME: השם המספרי של מדיניות הגישה. לדוגמה, 1234567890.

   • ‫ACCESS_LEVEL_NAME: השם של רמת הגישה. לדוגמה, allowvm1.

   מידע נוסף על קובץ ה-YAML זמין במאמר בנושא הפניה לכללי Ingress.

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

   gcloud access-context-manager perimeters update PERIMETER --set-ingress-policies=FILE_NAME
   

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

   • ‫PERIMETER: השם של גבולות גזרה לשירות שמגנים על פרויקט Cloud Storage. לדוגמה, sp2.

   • ‫FILE_NAME: קובץ ה-YAML שמגדיר את מדיניות הכניסה. לדוגמה, ingress.yaml.

   מידע נוסף זמין במאמר בנושא עדכון מדיניות תעבורת הנתונים הנכנסת (ingress) ותעבורת הנתונים היוצאת (egress) של גבולות גזרה לשירות.

הגדרת מדיניות יציאה כדי לאפשר תעבורת נתונים יוצאת של API לקטגוריית Cloud Storage

בנוסף, צריך להגדיר מדיניות תעבורת נתונים יוצאת (egress) בהיקף sp1 כדי לאפשר לתעבורת נתונים של Cloud Storage API לצאת מההיקף.

1. יוצרים קובץ YAML שמגדיר את מדיניות היציאה. מוודאים שהשדה sourceRestriction מוגדר כ-SOURCE_RESTRICTION_ENABLED בקובץ ה-YAML.

   echo """
   - egressFrom:
       identityType: ANY_IDENTITY
       sourceRestriction: SOURCE_RESTRICTION_ENABLED
       sources:
       - accessLevel: accessPolicies/POLICY_NAME/accessLevels/ACCESS_LEVEL_NAME
     egressTo:
       operations:
       - methodSelectors:
         - method: '*'
         serviceName: storage.googleapis.com
       resources:
       - '*'
   
   """ > egress.yaml
   

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

   • ‫POLICY_NAME: השם המספרי של מדיניות הגישה. לדוגמה, 1234567890.

   • ‫ACCESS_LEVEL_NAME: השם של רמת הגישה. לדוגמה, allowvm1.

   מידע נוסף על קובץ ה-YAML זמין במאמר בנושא הפניה לכללי יציאה.

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

   gcloud access-context-manager perimeters update PERIMETER --set-egress-policies=FILE_NAME
   

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

   • ‫PERIMETER: השם של גבולות גזרה לשירות שמגן על פרויקט המארח ברשת. לדוגמה, sp1.

   • ‫FILE_NAME: קובץ ה-YAML שמגדיר את מדיניות היציאה. לדוגמה, egress.yaml.

   מידע נוסף זמין במאמר בנושא עדכון מדיניות תעבורת הנתונים הנכנסת (ingress) ותעבורת הנתונים היוצאת (egress) של גבולות גזרה לשירות.

אחרי שמגדירים את מדיניות תעבורת הנתונים הנכנסת (ingress) ותעבורת הנתונים היוצאת (egress), אפשר לגשת לקטגוריה של Cloud Storage מ-VM1, אבל אי אפשר לגשת לקטגוריה של Cloud Storage מ-VM2.

המלצות

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

• אם רוצים להפעיל העברת IP, מומלץ להשתמש בהגדרות הבאות כדי לצמצם את הסיכון לזיוף כתובת IP:

  • כדי לוודא שרק מכונות וירטואליות מורשות יכולות להפעיל העברת IP, משתמשים בRestrict VM IP Forwarding מגבלת מדיניות הארגון (constraints/compute.vmCanIpForward).

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

    • מגדירים כללים של חומת אש לתעבורת נתונים נכנסת (ingress) כדי לאפשר תעבורת נתונים נכנסת רק מטווח כתובות IP ספציפי למכונות הווירטואליות שבהן מופעלת העברת IP.

    • מגדירים כללים של חומת אש לתעבורת נתונים יוצאת (egress) כדי לאפשר תעבורת נתונים יוצאת רק לטווח כתובות IP ספציפי ממכונות וירטואליות שבהן מופעלת העברת IP.