מידע על גישה לממשקי Google API גלובליים דרך נקודות קצה

במאמר הזה מוסבר על נקודות קצה של Private Service Connect שמשמשות לגישה לממשקי Google APIs גלובליים.

כברירת מחדל, אם יש לכם אפליקציה שמשתמשת בשירות Google, כמו Cloud Storage, האפליקציה מתחברת לשם ה-DNS שמוגדר כברירת מחדל לשירות הזה, כמו storage.googleapis.com. שמות ה-DNS שמוגדרים כברירת מחדל לשירותי Google מומרים לכתובות IP שניתנות לניתוב ציבורי. עם זאת, תעבורת נתונים שנשלחת מGoogle Cloud משאבים לכתובות ה-IP האלה נשארת בתוך הרשת של Google.

באמצעות Private Service Connect, אתם יכולים ליצור נקודות קצה פרטיות באמצעות כתובות IP פנימיות גלובליות ברשת ה-VPC שלכם. אפשר להקצות שמות DNS לכתובות ה-IP הפנימיות האלה עם שמות בעלי משמעות כמו storage-vialink1.p.googleapis.com ו-bigtable-adsteam.p.googleapis.com. השמות וכתובות ה-IP האלה הם פנימיים לרשת ה-VPC ולכל רשת מקומית שמחוברת אליה באמצעות מנהרות Cloud VPN או קבצים מצורפים של VLAN. אתם יכולים לקבוע איזו תנועה תועבר לאיזה נקודת קצה, ולהוכיח שהתנועה נשארת בתוך Google Cloud.

האפשרות הזו מאפשרת לכם לגשת לכל Google APIs והשירותים של Google שכלולים בחבילות ה-API.

איור 1. ‫Private Service Connect מאפשר לכם לשלוח תנועה לממשקי Google APIs באמצעות נקודת קצה (endpoint) שהיא פרטית לרשת ה-VPC שלכם (אפשר ללחוץ כדי להגדיל).

תכונות ותאימות

בטבלה הזו מפורטות התכונות שנתמכות בנקודות קצה שמשמשות לגישה לממשקי Google API גלובליים.

הגדרות אישיות פרטים
הגדרת צרכן (נקודת קצה)
זמינות גלובלית משתמש בכתובת IP פנימית גלובלית
תנועה ב-Cloud Interconnect
תנועה ב-Cloud VPN
גישה באמצעות קישור בין רשתות VPC שכנות (peering)
הפצת חיבורים דרך NCC (תצוגה מקדימה)
הגדרה אוטומטית של DNS
גרסת ה-IP IPv4
Producer
שירותים נתמכים ממשקי Google API גלובליים נתמכים

גישה היברידית

אפשר לגשת לנקודות קצה של Private Service Connect שמשמשות לגישה לממשקי Google APIs ממארחים מקומיים מחוברים נתמכים. מידע נוסף זמין במאמר גישה לנקודת הקצה ממארחים מקומיים.

הגדרת DNS אוטומטית דרך Service Directory

נקודות הקצה רשומות בספריית השירותים. Service Directory היא פלטפורמה לאחסון, לניהול ולפרסום של שירותים. כשיוצרים נקודת קצה לגישה ל-Google APIs ולשירותים של Google, בוחרים אזור ומרחב שמות של Service Directory.

אזור Service Directory

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

כשיוצרים את נקודת הקצה הראשונה ל-Google APIs ברשת VPC, האזור שבוחרים משמש כאזור ברירת המחדל לכל נקודות הקצה הבאות שנוצרות באותה רשת. אם לא הוגדר אזור לרשת, ולא תציינו אזור, האזור יוגדר ל-us-central1. כל נקודות הקצה ברשת צריכות להשתמש באותו אזור של Service Directory.

מרחב שמות של Service Directory

כשיוצרים את נקודת הקצה הראשונה ל-Google APIs ברשת VPC, מרחב השמות שבוחרים משמש כמרחב השמות שמוגדר כברירת מחדל לכל נקודות הקצה הבאות שנוצרות ברשת הזו. אם מרחב השמות לא מוגדר כבר לרשת, ולא מציינים מרחב שמות, נעשה שימוש במרחב שמות שנוצר על ידי המערכת. כל נקודות הקצה ברשת צריכות להשתמש באותו מרחב שמות של Service Directory. מרחב השמות שבוחרים צריך לשמש רק נקודות קצה שמשמשות לגישה לממשקי Google API. אפשר להשתמש באותו מרחב שמות לנקודות קצה בכמה רשתות.

