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

בדף הזה מובאת סקירה כללית על AlloyDB Auth Proxy, מחבר שמאפשר ליצור חיבורים מוצפנים ומורשים למסדי נתונים של AlloyDB.

מדריך מפורט לשימוש בשרת ה-Proxy לאימות זמין במאמר התחברות באמצעות שרת ה-Proxy לאימות של AlloyDB.

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

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

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

  • אימות אוטומטי ב-IAM‏ (AuthN): שרת ה-proxy יכול לאמת באופן אוטומטי משתמשי מסד נתונים על סמך הגורם המורשה ב-IAM שמריץ את שרת ה-proxy.

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

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

איך פועל שרת ה-Proxy לאימות ב-AlloyDB

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

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

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

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

למרות ש-AlloyDB Auth Proxy יכול להאזין בכל יציאה, הוא יוצר חיבורים יוצאים או חיבורי יציאה למופע AlloyDB רק ביציאה 5433. אם למארח הלקוח יש חומת אש יוצאת, היא צריכה לאפשר חיבורים ליציאה 5433 בכתובת ה-IP של מופע AlloyDB. מארח הלקוח צריך גם לאפשר חיבורים ליציאה 443, שהיא יציאת ה-HTTPS הסטנדרטית, לכל כתובות ה-IP.

איך פרוקסי האימות של AlloyDB מאשר חשבונות משתמשים ב-IAM

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

כדי לאתר את פרטי הכניסה של IAM בלקוח, לקוח ה-Auth Proxy בודק כל אחד מהפריטים הבאים, ומשתמש בראשון שהוא מוצא כדי לנסות לבצע אימות ל- Google Cloud:

  1. פרטי הכניסה שסופקו על ידי הדגל ‎--credentials-file

    משתמשים בחשבון שירות כדי ליצור ולהוריד את קובץ מפתח ה-JSON המשויך, ומגדירים את הדגל --credentials-file לנתיב של הקובץ כשמפעילים את לקוח Auth Proxy. לחשבון השירות צריכים להיות תפקידי ה-IAM‏ Cloud AlloyDB Client ‏(roles/alloydb.client) ו-Service Usage Consumer ‏(roles/serviceusage.serviceUsageConsumer) עבור מופע AlloyDB.

    כדי להשתמש באפשרות הזו בשורת הפקודה, מפעילים את הפקודה alloydb-auth-proxy עם הדגל --credentials-file שמוגדר לנתיב ולשם הקובץ של קובץ JSON עם פרטי כניסה. הנתיב יכול להיות מוחלט או יחסי לספריית העבודה הנוכחית.

  2. פרטי הכניסה שסופקו באמצעות הדגל ‎--token

    יוצרים אסימון גישה ומפעילים את הפקודה alloydb-auth-proxy עם האפשרות --token שמוגדרת לאסימון גישה מסוג OAuth 2.0.

  3. פרטי כניסה שסופקו על ידי משתנה סביבה

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

  4. פרטי כניסה מלקוח מאומת של Google Cloud CLI

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

    אם לא נבחר חשבון עבור gcloud auth login, לקוח ה-Auth Proxy יחפש חשבון שנבחר עבור gcloud auth application-default login. זו התנהגות ברירת המחדל כשלא מפעילים את הדגל --gcloud-auth.

  5. פרטי הכניסה שמשויכים למכונה של Compute Engine

    אם מתחברים ל-AlloyDB ממכונת Compute Engine, לקוח Auth Proxy יכול להשתמש בחשבון השירות שמשויך למכונת Compute Engine. אם לחשבון השירות יש תפקידי IAM של לקוח Cloud AlloyDB ‏(roles/alloydb.client) ו-Service Usage Consumer ‏(roles/serviceusage.serviceUsageConsumer) עבור מכונת AlloyDB, לקוח Auth Proxy עובר אימות בהצלחה.

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

  6. חשבון השירות שמוגדר כברירת מחדל בסביבה

    אם לקוח ה-Auth Proxy לא מוצא פרטי כניסה באף אחד מהמקומות שצוינו קודם, הוא פועל לפי הלוגיקה שמתועדת במאמר אימות כחשבון שירות. בסביבות מסוימות (כמו Compute Engine, ‏ App Engine ואחרות) יש חשבון שירות שמוגדר כברירת מחדל, והאפליקציה יכולה להשתמש בו כדי לבצע אימות כברירת מחדל. אם משתמשים בחשבון שירות שמוגדר כברירת מחדל, צריך להקצות לו את תפקידי ה-IAM ‏Cloud AlloyDB Client ‏(roles/alloydb.client) ו-Service Usage Consumer ‏(roles/serviceusage.serviceUsageConsumer).

    למידע נוסף על הגישה של Google Cloud לאימות, תוכלו לעיין בסקירה הכללית על אימות.

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