Cloud SQL Auth Proxy מול מסלול VPN ישיר למסד הנתונים
Auth Proxy ומסלול VPN ישיר פותרים חצאים שונים של אותה בעיה. השוו קודם את הרשאת המחבר, את הפורטים ואת הכניסה למסד הנתונים.
יש שתי דרכים הגיוניות להגיע למופע Cloud SQL פרטי ממחשב נייד ב-VPN. האחת היא חיבור ישיר לכתובת הפרטית של המופע דרך המסלול שכבר יש לכם. האחרת היא Cloud SQL Auth Proxy, שמאזין על loopback ופותח בעצמו את החיבור אל Cloud SQL. אלה פחות מוצרים מתחרים ויותר שתי תשובות שונות לשאלה מי מחזיק בהרשאה ומי מחזיק במסלול. בחירה גרועה מופיעה בדרך כלל כשגיאת הרשאה שנקראת כמו שגיאת רשת.
הנה ההשוואה שהייתי מציג לצוות, ואחריה הבדיקות שבאמת מכריעות אותה.
שני מסלולים לאותו מופע
המסלול הישיר משתמש במסלול private-services-access מהרשת שלכם אל ה-VPC של הפרויקט. הלקוח שלכם מדבר PostgreSQL עם הכתובת הפרטית של המופע, והחיבור חי או מת על ניתוב, כללי firewall והרשאות מסד הנתונים.
מסלול ה-proxy משתמש באותו מסלול אבל מוסיף תהליך מקומי. ה-proxy מאמת את עצמו מול Google API בעזרת ה-default credentials של האפליקציה, פותח חיבור למופע דרך ה-connector וחושף פורט loopback שהלקוח שלכם מתייחס אליו כ-PostgreSQL. שתי קפיצות הופכות לשלוש, והאמצעית נושאת הרשאת IAM. מסלול ה-VPN נשאר באחריותכם לתחזוקה, וה-proxy אף פעם לא רואה בו תחליף לבדיקה הזו.
מה כל מסלול באמת מאשר
ההבחנה החשובה ביותר היא מה כל אפשרות יכולה לאשר בשבילכם:
| Question | Direct private IP | Auth Proxy |
|---|---|---|
| Who proves identity to the network | Your client, through the VPN and a database login | The proxy, through IAM to Google's API |
| IAM role needed for the connector | None | Cloud SQL Client or equivalent |
| Database user authentication | Always required | Still required unless IAM database authentication is enabled |
| Shape of the local leg | Client to instance | Client to loopback, proxy to instance |
בדיקת ה-IAM של ה-proxy והכניסה למסד הנתונים הם שני שערים נפרדים, ומעבר באחד לא פותח את השני. צוות שמפעיל את ה-proxy ומניח שחשבון האפליקציה כבר מיותר יבלה אחר צהריים שלם בכשלי סיסמה שאין להם שום קשר לרשת.
פורטים ומסלולים, זה לצד זה
ה-proxy צריך TCP 443 יוצא בשביל ה-API ו-TCP 3307 בשביל חיבור המופע, ושניהם מתוארים ב-סקירת Auth Proxy של Google. מסלול ה-VPN שלכם מכסה את השני; הראשון יוצא בדרך כלל במסלול הרגיל.
חיבור ישיר דורש שפורט ה-PostgreSQL של המופע יהיה נגיש דרך המסלול הפרטי, וזו שיחה אחרת לגמרי על firewall. אם צוות הרשת שלכם מתיר רק 443 יוצא מתתי-הרשת של הלקוחות, ה-proxy מתאים בלי שינוי כלל והמסלול הישיר לא. העובדה האחת הזו מכריעה את הבחירה לעתים קרובות יותר מכל העדפה ארכיטקטונית.
אף אחד מהמסלולים לא דורש שלמופע תהיה כתובת ציבורית, ואף אחד לא מצדיק להוסיף כזו.
איפה ה-proxy לא עוזר
ה-proxy לא מתקן מסלול חסר. אם מסלול private-services-access חסר, או שה-VPN לא נושא אותו, ה-connector נכשל בעוד המאזין המקומי עדיין יושב שם ומאזין, וזה החלק המבלבל.
הוא גם לא מגן על הקטע שבין האפליקציה ל-proxy. על מחשב נייד אחד הקטע הזה הוא loopback וזה בסדר. אם תקשרו את המאזין לכתובת wildcard כדי שעמית יגיע אליו, בניתם שער מסד נתונים ללא אימות וקראתם לזה נוחות. השאירו אותו על loopback ותנו לעמית להשיג הרשאה משלו.
והוא לא הופך את Private Service Connect ואת private services access לברי החלפה. מופע PSC צריך סידור DNS משלו ואת הקריאה --psc במקום הצורה --private-ip.
לבחור, ואז לאמת בכל מקרה
בחרו ב-proxy כשרוצים IAM במסלול, הרשאות קצרות מועד ובלי שינוי ב-firewall הנכנס.
בחרו במסלול הישיר כשלקוח נתמך כבר מחזיק הרשאות מסד נתונים חזקות וצוות הרשת מוכן לפתוח את הפורט. בכל מקרה, אמתו בשאילתה אמיתית ולא בחיבור מוצלח: התחברו, הריצו קריאה אחת מול טבלה מוכרת ובדקו מה השרת רואה על הסשן שלכם.
אחרי חיבור מחדש של ה-VPN, התייחסו להרשאה שפגה, למסלול פרטי חסר ולסירוב כניסה למסד הנתונים כשלושה כשלים שונים. רק אחד מהם הוא בעיית רשת, ורק אחד אמור אי פעם להוביל לשינוי כלל firewall.