כשיוצרים נקודת קצה, נוצרות הגדרות ה-DNS הבאות:

  • נוצר אזור DNS פרטי של Service Directory בשביל p.googleapis.com.

  • רשומות DNS נוצרות ב-p.googleapis.com עבור חלק משירותי Google ומממשקי Google API הנפוצים שזמינים באמצעות Private Service Connect, ויש להם שמות DNS שמוגדרים כברירת מחדל ומסתיימים ב-googleapis.com. לדוגמה, אם שם נקודת הקצה הוא xyz, רשומות DNS נוצרות עבור storage-xyz.p.googleapis.com, compute-xyz.p.googleapis.com וממשקי API נפוצים אחרים בחבילת ה-API.

    הוראות ליצירת רשומות DNS לממשקי API ולשירותים שאין להם רשומת DNS ב-p.googleapis.com מפורטות במאמר בנושא יצירת רשומות DNS.

השירותים הזמינים משתנים בהתאם לבחירה של all-apis או של vpc-sc חבילת ה-API.

נוצר תחום DNS אחד של Service Directory לכל רשת VPC שמכילה נקודת קצה.

אפשר לגשת לשמות ה-DNS של נקודת קצה בכל האזורים ברשת ה-VPC.

פענוח DNS

לקוחות באותה רשת VPC שבה נמצאת נקודת הקצה יכולים לשלוח שאילתות לאזורי ה-DNS הפרטיים שנוצרו באופן אוטומטי כשהם מבצעים המרה של שמות מארחים, וגם לכל אזור פרטי שיוצרים באופן ידני. אם מופנית בקשה ממכונה של Compute Engine לשירות דרך נקודת קצה (לדוגמה, ל-storage-xyz.p.googleapis.com), הלקוח שולח שאילתה לאזור ה-DNS הפרטי המתאים כדי לפתור את שם המארח, ומקבל את כתובת ה-IP של נקודת הקצה של Private Service Connect.

עם זאת, אם לקוח מחפש שם מארח שלא קיים בתחום ה-DNS הפרטי, השאילתה מועברת לשרתי ה-DNS הציבוריים של Google. רשומות ה-DNS הציבוריות של googleapis.com (ודומיינים אחרים של Google) כוללות רשומת wildcard, כלומר כל שמות המארחים מפוענחים לכתובת IP. לדוגמה, אם אין לכם אזור DNS פרטי ל-p.googleapis.com ברשת ה- VPC, ואתם מבצעים חיפוש DNS ל- storage-xyz.p.googleapis.com, שם המארח מתורגם לכתובות IP ציבוריות ששייכות ל-Cloud Front Ends, ולא לכתובת ה-IP הפנימית של נקודת הקצה של Private Service Connect.

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

ממשקי API נתמכים

כשיוצרים נקודת קצה לגישה לממשקי Google APIs ולשירותים של Google, בוחרים את חבילת ממשקי ה-API שרוצים לגשת אליהם – All APIs (all-apis) או VPC-SC (vpc-sc):

  • חבילת all-apis מספקת גישה לרוב ממשקי ה-API והשירותים של Google, כולל כל נקודות הקצה של שירות *.googleapis.com.

  • חבילת vpc-sc מספקת גישה לממשקי API ולשירותים שתומכים ב-VPC Service Controls.

חבילות ה-API תומכות רק בפרוטוקולים מבוססי-HTTP דרך TCP ‏ (HTTP,‏ HTTPS ו-HTTP/2). אין תמיכה בפרוטוקולים אחרים, כולל MQTT ו-ICMP.

חבילת API שירותים נתמכים דוגמה לשימוש
all-apis

מאפשר גישת API לרוב ממשקי ה-API והשירותים של Google, בלי קשר לשאלה אם הם נתמכים על ידי VPC Service Controls. היא כוללת גישה ל-API של מפות Google,‏ Google Ads Google Cloudורוב ממשקי ה-API האחרים של Google, כולל הרשימות שבהמשך. אין תמיכה באפליקציות אינטרנט של Google Workspace כמו Gmail ו-Google Docs. אין תמיכה באתרים אינטראקטיביים.

