שימוש ב-VPC Service Controls עם נקודות קצה של קטלוג מאוחד

בקטלוג הייעודי לזמן ריצה של Lakehouse, כללי ההיקף של VPC Service Controls לנקודות קצה של קטלוג מאוחד מאפשרים לשלוח שאילתות לטבלאות Apache Iceberg חיצוניות ב-BigQuery, תוך מניעת זליגת נתונים. אםGoogle Cloud הפרויקטים או הקטגוריות של Cloud Storage נמצאים בתוך גבולות גזרה לשירות, אתם יכולים להגדיר כללים לתעבורת נתונים יוצאת (egress) ל-Amazon S3 ול-Microsoft Azure Data Lake Storage (ADLS) Gen2, או כללים לתעבורת נתונים נכנסת (ingress) ל-Cloud Storage. הכללים האלה מאשרים רענון של מטא-נתונים ברקע ושאילתות לטבלאות שרשומות ב-AWS Glue Data Catalog, ב-Databricks Unity Catalog, ב-Snowflake Horizon Catalog וב-Workday Data Lake.

אם הפרויקטים שלכם לא נמצאים בתוך גבולות גזרה לשירות, נקודות הקצה של הקטלוג המאוחד פועלות בלי הגדרה של VPC Service Controls. לחיבורים חוצי-עננים ל-SAP Business Data Cloud‏ (SAP BDC), ראו הגדרת VPC Service Controls ל-SAP BDC. כדי להגן על קטגוריות שאליהן ניגשים דרך נקודת הקצה של קטלוג Apache Iceberg REST במצב הנפקת פרטי כניסה, קראו את המאמר שימוש ב-VPC Service Controls עם הנפקת פרטי כניסה.

לפני שמתחילים

  1. מגדירים נקודת קצה של קטלוג מאוחד ל-AWS Glue Data Catalog, ל-Databricks Unity Catalog, ל-Snowflake Horizon Catalog או ל-Workday Data Lake.

  2. יוצרים לפרויקטים גבולות גזרה לשירות, בהתאם למיקום שבו מאוחסנים קובצי הטבלאות:

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

התפקידים הנדרשים

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

  • הגדרת גבולות גזרה לשירות ומדיניות תעבורת נתונים נכנסת או יוצאת: עריכת Access Context Manager ‏(roles/accesscontextmanager.policyEditor)

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

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

תרחישי שימוש וכללי היקף נדרשים

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

תרחיש לדוגמה כלל נדרש לגבי גבולות הגזרה שלבי ההגדרה
שליחת שאילתות לטבלאות חוצות-עננים ב-Amazon S3 או ב-ADLS Gen2: שליחת שאילתות לטבלאות Apache Iceberg בקטגוריות של s3:// או במאגרים של abfss:// דרך נקודת קצה של קטלוג מאוחד בפרויקט BigQuery מוגן, תוך חסימת תעבורת נתונים יוצאת לא מורשית. מוסיפים כלל תעבורת נתונים יוצאת (egress) במתחם ההיקפי של הפרויקט של נקודת הקצה של הקטלוג, שמאפשר גם לחשבון השירות של blirc-... של נקודת הקצה של הקטלוג וגם לחשבונות המשתמשים של השאילתה לקרוא את הקטגוריות או המאגרים החיצוניים שאושרו. מאתרים את חשבון השירות של נקודת הקצה של הקטלוג, ואז מוסיפים כלל תעבורת נתונים יוצאת (egress) לאחסון בענן חיצוני.
גישה לטבלאות של קטלוגים חיצוניים בקטגוריות מוגנות של Cloud Storage: שליחת שאילתות לטבלאות של Databricks Unity Catalog או Snowflake Horizon Catalog שמאוחסנות בקטגוריה של gs:// בתוך היקף שמגביל את storage.googleapis.com (גם באותו פרויקט והיקף כמו נקודת הקצה של הקטלוג המאוחד). מוסיפים כלל תעבורת נתונים נכנסת (ingress) במתחם ההיקפי של הפרויקט של הקטגוריה של Cloud Storage, שמאפשר לחשבון השירות של הקטלוג המרוחק Google Cloud לגשת אל storage.googleapis.com. הוספת כלל תעבורת נתונים נכנסת (ingress) לקטגוריות של Cloud Storage בגבולות הגזרה לשירות.
לאפשר שאילתות מגורמים מחוץ להיקף של נקודת הקצה של הקטלוג: להריץ משימות BigQuery בפרויקט של נקודת הקצה של הקטלוג מחשבונות של מנתחי נתונים, מכלי BI או מחשבונות שירות של עומסי עבודה שנמצאים מחוץ להיקף. מוסיפים כלל כניסה בהיקף של הפרויקט של נקודת הקצה של הקטלוג, שמאפשר למבצעי הקריאות החיצוניים לגשת אל bigquery.googleapis.com ואל biglake.googleapis.com, בנוסף לכלל האחסון של מיקום הטבלה. מגדירים את כניסת המתקשרים באמצעות חומרי העזר בנושא כללי כניסה, ואז פועלים לפי תהליך האחסון של מיקום הטבלה.

