מידע על שרת ה-proxy של AlloyDB Auth

‫AlloyDB Auth Proxy הוא מחבר שמאפשר ליצור חיבורים מוצפנים ומורשים למסדי הנתונים של AlloyDB ל-PostgreSQL, בלי לנהל אישורי SSL או להגדיר כללים של חומת אש. במאמר התחברות באמצעות שרת ה-proxy לאימות של AlloyDB מוסבר איך משתמשים בשרת ה-proxy לאימות.

יתרונות השימוש ב-AlloyDB Auth Proxy

ל-Auth Proxy יש את היתרונות הבאים על פני חיבור לקוחות ישירות למסדי נתונים של AlloyDB:

  • הרשאת חיבור שמבוססת על ניהול זהויות והרשאות גישה (IAM). ‫Auth Proxy משתמש בפרטי הכניסה ובהרשאות של חשבון משתמש ב-IAM כדי לאשר חיבורים למכונות AlloyDB.

  • אימות אוטומטי ב-IAM. שרת ה-proxy לאימות יכול לאמת באופן אוטומטי משתמשים במסד הנתונים, על סמך חשבון המשתמש ב-IAM שמפעיל את שרת ה-proxy.

  • תקשורת מאובטחת ומוצפנת. שרת ה-proxy לאימות יוצר, משתמש ומתחזק באופן אוטומטי חיבור Mutual TLS (mTLS) 1.3 באמצעות צופן AES של 256 ביט בין הלקוח למכונה של AlloyDB, כדי לאמת את הזהויות של הלקוח והשרת ולהצפין את תנועת הנתונים.

למידע נוסף על התחברות למכונות של AlloyDB, קראו את הסקירה הכללית על התחברות.

איך פועל AlloyDB Auth Proxy

‫AlloyDB Auth Proxy פועל כתהליך לקוח מקומי (alloydb-auth-proxy) בסביבת האפליקציה, ומאזין לחיבורים ב-localhost (כברירת מחדל ביציאת TCP‏ 5432) או בשקע דומיין מקומי של Unix. האפליקציה מתחברת למאזין המקומי הזה באמצעות מנהלי התקנים ופרוטוקולי תקשורת סטנדרטיים של PostgreSQL, ולקוח Auth Proxy מעביר את התנועה דרך מנהרה מוצפנת (mTLS 1.3 עם צופן AES של 256 ביט) לתהליך של שרת Auth Proxy הנלווה שפועל במכונה של AlloyDB. כל חיבור שנוצר באמצעות שרת ה-proxy לאימות יוצר חיבור אחד למכונה של AlloyDB.

כשאפליקציה מתחברת לשרת ה-proxy לאימות, השרת בודק אם יש חיבור קיים למכונה של AlloyDB. אם אין חיבור, שרת ה-proxy שולח קריאה ל-AlloyDB API כדי לקבל אישור SSL זמני, ומשתמש בו כדי ליצור את מנהרת ה-mTLS למכונה. התוקף של אישורי SSL זמניים פג תוך 24 שעות, ו-Auth Proxy מרענן אותם באופן אוטומטי לפני שהתוקף שלהם פג.

שרת ה-proxy לאימות קורא ל-AlloyDB API דרך שם הדומיין alloydb.googleapis.com באמצעות HTTPS. לכן, חומת האש צריכה לאפשר חיבורי TCP יוצאים ביציאה 443 (HTTPS) ממכונת הלקוח.

למרות ש-Auth Proxy יכול להאזין באופן מקומי בכל יציאה, הוא יוצר חיבורים יוצאים למכונה של AlloyDB רק ביציאת TCP ‏5433. אם למארח הלקוח יש חומת אש לתעבורה יוצאת, היא צריכה לאפשר חיבורים ליציאה 5433 בכתובת ה-IP של המכונה ב-AlloyDB, וליציאה 443 בכל כתובות ה-IP.

