מידע על גישה ל-Google APIs דרך נקודות קצה

במסמך הזה מפורטת סקירה כללית על נקודות קצה (endpoints) של 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.

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

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

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

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

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

גישה מקומית

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

‫Private Service Connect ו-Service Directory

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

אזור Service Directory

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

הערה: הערה: חבילות ה-API האלה מספקות גישה לאותם ממשקי API שזמינים דרך כתובות ה-VIP של גישה פרטית ל-Google – all-apis שווה ל-private.googleapis.com ו-vpc-sc שווה ל-restricted.googleapis.com. כתובות ה-VIP של גישה פרטית ל-Google – all-apis שווה ל-private.googleapis.com ו-vpc-sc שווה ל-restricted.googleapis.com. הערה: הערה: חבילות ה-API האלה מספקות גישה לאותם ממשקי API שזמינים דרך כתובות ה-VIP של גישה פרטית ל-Google – all-apis שווה ל-�

חבילות ה-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 *.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 API ולשירותים שלא תומכים ב-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

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

דרישות לגבי כתובות IP

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

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

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

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

• היא חייבת להיות כתובת IPv4 חוקית. יכולה להיות כתובת RFC 1918 או כתובת שהיא לא RFC 1918. אין תמיכה בכתובות IPv6 ב-Private Service Connect.

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

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

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

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

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

• היא לא יכולה להיות בטווח כתובות 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 ספרים שלא נתמכים בגישה פרטית ל-Google.

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

• אם מחברים את הרשת המקומית לרשת ה-VPC באמצעות כמה צירופים ל-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 (לחיצה להגדלה).

תמחור

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

מכסות

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

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

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

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

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

• הגדרת Private Service Connect כדי לגשת לממשקי API ולשירותים של Google