פתרון בעיות נפוצות ב-VPC Service Controls בשירותי Google Cloud

בדף הזה מפורטים פתרונות לבעיות שאתם עשויים להיתקל בהן כשאתם משתמשים בGoogle Cloud שירות שנמצא בתוך service perimeter של VPC Service Controls.

בעיות ב-Cloud Build

יש כמה מגבלות ידועות לשימוש במשאבי Cloud Build בתוך מתחם היקפי של VPC Service Controls. מידע נוסף זמין במאמר מגבלות בשימוש ב-VPC Service Controls עם Cloud Build.

לחשבון השירות ב-Cloud Build אין גישה למשאבים מוגנים

מערכת Cloud Build משתמשת בחשבון השירות של Cloud Build כדי להפעיל גרסאות build בשמכם. כברירת מחדל, כשמריצים build ב-Cloud Build, ה-build רץ בפרויקט של דייר מחוץ לפרויקט שלכם.

המכונות הווירטואליות של העובדים ב-Cloud Build שמייצרות פלט של בנייה נמצאות מחוץ לגבולות הגזרה של VPC Service Controls, גם אם הפרויקט שלכם נמצא בתוך גבולות הגזרה. לכן, כדי שגרסאות ה-build יוכלו לגשת למשאבים בתוך המתחם ההיקפי, צריך לתת לחשבון השירות של Cloud Build גישה למתחם ההיקפי של VPC Service Controls. אפשר לעשות זאת על ידי הוספת החשבון לרמת הגישה או לכלל תעבורת הנתונים הנכנסת (ingress).

מידע נוסף זמין במאמר מתן גישה לחשבון השירות של Cloud Build להיקף של VPC Service Controls.

בעיות ב-Cloud Storage

דחיות כשמטרגטים קטגוריה לא קיימת של Cloud Storage לרישום ביומן

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

אפשר לעיין ביומן של דחיית הגישה באמצעות המזהה הייחודי של VPC Service Controls‏ (vpcServiceControlUniqueIdentifier). בהמשך מופיע יומן לדוגמה עם סיבת ההפרה RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER:

"serviceName": "storage.googleapis.com",
"methodName": "google.storage.buckets.update",
"resourceName": "projects/325183452875",
"metadata": {
  "violationReason": "RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER",
  ...
  "egressViolations": [
    {
      "sourceType": "Resource",
      "targetResource": "projects/0/buckets/this-bucket-does-not-exist",
      "source": "projects/325183452875/buckets/bucket-in-same-project",
      "servicePerimeter": "accessPolicies/875573620132/servicePerimeters/prod_perimeter"
    }]}

אם בשדה targetResource באובייקט egressViolations מוצג יעד עם projects/0/buckets, תמיד תופעל דחייה כי projects/0 לא קיים והוא נחשב מחוץ לגבולות ההיקף של השירות.

שגיאות סירוב כשמנסים לגשת לקטגוריות ציבוריות של Cloud Storage בבעלות Google

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

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

כדי לפתור את הבעיה, אפשר ליצור כללים לתעבורת נתונים נכנסת ויוצאת.

גישה לקטגוריה של Cloud Storage שזמינה לציבור מתוך היקף

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

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

בעיות ב-Security Command Center

בקטע הזה מפורטות הבעיות שאתם עשויים להיתקל בהן במהלך השימוש במשאבים של Security Command Center שנמצאים בתוך היקף של VPC Service Controls.

‫Security Command Center נחסם משליחת התראה ל-Pub/Sub

ניסיון לפרסם התראות של Security Command Center בנושא Pub/Sub בתוך מתחם אבטחה היקפית של VPC Service Controls נכשל עם הפרה של RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER.

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

כפתרון זמני, אפשר לבצע אחת מהפעולות הבאות:

  • שימוש בנושא Pub/Sub בפרויקט שלא נמצא בפרימטר של שירות.
  • מסירים את Pub/Sub API מגבולות הגזרה לשירות עד להשלמת ההגדרה של ההתראות.

מידע נוסף על הפעלת התראות של Security Command Center שנשלחות לנושא Pub/Sub זמין במאמר הפעלת התראות על ממצאים ב-Pub/Sub.

מרכז האבטחה נחסם מסריקת משאבי Compute Engine בתוך היקף