אתם יכולים להשתמש בשרת ה-Proxy לאימות בכל נתיבי הקישוריות לרשת של AlloyDB:

  • גישה לשירותים פרטיים (ברירת המחדל): חיבור לכתובת ה-IP הפנימית של המכונה ברשת של ענן וירטואלי פרטי (VPC) מקושר.
  • ‫Private Service Connect: מתחבר דרך נקודת קצה (endpoint) של Private Service Connect ורשומת DNS פרטית כשמעבירים את הדגל --psc.
  • כתובת IP ציבורית: מתחברת לכתובת ה-IP הציבורית של המכונה כשמעבירים את הדגל --public-ip. מכיוון ששרת ה-proxy לאימות מאמת ומצפין חיבורים באמצעות IAM ו-mTLS ביציאה 5433, לא צריך להוסיף את כתובת ה-IP של הלקוח לרשתות חיצוניות מורשות כשמתחברים דרך שרת ה-proxy לאימות.

איך AlloyDB Auth Proxy מאמת ומאשר חיבורים

כדי לאשר את החיבור של הלקוח למכונה של AlloyDB, הלקוח של שרת ה-Proxy לאימות מאמת את Google Cloud באמצעות פרטי הכניסה של ישות מורשית ב-IAM בלקוח, ואז מאמת שלישות המורשית ב-IAM יש את תפקידי ה-IAM של לקוח AlloyDB‏ (roles/alloydb.client) ושל Service Usage Consumer‏ (roles/serviceusage.serviceUsageConsumer).

כברירת מחדל, לקוח ה-Auth Proxy משתמש ב-Application Default Credentials ‏ (ADC) כדי לאתר את פרטי הכניסה של הלקוח. כך אפשר לאמת אפליקציות באופן אחיד וסטנדרטי, בלי לערוך או להגדיר ערכים באופן ידני.

אימות רגיל

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

  • פיתוח מקומי. כשמפתחים באופן מקומי, אפשר לבצע אימות באמצעות חשבון המשתמש האישי או הארגוני ב-Google. לקוח ה-Auth Proxy מזהה את פרטי הכניסה האלה ומשתמש בהם באופן אוטומטי. זו הגישה המומלצת לפיתוח מקומי, כי היא מייתרת את הצורך להוריד קובצי מפתחות של חשבונות שירות באופן מקומי. להוראות מפורטות להגדרת סביבת פיתוח מקומית, קראו את המאמרים התחברות מהמחשב הנייד והתקנת כלי שורת הפקודה של psql.

  • סביבות בניהול Google. כשמריצים את האפליקציה בשירות שלGoogle Cloud (כמו מכונות Compute Engine, ‏Google Kubernetes Engine, ‏Cloud Run, פונקציות Cloud Run או App Engine), פרטי הכניסה מחשבון השירות המצורף מסופקים באופן אוטומטי על ידי שרת המטא-נתונים של הסביבה. הלקוח של Auth Proxy מגלה את פרטי הכניסה האלה ומשתמש בהם באופן אוטומטי, בלי הגדרה נוספת.

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

שינוי פרטי הכניסה

בתרחישים ספציפיים – כמו בדיקה, הפעלה מחוץ ל-Google Cloudאו כשרוצים לעקוף את פרטי הכניסה הרגילים לסביבה – אפשר לשנות את פרטי הכניסה באחת מהשיטות הבאות:

  • מַפְתח של חשבון שירות. מזינים את המפתח באמצעות משתנה הסביבה GOOGLE_APPLICATION_CREDENTIALS או הדגל --credentials-file. מפתחות של חשבונות שירות מהווים סיכון אבטחה אם לא מנהלים אותם בצורה נכונה, לכן כשאפשר, מומלץ לבחור באחד מהמקורות הרגילים.

  • אסימון גישה קיים מסוג OAuth 2.0. מציינים את האסימון באמצעות הדגל --token.

  • פרטי הכניסה ל-CLI של gcloud. צריך לספק את פרטי הכניסה האלה באמצעות הדגל --gcloud-auth. אנחנו לא ממליצים על הדגל הזה. במקום זאת, צריך להריץ את הפקודה gcloud auth application-default login.

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

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