איך VPC Service Controls בודק את תעבורת הנתונים בנקודת הקצה של הקטלוג המאוחד

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

  • אחסון חיצוני בענן (Amazon S3 או Azure Data Lake Storage Gen2): ב-VPC Service Controls מתבצעת הערכה של תעבורת הנתונים היוצאת מגבולות הגזרה לשירות של פרויקט נקודת הקצה של הקטלוג, בהשוואה לזהות של מבצע הקריאה ב-Google Cloud ולקטגוריה או למאגר החיצוניים של היעד:

    פעולה הזהות נבדקה המשאב שנבדק
    רענון מטא-נתונים ברקע חשבון השירות של Lakehouse שהוקצה אוטומטית לנקודת הקצה של הקטלוג (blirc-PROJECT_NUMBER-ID@gcp-sa-biglakerestcatalog.iam.gserviceaccount.com) הקטגוריה או מאגר הנתונים החיצוניים שמכילים את המטא-נתונים של Apache Iceberg בטבלה
    שאילתה חשבון המשתמש או חשבון השירות שמריץ את המשימה ב-BigQuery הקטגוריות או הקונטיינרים החיצוניים שמכילים את המטא-נתונים ואת קובצי הנתונים של הטבלה

    בטבלאות שמאוחסנות ב-Amazon S3 או ב-ADLS Gen2, כלל התעבורה היוצאת של ההיקף צריך לכלול את כל הפרטים הבאים:

    • זהויות: גם חשבון השירות של נקודת הקצה של הקטלוג וגם חשבונות המשתמשים של השאילתה.
    • משאבים חיצוניים: כל קטגוריה או מאגר שהטבלאות משתמשות בהם למטא-נתונים ולקובצי נתונים.
    • פעולות: גם bigquery.googleapis.com (עם ההרשאה externalResource.read) וגם biglake.googleapis.com (עם כל השיטות, '*').

  • ‫Cloud Storage (מיקומים חיצוניים של Databricks Unity Catalog או Snowflake Horizon Catalog ב- Google Cloud): גם במהלך רענון המטא-נתונים ברקע וגם במהלך שאילתות ב-BigQuery, ‏BigQuery ו-Lakehouse קוראים מ-Cloud Storage באמצעות פרטי הכניסה עם ההיקף המצומצם שסופקו על ידי הקטלוג המרוחק, ולא באמצעות חשבון השירות של blirc-... בנקודת הקצה של הקטלוג. כשהפרויקט של הקטגוריה של Cloud Storage נמצא בתוך גבולות גזרה לשירות שמגבילים את storage.googleapis.com, ‏storage.googleapis.com מעריך את חשבון השירות של הקטלוג המרוחק של Google Cloud כזהות חיצונית שמנסה להיכנס לגבולות הגזרה. הבדיקה הזו מתבצעת גם אם הקטגוריה נמצאת באותו פרויקט ובאותם גבולות גזרה לשירות כמו נקודת הקצה של הקטלוג המאוחד. צריך להוסיף כלל תעבורת נתונים נכנסת (ingress) לגבולות הגזרה לשירות של הפרויקט של הקטגוריה, שמאפשר לחשבון השירות של הקטלוג המרוחקGoogle Cloud לגשת אל storage.googleapis.com.

