כדי לשמור על חיבורים מאובטחים ואמינים למכונות של AlloyDB ל-PostgreSQL בסביבות ייצור ופיתוח, כדאי לפעול לפי השיטות המומלצות הבאות כשפורסים ומנהלים את AlloyDB Auth Proxy.
עדכון הלקוח של שרת ה-proxy לאימות
Google משיקה גרסאות חדשות של Auth Proxy מדי חודש. כדי לבדוק מה הגרסה הנוכחית, אפשר להיכנס לדף הגרסאות של AlloyDB Auth Proxy ב-GitHub.
כדאי להשתמש באוטומציה כדי לעדכן את גרסת ה-Auth Proxy ולבדוק את הגרסה החדשה בסביבות שהן לא סביבות ייצור, לפני שמקדמים את השינוי לסביבת הייצור.
הפעלת לקוח Auth Proxy כשירות מתמיד או כ-sidecar
בסביבת ייצור, צריך להריץ את לקוח Auth Proxy כשירות מתמשך או כ-sidecar.
אם תהליך הלקוח של שרת ה-proxy לאימות נעצר, כל החיבורים הקיימים דרכו נסגרים, והאפליקציה לא יכולה ליצור חיבורים נוספים למכונה של AlloyDB באמצעות שרת ה-proxy לאימות של AlloyDB. כדי למנוע את התרחיש הזה, צריך להריץ את לקוח Auth Proxy כשירות מתמיד, כך שאם לקוח Auth Proxy נסגר מסיבה כלשהי, הוא מופעל מחדש באופן אוטומטי.
בהתאם למקום שבו אתם מריצים את הלקוח, השתמשו באפשרויות הבאות:
- ללקוח Auth Proxy שפועל במכונות וירטואליות של Linux, משתמשים בשירות כמו
systemd,upstartאוsupervisor. - לעומסי עבודה ב-Windows, מריצים את לקוח Auth Proxy כשירות של Windows. מידע נוסף זמין במאמר הפעלת שרת ה-proxy לאימות כשירות של Windows.
- בהגדרות של Kubernetes, מריצים את לקוח Auth Proxy כ-sidecar.
הפעלת לקוח Auth Proxy באותו מחשב שבו פועל עומס העבודה
ההנחה היא שהלקוח של Auth Proxy פועל באותו מחשב שבו פועל עומס העבודה. כל תנועת הלקוחות לשרת ה-proxy לאימות לא תהיה מוצפנת. התנועה משרת ה-proxy לאימות אל AlloyDB מוצפנת באמצעות mTLS.
חשוב לוודא שכל לקוח של שרת ה-proxy לאימות נמצא באותו מחשב, כדי שתנועה לא מוצפנת לא תצא מהמחשב. ה-AlloyDB Auth Proxy צריך להיות באותו מיקום של הלקוח שרוצה לגשת למכונה של AlloyDB.
שימוש בחשבון שירות נפרד לכל עומס עבודה
AlloyDB Auth Proxy משתמש בחשבון ה-Principal של ניהול הזהויות והרשאות הגישה (IAM) של הסביבה כדי ליצור מנהרה מאובטחת למכונה של AlloyDB. כדי לפעול לפי העיקרון של הרשאות מינימליות, כל עומס עבודה, כמו אפליקציית אינטרנט או אפליקציה לעיבוד נתונים בקצה העורפי, צריך להשתמש בחשבון שירות נפרד. השימוש בחשבון שירות נפרד מבטיח שאפשר לנהל (או לבטל) את ההרשאות של כל עומס עבודה בנפרד.
אל תפרסו את שרת ה-proxy לאימות ב-AlloyDB כצוואר בקבוק
יכול להיות שתרצו לפרוס את שרת ה-proxy לאימות של AlloyDB במכונה וירטואלית משותפת, ולהשתמש בו כדי לנתב את כל התנועה ממספר עומסי עבודה למכונה של AlloyDB. עם זאת, הגישה הזו לא מאובטחת ויוצרת נקודת כשל בודדת.
כשכמה לקוחות משתמשים באותו חשבון משתמש ב-IAM שבו משתמש Auth Proxy, קשה לזהות את עומס העבודה שניגש בפועל למכונה של AlloyDB, ולכן הגישה הזו לא מאובטחת.
הגישה הזו יוצרת נקודת כשל בודדת, כי אם ה-AlloyDB Auth Proxy עמוס בגלל עלייה פתאומית בתנועה, כל החיבורים של הלקוחות יושפעו לרעה.
במקום זאת, פורסים לקוח Auth Proxy בכל מכונה שצריכה חיבור מאובטח, כ-sidecar או כשירות מתמיד.
צמצום פלט היומן של AlloyDB Auth Proxy בפריסות בסביבת ייצור
אם אתם צריכים להגביל את גודל היומנים של שרת ה-proxy לאימות ב-AlloyDB, הגדירו את האפשרות --verbose=false כשאתם מפעילים את שרת ה-proxy לאימות ב-AlloyDB. חשוב לזכור שאם משתמשים באפשרות הזו, הפלט של שרת ה-proxy לאימות ב-AlloyDB פחות יעיל באבחון בעיות בחיבור.
קריאת הודעת העזרה של AlloyDB Auth Proxy
AlloyDB Auth Proxy כולל הרבה תכונות נוספות והודעת עזרה מקיפה עם פרטים. מריצים את הפקודה alloydb-auth-proxy --help כדי לראות אפשרויות הגדרה נוספות.
איך ליצור קשר עם צוות הפיתוח ב-GitHub
אם לדעתכם מצאתם באג או שאתם רוצים להגיש בקשה להוספת תכונה, אתם יכולים לפנות לצוות הפיתוח במאגר של שרת proxy לאימות ב-AlloyDB ב-GitHub.