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