ב-VPC Service Controls מתבצעת הערכה רק של פעולות קריאה מהאחסון שמתבצעות על ידי BigQuery ו-Lakehouse (biglake.googleapis.com). לא מתבצעת הערכה של קריאות ש-Lakehouse מבצע לנקודת קצה ל-API של הקטלוג המרוחק (כמו הצגת מרחבי שמות וטבלאות), ואין ניהול של מנועי שאילתות חיצוניים שקוראים ישירות מהאחסון.

פורמטים של משאבים חיצוניים

ציינו משאבים חיצוניים בכללי תעבורת נתונים יוצאת בתור URI מדויק של קטגוריה או מאגר. אין תמיכה בנתיבי אובייקטים ובתווים כלליים לחיפוש. שמות של קטגוריות, מאגרים וחשבונות אחסון חייבים להיות באותיות קטנות. כללים שמכילים אותיות רישיות בשמות האלה יידחו כשתשמרו את הכלל. אי אפשר להחליף בין מזהי URI של Azure Data Lake Storage Gen2 (abfss://) ושל Azure Blob Storage (azure://) בכללים לתעבורת נתונים יוצאת של VPC Service Controls. בנקודות קצה של קטלוג מאוחד, צריך לציין את הפורמט abfss://.

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

שירות אחסון פורמט דוגמה
Amazon S3 s3://BUCKET_NAME s3://my-iceberg-warehouse
Azure Data Lake Storage Gen2 abfss://CONTAINER@STORAGE_ACCOUNT.dfs.core.windows.net abfss://unity-catalog-storage@mystorageaccount.dfs.core.windows.net

איך מוצאים את חשבון השירות של נקודת הקצה של הקטלוג

כשיוצרים נקודת קצה של קטלוג מאוחד, Lakehouse מקצה חשבון שירות ייעודי לכל נקודת קצה. בטבלאות ב-Cloud Storage, דלגו לקטע הוספת כלל תעבורת נתונים נכנסת לקטגוריות של Cloud Storage בגבולות גזרה לשירות. אם הטבלאות מאוחסנות ב-Amazon S3 או ב-ADLS Gen2, צריך לאחזר את כתובת האימייל של חשבון השירות הזה בשביל כלל התעבורה היוצאת:

gcloud biglake iceberg catalogs describe CATALOG_ID \
    --project=PROJECT_ID \
    --format='value(biglake-service-account)'

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

  • ‫CATALOG_ID: המזהה של נקודת הקצה של הקטלוג המאוחד.
  • ‫PROJECT_ID: המזהה של הפרויקט ב- Google Cloudשמכיל את נקודת הקצה של הקטלוג המאוחד.

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

blirc-PROJECT_NUMBER-ID@gcp-sa-biglakerestcatalog.iam.gserviceaccount.com

הוספת כלל לתעבורת נתונים יוצאת (egress) לאחסון בענן חיצוני

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

המסוף

  1. נכנסים לדף VPC Service Controls במסוף Google Cloud .

    כניסה ל-VPC Service Controls

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

  3. לוחצים על Edit, ובקטע Egress policy לוחצים על Add an egress rule.

  4. בקטע From, בקטע Identities, בוחרים באפשרות Select identities & groups, לוחצים על Add identities ומוסיפים את חשבון השירות של נקודת הקצה של הקטלוג ואת המשתמשים או חשבונות השירות שמריצים שאילתות.

  5. בקטע אל:

    1. בוחרים באפשרות External resources, לוחצים על Add resources, מזינים כל קטגוריה ב-s3:// או מאגר ב-abfss:// שבהם הטבלאות משתמשות, ולוחצים על Add external resources.
    2. בקטע Operations or IAM roles, מגדירים את השירותים הבאים בטבלה API operations:
      • ‫BigQuery API ‏(bigquery.googleapis.com): כדי להגביל את הרשאת הגישה של רשומת ברירת המחדל של כל השיטות (*) לקריאה בלבד, פותחים את תפריט הפעולות של bigquery.googleapis.com ולוחצים על Edit, בוחרים באפשרות Select methods, בוחרים בהרשאה externalResource.read ולוחצים על Add selected methods.
      • ‫BigLake API ‏(biglake.googleapis.com): לוחצים על Add operations, בוחרים באפשרות BigLake API ‏(biglake.googleapis.com), בוחרים באפשרות All methods ולוחצים על Add all methods.

  6. לוחצים על Save.

‫CLI של gcloud

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

    - egressFrom:
    identities:
    - serviceAccount:CATALOG_ENDPOINT_SERVICE_ACCOUNT
    - user:QUERY_USER_EMAIL
  egressTo:
    externalResources:
    - s3://S3_BUCKET_NAME
    - abfss://ADLS_CONTAINER@STORAGE_ACCOUNT.dfs.core.windows.net
    operations:
    - serviceName: bigquery.googleapis.com
      methodSelectors:
      - permission: externalResource.read
    - serviceName: biglake.googleapis.com
      methodSelectors:
      - method: '*'

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

    • ‫CATALOG_ENDPOINT_SERVICE_ACCOUNT: כתובת האימייל של חשבון השירות של נקודת הקצה של הקטלוג, שאותה אחזרתם קודם.
    • ‫QUERY_USER_EMAIL: כתובת האימייל של משתמש או של חשבון שירות שמריץ שאילתות דרך נקודת הקצה של הקטלוג המאוחד. בחשבון שירות, משתמשים בקידומת serviceAccount: במקום ב-user:. לחלופין, מחליפים את identities ב-identityType: ANY_IDENTITY כדי לאפשר לכל חשבון ראשי להיות בהיקף.
    • ‫S3_BUCKET_NAME, ADLS_CONTAINER ו-STORAGE_ACCOUNT: מיקומי האחסון החיצוניים שבהם נמצאים המטא-נתונים וקובצי הנתונים של הטבלה. צריך לכלול רק את הרשומות שרלוונטיות לספק האחסון שלכם.

  2. מאתרים את המזהה המספרי של מדיניות בקרת הגישה של הארגון:

    gcloud access-context-manager policies list \
    --organization=ORGANIZATION_ID \
    --format='value(name)'

    מחליפים את ORGANIZATION_ID במזהה הארגון המספרי.

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

    gcloud access-context-manager perimeters update PERIMETER_NAME \
    --policy=POLICY_ID \
    --set-egress-policies=egress.yaml

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

    • ‫PERIMETER_NAME: השם של גבולות הגזרה לשירות.
    • ‫POLICY_ID: המזהה המספרי של מדיניות הגישה.

    כדי לבדוק את הכלל לפני האכיפה, צריך להחיל אותו על הגדרת הרצה לניסיון באמצעות gcloud access-context-manager perimeters dry-run update, ולאכוף אותו אחרי האימות באמצעות gcloud access-context-manager perimeters dry-run enforce.

  4. מוודאים שהכלל פעיל:

    gcloud access-context-manager perimeters describe PERIMETER_NAME \
    --policy=POLICY_ID \
    --format='yaml(status.egressPolicies)'

הוספת כלל לתעבורת נתונים נכנסת לקטגוריות של Cloud Storage בגבולות הגזרה לשירות

אם טבלאות בקטלוג מרוחק (כמו Databricks Unity Catalog או Snowflake Horizon Catalog) מאוחסנות בקטגוריה של Cloud Storage שמוגנת על ידי גבולות גזרה שמגבילים את storage.googleapis.com, צריך להוסיף כלל תעבורת נתונים נכנסת לגבולות הגזרה לשירות של הפרויקט של הקטגוריה. מכיוון ש-BigQuery ו-Lakehouse מאמתים את Cloud Storage באמצעות חשבון השירות של Google Cloud בקטלוג המרוחק (ולא באמצעות חשבון השירות של blirc-...), הכלל הזה נדרש גם כשהקטגוריה נמצאת באותו פרויקט ובאותה סביבה כמו נקודת הקצה של הקטלוג המאוחד.

המסוף

  1. נכנסים לדף VPC Service Controls במסוף Google Cloud .

    כניסה ל-VPC Service Controls

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

  3. לוחצים על Edit, ובקטע Ingress policy לוחצים על Add an ingress rule.

  4. בקטע מאת:

    1. בקטע Identities, לוחצים על Select identities & groups, ואז על Add identities ומוסיפים את חשבון השירות Google Cloud שהוקצה על ידי הקטלוג המרוחק לקטגוריה של Cloud Storage.
    2. בקטע מקורות, בוחרים באפשרות כל המקורות (או באפשרות בחירת מקורות כדי לציין רמת גישה).

  5. בקטע אל:

    1. בקטע משאבים, לוחצים על בחירת משאבים. בכרטיסייה Projects, לוחצים על Add projects, בוחרים את הפרויקט שמכיל את הקטגוריה של Cloud Storage ולוחצים על Add selected projects.
    2. בקטע Operations or IAM roles, לוחצים על Select operations, ואז על Add operations, בוחרים באפשרות Cloud Storage API (storage.googleapis.com), לוחצים על All methods ואז על Add all methods. לחלופין, בוחרים באפשרות Select methods כדי לבחור שיטות שירות ספציפיות נתמכות (כמו google.storage.objects.get,‏ google.storage.objects.list ו-google.storage.buckets.get), ולוחצים על Add selected methods.

  6. לוחצים על Save.

‫CLI של gcloud

  1. יוצרים קובץ בשם ingress.yaml שמאפשר לחשבון השירות שלGoogle Cloud בקטלוג המרוחק לגשת אל storage.googleapis.com בפרויקט של הקטגוריה. הסכימה המלאה מופיעה בחומר העזר בנושא כללי תעבורת נתונים נכנסת.

    - ingressFrom:
    identities:
    - serviceAccount:REMOTE_CATALOG_GCS_SERVICE_ACCOUNT
    sources:
    - accessLevel: '*'
  ingressTo:
    operations:
    - serviceName: storage.googleapis.com
      methodSelectors:
      - method: '*'
    resources:
    - projects/BUCKET_PROJECT_NUMBER

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

    • ‫REMOTE_CATALOG_GCS_SERVICE_ACCOUNT: כתובת האימייל של חשבון השירות שנוצר על ידי הקטלוג המרוחק כדי לגשת לקטגוריה של Cloud Storage (לדוגמה, מ-DESCRIBE STORAGE CREDENTIAL ב-Databricks Unity Catalog או מ-DESC EXTERNAL VOLUME ב-Snowflake Horizon Catalog).Google Cloud
    • ‫BUCKET_PROJECT_NUMBER: מספר הפרויקט שמכיל את הקטגוריה של Cloud Storage.

  2. מאתרים את המזהה המספרי של מדיניות בקרת הגישה של הארגון:

    gcloud access-context-manager policies list \
    --organization=ORGANIZATION_ID \
    --format='value(name)'

    מחליפים את ORGANIZATION_ID במזהה הארגון המספרי.

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

    gcloud access-context-manager perimeters update BUCKET_PERIMETER_NAME \
    --policy=POLICY_ID \
    --set-ingress-policies=ingress.yaml

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

    • ‫BUCKET_PERIMETER_NAME: השם של גבולות הגזרה לשירות שמגינים על הפרויקט של הקטגוריה.
    • ‫POLICY_ID: המזהה המספרי של מדיניות הגישה.

    כדי לבדוק את הכלל לפני האכיפה, צריך להחיל אותו על הגדרת הרצה לניסיון באמצעות gcloud access-context-manager perimeters dry-run update, ולאכוף אותו אחרי האימות באמצעות gcloud access-context-manager perimeters dry-run enforce.

  4. מוודאים שהכלל פעיל:

    gcloud access-context-manager perimeters describe BUCKET_PERIMETER_NAME \
    --policy=POLICY_ID \
    --format='yaml(status.ingressPolicies)'

אימות ההגדרות האישיות

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

  1. מחכים לסיום המחזור הבא של רענון המטא-נתונים המתוזמן ברקע, ואז בודקים את יומני הביקורת של דחיית המדיניות ב-Cloud Audit Logs כדי לוודא שאין הפרות של VPC Service Controls. רענון המטא-נתונים ברקע פועל באופן אוטומטי לפי לוח הזמנים של הרענון, ואי אפשר להפעיל אותו באופן ידני.

    ב-Logs Explorer, בוחרים את הפרויקט המוגן – הפרויקט של נקודת הקצה של הקטלוג לאחסון בענן חיצוני, או הפרויקט של הקטגוריה של Cloud Storage לטבלאות של Cloud Storage. מידע נוסף זמין במאמר אחזור שגיאות של VPC Service Controls מיומני הביקורת. מריצים את השאילתה הבאה:

    log_id("cloudaudit.googleapis.com/policy")
protoPayload.metadata.@type:"type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"

    אם רשומות של הפרות מופיעות אחרי שהכלל מופץ, בודקים את השדות egressViolations.targetResource,‏ ingressViolations.targetResource ו-authenticationInfo.principalEmail ברשומת היומן כדי לוודא שהם תואמים למשאבים ולזהויות שבכלל. אם טבלאות חדשות לא מסתנכרנות ולא מופיעות רשומות של VpcServiceControlAuditMetadata, צריך לבדוק את ההרשאות ואת פרטי הכניסה של הקטלוג המרוחק. אפשר לקרוא מידע נוסף במאמר פתרון בעיות בגישה לנתונים חוצי-עננים.

  2. מריצים שאילתת בדיקה על טבלה ב-BigQuery באמצעות מוסכמת מתן השמות P.C.N.T‏ (Project.Catalog.Namespace.Table) שמורכבת מארבעה חלקים:

    SELECT COUNT(*)
FROM `PROJECT_ID.CATALOG_ID.NAMESPACE.TABLE_NAME`;

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

    • ‫PROJECT_ID: המזהה של הפרויקט ב- Google Cloudשמכיל את נקודת הקצה של הקטלוג המאוחד.
    • ‫CATALOG_ID: המזהה של נקודת הקצה של הקטלוג המאוחד.
    • ‫NAMESPACE: מרחב השמות בנקודת הקצה של הקטלוג המאוחד.
    • ‫TABLE_NAME: שם של טבלה במרחב השמות.

    אם שאילתה נחסמת על ידי VPC Service Controls, הודעת השגיאה כוללת ערך של vpcServiceControlsUniqueIdentifier. מסננים את יומני הביקורת של Policy Denied ב-Logs Explorer על ידי התאמת protoPayload.metadata.vpcServiceControlsUniqueId למזהה הזה:

    log_id("cloudaudit.googleapis.com/policy")
protoPayload.metadata.@type:"type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"
protoPayload.metadata.vpcServiceControlsUniqueId="UNIQUE_IDENTIFIER"

    מחליפים את UNIQUE_IDENTIFIER בערך של vpcServiceControlsUniqueIdentifier מהודעת השגיאה.

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