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

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

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

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

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

  • הרשאת חיבור (AuthZ) שמבוססת על IAM: שרת ה-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 Auth משתמש במנהרה מאובטחת (mTLS 1.3, צופן AES של 256 ביט) כדי לתקשר עם תהליך נלווה שפועל בשרת. כל חיבור שנוצר דרך שרת ה-proxy לאימות ב-AlloyDB יוצר חיבור אחד למכונת AlloyDB.

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

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

למרות ש-AlloyDB Auth Proxy יכול להאזין בכל יציאה, הוא יוצר חיבורים יוצאים או תעבורת נתונים יוצאת (egress) למופע 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 Client‏ (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 ועוד) מספקות חשבון שירות שמוגדר כברירת מחדל, והאפליקציה יכולה להשתמש בו כדי לבצע אימות כברירת מחדל. אם משתמשים בחשבון שירות שמוגדר כברירת מחדל, צריך להקצות לו את התפקידים Cloud AlloyDB Client ‏(roles/alloydb.client) ו-Service Usage Consumer ‏(roles/serviceusage.serviceUsageConsumer) ב-IAM.

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

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