‫Security Command Center סורק את המשאבים ב-Compute Engine בפרויקטים שלכם באמצעות חשבון שירות לכל מוצר ולכל פרויקט (P4SA) service-{project_number}@gcp-sa-computescanning.iam.gserviceaccount.com. כדי ש-Security Command Center יוכל לגשת למשאבים בתוך גבולות הגזרה, צריך להוסיף את P4SA לרמת הגישה או לכלל התעבורה הנכנסת. אחרת, יכול להיות שתופיע שגיאת NO_MATCHING_ACCESS_LEVEL.

‫Security Command Center נחסם מסריקת משאבים בתוך גבולות גזרה לשירות

‫Security Health Analytics סורק משאבים בפרויקטים באמצעות P4SA (חשבון שירות לכל מוצר ולכל פרויקט) service-org-ORGANIZATION_ID@security-center-api.iam.gserviceaccount.com. כדי ש-Security Command Center יוכל לגשת למשאבים בתוך גבולות הגזרה, צריך להוסיף את חשבון P4SA לרמת הגישה או לכלל הכניסה. אחרת, תופיע השגיאה NO_MATCHING_ACCESS_LEVEL.

בעיות ב-Google Kubernetes Engine

בסעיף הזה מפורטות הבעיות שאולי תיתקלו בהן כשמשתמשים במשאבי Google Kubernetes Engine שנמצאים בתוך service perimeter של VPC Service Controls.

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

השירות autoscaling.googleapis.com לא משולב עם VPC Service Controls, ולכן אי אפשר להוסיף אותו לשירותים המוגבלים או לשירותים שאפשר לגשת אליהם. אי אפשר לאפשר את השימוש ב-autoscaling.googleapis.com API בשירותים נגישים. לכן, יכול להיות שהמידרוג האוטומטי של אשכולות שקיימים בגבולות גזרה עם שירותים נגישים לא יפעל.

אנחנו ממליצים לא להשתמש בשירותים נגישים. כשמשתמשים בכתובת IP וירטואלית (VIP) מוגבלת, צריך ליצור חריגה לכתובת autoscaling.googleapis.com כדי לעבור לכתובת VIP פרטית בגבולות גזרה שמכיל אשכול עם התאמה אוטומטית לעומס.

בעיות ב-BigQuery

בקטע הזה מפורטות הבעיות שאתם עשויים להיתקל בהן במהלך השימוש במשאבי BigQuery שנמצאים בתוך service perimeter של VPC Service Controls.

הגבלות ההיקף של VPC Service Controls לא חלות על ייצוא של תוצאות שאילתות ב-BigQuery

אם אתם מנסים להגביל את הייצוא של נתונים מוגנים מ-BigQuery אל Google Drive,‏ Google Sheets או Data Studio, יכול להיות שתראו חריגה מההתנהגות הצפויה. כשמריצים שאילתה מממשק המשתמש של BigQuery, התוצאות נשמרות בזיכרון המקומי של המחשב, כמו מטמון הדפדפן. המשמעות היא שהתוצאות נמצאות עכשיו מחוץ ל-VPC Service Controls, כך שאולי תוכלו לשמור את התוצאות בקובץ CSV או ב-Google Drive.

בתרחיש הזה, VPC Service Controls פועל כמצופה כי התוצאה מיוצאת ממחשב מקומי שנמצא מחוץ להיקף השירות, אבל ההגבלה הכוללת על נתוני BigQuery נעקפת.

כדי לפתור את הבעיה הזו, צריך להגביל את הרשאות ה-IAM של המשתמשים על ידי הסרת ההרשאה bigquery.tables.export. שימו לב: פעולה כזו משביתה את כל אפשרויות הייצוא.

בעיות ב-GKE Enterprise

בקטע הזה מפורטות הבעיות שאתם עלולים להיתקל בהן במהלך השימוש במשאבי GKE Enterprise שנמצאים בתוך perimeter של VPC Service Controls.

כדי לפתור בעיות שקשורות לשימוש ב-VPC Service Controls עם Cloud Service Mesh, אפשר לעיין במאמר פתרון בעיות ב-VPC Service Controls ב-Cloud Service Mesh מנוהל.

הגדרה של GKE Enterprise Config Controller יוצרת הפרה של תעבורת נתונים יוצאת (egress)