שמות דומיין שתואמים:

  • accounts.google.com (תומך רק בנתיבים שנדרשים לאימות OAuth של חשבונות שירות; אימות של חשבונות משתמשים הוא אינטראקטיבי ולא נתמך)
  • *.aiplatform-notebook.cloud.google.com
  • *.aiplatform-notebook.googleusercontent.com
  • appengine.google.com
  • *.appspot.com
  • *.backupdr.cloud.google.com
  • backupdr.cloud.google.com
  • *.backupdr.googleusercontent.com
  • backupdr.googleusercontent.com
  • *.cloudfunctions.net
  • *.cloudproxy.app
  • *.composer.cloud.google.com
  • *.composer.googleusercontent.com
  • *.datafusion.cloud.google.com
  • *.datafusion.googleusercontent.com
  • *.dataproc.cloud.google.com
  • dataproc.cloud.google.com
  • *.dataproc.googleusercontent.com
  • dataproc.googleusercontent.com
  • *.developerconnect.dev
  • dl.google.com
  • gcr.io או *.gcr.io
  • *.googleapis.com

    לא כולל *.rep.googleapis.com נקודות קצה אזוריות ונקודות קצה עם מספר אזורים.

  • *.gke.goog
  • gstatic.com או *.gstatic.com
  • *.kernels.googleusercontent.com
  • *.ltsapis.goog
  • *.notebooks.byoid.googleusercontent.com
  • *.notebooks.cloud.google.com
  • notebooks.cloud.google.com
  • *.notebooks.googleusercontent.com
  • packages.cloud.google.com
  • pkg.dev או *.pkg.dev
  • pki.goog או *.pki.goog
  • *.run.app
  • source.developers.google.com
  • storage.cloud.google.com

בוחרים באפשרות all-apis במקרים הבאים:

  • אתם לא משתמשים ב-VPC Service Controls.
  • אתם משתמשים ב-VPC Service Controls, אבל אתם גם צריכים לגשת לממשקי API ולשירותים של Google שלא נתמכים על ידי VPC Service Controls. 1
vpc-sc

מאפשר גישת API אל ממשקי API ושירותים של Google שנתמכים על ידי VPC Service Controls.

חוסמת גישה ל-Google APIs ולשירותים של Google שלא תומכים ב-VPC Service Controls. אין תמיכה בממשקי API של Google Workspace או באפליקציות אינטרנט של Google Workspace, כמו Gmail ו-Google Docs.

בוחרים באפשרות vpc-sc כשרק צריך גישה לממשקי API ולשירותים של Google שנתמכים על ידי VPC Service Controls. חבילת vpc-sc לא מאפשרת גישה לממשקי API ולשירותים של Google שלא תומכים ב-VPC Service Controls. 1
‫1 אם אתם צריכים להגביל את המשתמשים רק ל-Google APIs ולשירותים של Google שתומכים ב-VPC Service Controls, כדאי להשתמש ב-vpc-sc, כי הוא מספק אמצעים נוספים לצמצום הסיכון לזליגת נתונים. השימוש ב-vpc-sc חוסם את הגישה לממשקי API ולשירותים של Google שלא נתמכים על ידי VPC Service Controls. פרטים נוספים זמינים במאמר הגדרת קישוריות פרטית במסמכי התיעוד של VPC Service Controls.

הדרישות בנוגע לכתובות IP

כשמגדירים Private Service Connect לממשקי Google APIs גלובליים, צריך לספק כתובת IP לשימוש בנקודת הקצה.

הכתובת נכללת במכסת הפרויקט של כתובות IP פנימיות גלובליות.

כתובת ה-IP צריכה לעמוד בדרישות הבאות:

  • היא חייבת להיות כתובת IP יחידה ולא טווח כתובות.

  • היא צריכה להיות כתובת IPv4 תקינה. יכולה להיות כתובת RFC 1918 או כתובת שאינה RFC 1918. אין תמיכה בכתובות IPv6.

  • היא לא יכולה להיות בטווח של רשתות המשנה שהוגדרו ברשת ה-VPC.

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

  • היא לא יכולה לחפוף עם נתיב סטטי מותאם אישית /32 ברשת ה-VPC המקומית. לדוגמה, אם לרשת ה-VPC יש נתיב סטטי מותאם אישית ל-10.10.10.10/32, אי אפשר לשריין את הכתובת 10.10.10.10 ל-Private Service Connect.

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

  • היא לא יכולה להיות בטווח של כתובות IP במצב אוטומטי (ב-10.128.0.0/9) אם רשת ה-VPC המקומית היא רשת במצב אוטומטי או אם היא מקושרת לרשת במצב אוטומטי.

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

  • אם נקודת קצה חופפת לנתיב דינמי מותאם אישית שהיעד שלו זהה ל-/32, נקודת הקצה מקבלת עדיפות.

  • אם כתובת ה-IP של נקודת הקצה נמצאת בטווח היעד של מסלול סטטי מקומי, מסלול דינמי מקומי או מסלול מותאם אישית של שירותי Peering, ולמסלול הזה יש מסכה של רשת משנה קצרה יותר מ-/32, נקודת הקצה מקבלת עדיפות גבוהה יותר.

