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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

איך שרת ה-proxy לאימות של AlloyDB מאמת ומאשר חיבורים

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

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

אימות רגיל

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

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

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

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

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

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

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

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

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

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

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