התהליך של הגדרת GKE Enterprise Config Controller צפוי להיכשל אם אין הגדרת יציאה שמאפשרת להגיע אל containerregistry.googleapis.com באמצעות השיטה google.containers.registry.read בפרויקט מחוץ להיקף.

כדי לפתור את השגיאה, צריך ליצור את כלל היציאה הבא:

From:
  Identities:ANY_IDENTITY
To:
  Projects =
    NNNNNNNNNNNN
  Service =
  Service name: containerregistry.googleapis.com
  Service methods:
    containers.registry.read

הפרת היציאה נעלמת אחרי שמוסיפים את הכלל למתחם שהופר.

בעיות ב-Container Registry

בקטע הזה מפורטות הבעיות שאתם עשויים להיתקל בהן במהלך השימוש במשאבי Container Registry שנמצאים בתוך היקף של VPC Service Controls.

בקשות ל-Container Registry API נחסמות על ידי VPC Service Controls למרות שהן מותרות בכלל תעבורת נתונים נכנסת (ingress) או יוצאת (egress)

אם אפשרתם גישה ל-Container Registry באמצעות כללי תעבורת נתונים נכנסת (ingress) עם השדה identity_type שמוגדר לערך ANY_USER_ACCOUNT או ANY_SERVICE_ACCOUNT, הגישה נחסמת על ידי VPC Service Controls.

כדי לפתור את הבעיה, צריך לעדכן את השדה identity_type ל-ANY_IDENTITY בכלל הכניסה או היציאה.

שגיאות תעבורת נתונים יוצאת (egress) מסוכן שירות בזמן העתקה של קובץ אימג' של Docker בבעלות Artifact Registry לפרויקט בגבולות גזרה

כשמנסים להעתיק תמונה בבעלות Artifact Registry לפרויקט שנמצא בגבולות גזרה של VPC Service Controls, יכול להיות שתיתקלו בשגיאות תעבורת נתונים יוצאת (egress) ביומנים מסוכן השירות cloud-cicd-artifact-registry-copier@system.gserviceaccount.com. שגיאת היציאה הזו מתרחשת בדרך כלל כשהמדיניות לגבי היקף הארגון מוגדרת למצב הרצה יבשה.

כדי לפתור את הבעיה, צריך ליצור כלל תעבורת נתונים יוצאת (egress) שמאפשר לסוכן השירות cloud-cicd-artifact-registry-copier@system.gserviceaccount.com גישה לשירות storage.googleapis.com בפרויקט שמופיע ביומני השגיאות של VPC Service Controls.

בעיות ב-Vertex AI

בקטע הזה מפורטות הבעיות שאתם עשויים להיתקל בהן במהלך השימוש במשאבי Vertex AI שנמצאים בתוך service perimeter של VPC Service Controls.

בקשות ל-User-managed notebooks API נחסמות על ידי VPC Service Controls למרות שהן מותרות בכלל תעבורת נתונים נכנסת (ingress) או יוצאת (egress)

אם אפשרתם גישה ל-User-managed notebooks API באמצעות מדיניות כניסה והגדרתם את identity_type כ-ANY_USER_ACCOUNT או כ-ANY_SERVICE_ACCOUNT, מערכת VPC Service Controls חוסמת את הגישה ל-API.

כדי לפתור את הבעיה, צריך לעדכן את השדה identity_type ל-ANY_IDENTITY בכלל הכניסה או היציאה.

בעיות ב-Spanner

גיבוי מסד הנתונים של Spanner נחסם בגלל ההפרה NO_MATCHING_ACCESS_LEVEL מחשבון השירות לכל מוצר ולכל פרויקט (P4SA) service-PROJECT_NUMBER@gcf-admin-robot.iam.gserviceaccount.com.

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

בעיות ב-AlloyDB ל-PostgreSQL

אם קלאסטר AlloyDB ל-PostgreSQL מוגן על ידי CMEK, יכול להיות שתיתקלו בשגיאות כניסה ביומנים מסוכני שירות service-PROJECT_NUMBER@compute-system.iam.gserviceaccount.com ו-service-PROJECT_NUMBER@gs-project-accounts.iam.gserviceaccount.com.

כדי לפתור את הבעיה, צריך להוסיף כלל תעבורת נתונים נכנסת (ingress) עם גישה לסוכני השירות שצוינו אל השירות cloudkms.googleapis.com בפרויקט שמוזכר ביומני השגיאות של VPC Service Controls.

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