תרחישים לדוגמה

אפשר ליצור כמה נקודות קצה באותה רשת VPC. אין הגבלה על רוחב הפס הכולל שנשלח לנקודת קצה מסוימת. מכיוון שנקודות קצה משתמשות בכתובות IP פנימיות גלובליות, כל משאב ברשת ה-VPC או ברשת מקומית שמחוברת באמצעות מנהרות Cloud VPN או קבצים מצורפים של Cloud Interconnect יכול להשתמש בהן.

אם יש לכם כמה נקודות קצה, אתם יכולים לציין נתיבי רשת שונים באמצעות Cloud Router וכללי חומת אש.

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

  • יכול להיות שיהיה לכם כלל חומת אש במכונה וירטואלית שימנע את כל התעבורה לאינטרנט, אבל תעבורה שנשלחת לנקודות קצה של Private Service Connect עדיין תגיע ל-Google.

  • אם יש לכם מארחים מקומיים שמחוברים ל-VPC באמצעות מנהרת Cloud VPN או צירוף ל-VLAN, אתם יכולים לשלוח חלק מהבקשות דרך המנהרה או ה-VLAN, ולשלוח בקשות אחרות דרך האינטרנט הציבורי. ההגדרה הזו מאפשרת לעקוף את המנהרה או את ה-VLAN בשביל שירותים כמו Google Books שלא נתמכים בגישה פרטית ל-Google.

    כדי ליצור את ההגדרה הזו, צריך ליצור נקודת קצה (endpoint) של Private Service Connect, לפרסם את כתובות ה-IP של נקודת הקצה באמצעות פרסום מסלולים בהתאמה אישית ב-Cloud Router ולהפעיל מדיניות להעברת בקשות נכנסות ב-Cloud DNS. האפליקציה יכולה לשלוח חלק מהבקשות דרך מנהרת Cloud VPN או דרך קובץ ה-VLAN המצורף באמצעות שם נקודת הקצה, והיא יכולה לשלוח בקשות אחרות דרך האינטרנט באמצעות שם ה-DNS שמוגדר כברירת מחדל.

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

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

  • אפשר גם להשתמש בכמה צירופים ל-VLAN בטופולוגיה פעילה/פעילה. אם מפרסמים את אותה כתובת IP של נקודת הקצה באמצעות פרסום של מסלולים בהתאמה אישית עבור סשנים של BGP בנתבי Cloud שמנהלים את רשתות ה-VLAN, מנות שנשלחות ממערכות מקומיות לנקודות הקצה מנותבות ברשתות ה-VLAN באמצעות ECMP.

    איור 2. אפשר להגדיר Private Service Connect,‏ Cloud Router ומארחים מקומיים כדי לשלוט בצירוף ל-VLAN שמשמש לשליחת תעבורת נתונים אל Google APIs (לחיצה להגדלה).

VPC משותף

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

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

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

אם יוצרים את ההגדרה הזו, צריך להעניק לאדמין של פרויקט השירות תפקיד כמו Compute Network User ‏ (roles/compute.networkUser) בפרויקט המארח. התפקיד הזה מכיל את ההרשאות הנדרשות compute.networks.use ו-compute.addresses.use.

אי אפשר ליצור את ההגדרה הזו באמצעות מסוף Google Cloud . צריך להשתמש ב-Google Cloud CLI או ב-API.

תמחור

המחירים של Private Service Connect מפורטים בדף המחירים של VPC.

מכסות

מספר נקודות הקצה של Private Service Connect שאפשר ליצור כדי לגשת ל-Google APIs מוגבל על ידי PSC Google APIs Forwarding Rules per VPC Network המכסה. מידע נוסף זמין במאמר בנושא מכסות.

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

אדמין של מדיניות הארגון יכול להשתמש באילוץ constraints/compute.disablePrivateServiceConnectCreationForConsumers כדי להגדיר את קבוצת סוגי נקודות הקצה שמשתמשים לא יכולים ליצור עבורם כללי העברה.

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

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