RDS פרטי מ-EC2: אותו VPC, peering או משהו אחר?

המחשב הנייד של המפתח מגיע למופע ה-RDS הפרטי דרך ה-VPN של הצוות, אך היישום על EC2 כלל אינו מצליח להתחבר. זו אינה פריסה שבורה. למחשב הנייד יש מנהרה שמופע EC2 לעולם אינו יורש, ו«פרטי» ב-RDS פירושו שלדאטהבייס אין נקודת קצה ציבורית, לא שמשתמשי VPN אנושיים הם הקוראים היחידים המורשים. היישום זקוק למסלול מורשה משלו, ליחסים משלו עם קבוצת האבטחה ולזהות משלו בדאטהבייס, והסדר שבו בוחרים את שלושת אלה חוסך את רוב הדיבוג. החליטו קודם על המסלול, אחר כך על ההרשאות, ואז אמתו מהסביבה שנפרסה ולא מהשולחן שלכם.

ה-VPN של המחשב הנייד אינו המסלול של היישום

יהיה אשר יהיה מה ש-VPN של הצוות עושה לאנשים, הוא אינו עושה דבר למופע, אלא אם אותו מופע הוא חלק מפורש באותו מסלול רשת. מופע EC2 בתת-רשת פרטית מגיע ל-RDS דרך ניתוב VPC, קבוצות אבטחה ו-ACL של רשת. הוא אינו יורש מנהרה של אדם, הפעלה של אדם או אישורי גישה של אדם, ולא צריך: קישוריות יישומים ללא השגחה וגישה מרחוק של הצוות חייבות לפעול באופן עצמאי.

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

החלטה 1: אותו VPC, מסלול ישיר

כשהיישום והדאטהבייס נמצאים באותו VPC עם ניתוב ישיר ובלי תיבת בדיקה באמצע, המסלול פשוט וההפניה לקבוצת אבטחה היא הכלי החזק ביותר הזמין. תנו ליישום קבוצה משלו, ואז אפשרו את פורט הדאטהבייס מאותה קבוצה ולא מטווח כתובות:

aws ec2 authorize-security-group-ingress --group-id sg-0db123   --protocol tcp --port 5432 --source-group sg-0app456

aws rds describe-db-instances --db-instance-identifier prod-db   --query 'DBInstances[0].{Endpoint:Endpoint.Address,Port:Endpoint.Port,Public:PubliclyAccessible,Groups:VpcSecurityGroups}'

הפורט הוא להמחשה וחייב להתאים למנוע. הפניה לקבוצה מאשרת תעבורה ממופעי היישום; היא אינה מעתיקה את הכללים שלהם ואינה יוצרת התחברות לדאטהבייס. שתי בעיות נפרדות, שני תיקונים נפרדים.

ואז בדקו את שאר המסלול במקום לעצור בכלל שזה עתה הוספתם. מדיניות היציאה של היישום, המערך המלא של הקבוצות המחוברות לדאטהבייס, טבלאות הניתוב של תת-הרשת וכל ACL רשת חייבים כולם להסכים. כללי קבוצות אבטחה הם בעלי מצב, ואילו ACL רשת מותאם חייב לאפשר את הבקשה ואת תעבורת החזרה בכללים נפרדים, כולל פורטים אפמריים. כלל חדש וצר לדאטהבייס גם אינו מבטל הרשאה רחבה ישנה יותר שכבר הייתה מחוברת.

החלטה 2: VPC אחר או חשבון אחר

אם היישום ב-VPC אחר, בעלי הרשת בוחרים חיבור פרטי נתמך: peering, עיצוב transit או הסדר VPC משותף. אז חייבים להתקיים שני כיווני הניתוב, פתרון השמות חייב לעבוד עבור נקודת הקצה של RDS, והמקור שמדיניות הדאטהבייס מעריכה חייב להתאים למה שמגיע בפועל. שמות חשבון תואמים או יחסי חיוב משותפים אינם מספקים דבר מזה.

ההפניה לקבוצת אבטחה היא החלק שמשתנה. היא עובדת בכמה עיצובי חיבור פרטי, אך מפסיקה לעבוד ברגע שתיבת ביניים כותבת מחדש את המקור או מסיימת את החיבור, כי אז הדאטהבייס רואה את תיבת הביניים ולא את קבוצת היישום שלכם. תרחישי ה-VPC של RDS מפרידים בין גישה בתוך אותו VPC לבין הסדרים האחרים, וכדאי לבדוק את הטופולוגיה הספציפית שלכם מולם לפני שמניחים שסגנון כלל עובר.

אל תפתרו מסלול חסר בכך שתהפכו את הדאטהבייס לנגיש לציבור. זו החלטת חשיפה אחרת עם בעלים אחר, ובדרך כלל מציע אותה מי שהכי רחוק מהתוצאה.

החלטה 3: איזו זהות הדאטהבייס מקבל

גישת רשת ואימות דאטהבייס הם שכבות נפרדות, וערבובן מייצר את השגיאות המטעות ביותר. תפקיד המופע הוא זהות AWS לקריאה ל-API של AWS. הוא אינו משתמש דאטהבייס. אימות דאטהבייס ב-IAM הוא תכונה נתמכת היכן שהמנוע והתצורה מאפשרים זאת, והוא עדיין מיפוי למשתמש דאטהבייס ולא תחליף לו.

השתמשו בשם נקודת הקצה של RDS בתצורת היישום במקום בכתובת שנלכדה מחיפוש אחד. מעבר Multi-AZ משנה את הכתובת שמאחורי השם הזה, ויישום שנעוץ ל-IP ייכשל בדיוק ברגע שבו הוא נחוץ. השאירו את אימות ה-TLS של המנוע פעיל במקום לכבות אותו כדי שהשגיאה תיעלם, כי כשל אימות אומר לכם משהו על נקודת הקצה שאליה הגעתם.

ואז תנו לחשבון הדאטהבייס את המינימום שהיישום צריך, בסכימה שהוא באמת משתמש בה. העבודה הזו משעממת, היא ניתנת לביקורת, והיא החלק שסקירת תקרית תשאל עליו.

אמתו מהסביבה שנפרסה

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

psql "host=prod-db.abc123.eu-west-1.rds.amazonaws.com port=5432 dbname=app sslmode=verify-full" -c 'select 1'

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