וגם הרחבה על תצורות אימות.
במאמר הקודם שלי פירטתי באריכות ובהרחבה כיצד לבנות מערך של ניטור ואוטומציה לביצוע פעולות בסביבת הענן.
אמנם המאמר מתייחס מפורשות לסביבת הענן של GCP, אך העקרונות נכונים לישום גם אצל ספקיות ענן אחרות.
בסופו של דבר יוצרים קונטיינר שמריץ את המשימות, וגורמים לו לתקשר עם רשת הארגון ועם שירותי ענן אחרים.
לאחר כתיבת המאמר הקודם קיבלתי פניה בעניין התחברות לשרת דואר On-Prem, כאשר הגדרות האבטחה של אותו שרת דואר מאלצים אימות Kerberos.
בזה יעסוק המאמר הנוכחי, שיהיה קצר משמעותית מן האחרים.
תצורות אימות:
במאמר הקודם ראינו כיצד שולחים בקשה מפורשת לקבלת Access Token – ואיך משתמשים בו כדי לגשת למשאבים.
בלי להזכיר זאת מפורשות, הגדרנו הרשאות לחשבונות שירות בסביבת GCP, וכך יש להם הרשאות לכל מיני API.
הרשאות אלה מתנהלות בתצורה מרומזת. זה אומר שברגע שניתנה ההרשאה, מאחורי הקלעים אותו חשבון ניגש ולוקח לו Access Token עבור היעד המורשה.
גם ראינו תצורת התחברות של משתמש וסיסמה, כזו שפותחים באמצעותה Session. כל עוד ה-Session חי, ההרשאה בתוקף על סמך ההזדהות.
כעת אציג (בקצרה) את תצורת האימות של Kerberos. אז אכתוב איך להפעיל אותה מתוך קונטיינר בהתחברות לסביבת דומיין.
Kerberos:
באימות Kerberos הלקוח אינו שולח את הסיסמה לאף שרת או מחשב אחר ברשת.
במקום לשלוח סיסמה, הלקוח מקבל מהשירות מסר המוצפן באמצעות הסיסמה שלו. כך צד הלקוח פותח את ההצפנה של המסר אצלו באופן פנימי. משם הוא מקבל מפתח הצפנה עבור שלבי התקשורת הבאים.
בלי לעבור על כל שלבי התהליך שנשמעים כמו חד גדיא, האימות בין הלקוח למשאבים ברשת מסתמך על כרטיסים מוצפנים מעין אלה. הלקוח והשירותים מעבירים ביניהם את הכרטיסים במקום סיסמאות, והשימוש בסיסמה מוגבל רק להצפנת המסר הראשוני.
הכרטיס המוצפן כולל מידע גם על צד הלקוח. לכן זו שיטת אימות הרבה יותר טובה מאשר משתמש וסיסמה. שכן:
- הסיסמאות לא עוברות על גבי הרשת
- ההרשאה שניתנת ללקוח בצורת הכרטיס, תקפה רק לתחנה ממנה המשתמש ביצע את בקשת האימות הראשונית.
עבור כל שירות או משאב חדש שאליו הלקוח רוצה לגשת, הוא יצטרך להשתמש בכרטיסים המוצפנים שלו. איתם יוכל להזדהות ולבקש כרטיס מעבר יעודי לאותו משאב חדש. תצורה זו מצמצמת את האפשרות לגניבת הרשאה מתחנה אחת ושימוש בה במקום אחר.
לכן יש מקומות ושירותים בהם יגדירו חסימה של תצורות אימות מיושנות יותר. כאשר מתאפשר אימות באמצעות Kerberos.
הזדהות ושימוש ב-Kerberos מתוך Container Linux:
ניקח לדוגמה את המקרה שהציגו לי – שרת Exchange On-Prem שהגישה אליו מתאפשרת רק באמצעות kerberos.
אם נרצה לתשאל את השרת או לבצע פעולות כמו שינויים, מחיקה או השבתה בתיבות דואר – לא נוכל לעשות זאת בתצורה שהוצגה במאמר הקודם. לכן נצטרך להוסיף יכולות לקונטיינר שלנו (או להחליף יכולות), ומשם לפנות לשרת הדואר בצורה אחרת.
כדי לאפשר הזדהות מול סביבת Active-Directory, השתמשנו במאמר הקודם בתצורת NTLM. עבור תצורה זו הקונטיינר שהוצג שם כולל את החבילה gss-ntlmssp. כדי להשתמש באימות kerberos, נוסיף לה או נחליף אותה בחבילה הבאה – krb5-user.
כפי שניתן לראות בציור, פשוט מוסיפים את ההתקנה של החבילה ל-Dockerfile.
פניה והזדהות:
מתוך הקונטיינר נפעיל סקריפט דומה כדי לבצע אימות, ואז שימוש בזהות הזו לצורך גישה למשאבים.
כך זה נראה:
# Set authentication for Exchange Shell
$plain = gcloud secrets versions access latest --secret service-account --project example-project
echo $plain | kinit ServisAccount@EXAMPLE.COM
# Connect to ExchangeShell
$session = New-PSSession -ConfigurationName microsoft.exchange -ConnectionUri http://mail.example.com/powershell -Authentication Kerberos
Import-PSSession $session
$mailboxes = Get-Mailbox -ResultSize Unlimited
$permissions = Get-MailboxPermission -Identity $mailbox.SamAccountName
Disable-Mailbox -Identity $x.UserPrincipalName -Confirm:$false
Remove-PSSession $session
הסבר הפעולות:
- בשורה הראשונה הסקריפט אוסף את סיסמת המשתמש מתוך Secret-Manager.
- אז הסקריפט משתמש בסיסמה עבור אימות Kerberos.
– יש לזכור שהסיסמה לא יוצאת מחוץ לקונטיינר.
– מי שינסה ישים לב. אותה פקודת echo נועדה רק להשליך את הסיסמה עבור ה-pipeline, ואיננה מופיעה בלוגים של הקונטיינר.
– לשים לב כאשר רושמים את שם המשתמש עבור הפקודה kinit. חובה לשים את שם הדומיין באותיות גדולות!
– לאחר האימות קיים במערכת כרטיס עבור זהות חשבון השירות שביצע את ההזדהות. - בשליחת בקשה עבור שירות הדורש אימות Kerberos, צד הלקוח מחפש איזה כרטיסים יש לו כרגע. אז הלקוח משתמש בכרטיס שהונפק לו.
- הלקוח מקבל תקשורת ל-Exchange Shell.
- הלקוח יכול לבצע פעולות על שרת הדואר.