בדף הזה מוסבר איך להגדיר יעד מבוצר (bastion host) בפריסה שמחוברת ל-Google Distributed Cloud, כדי לאפשר למהנדסי Google לגשת לצמתים באזור שמחובר ל-Distributed Cloud ולפתור בעיות בהם באמצעות Secure Shell (SSH).
Google מספקת את קוד המקור המלא שבעזרתו אפשר ליצור מכונה וירטואלית של יעד מבוצר (bastion host) מותאם אישית בהתאם לדרישות העסקיות שלכם.
דרישות מוקדמות
בקטע הזה מפורטות הדרישות המוקדמות לפריסת פתרון של יעד מבוצר (bastion host) מחובר ל-Distributed Cloud.
הפעלת אישור גישה
התכונה 'יעד מבוצר (bastion host)' משתמשת בתכונה 'אישור גישה' של Access Transparency כדי לאפשר ל-Google לבקש גישה לנתונים שלכם. לפני שמפעילים מכונות וירטואליות של שרת bastion, צריך להפעיל את Access Transparency ואת Access Approval בפרויקט Google Cloud . מידע נוסף זמין בדפים הבאים:
מפרטים של מכונות וירטואליות
פתרון יעד מבוצר (bastion host) המחובר ל-Distributed Cloud דורש פריסת OpenStack בגודל small עם המפרט הבא:
- מעבד: 1 vCPU
- RAM: 2GB
- דיסק: 20GB
Google ממליצה לפרוס מכונות וירטואליות של יעדים מבוצרים (bastion host) מסוג N+1 לכל Google Cloud אזור כדי לשפר את האמינות.
דרישות רשת
כדי להשתמש בפתרון של יעד מבוצר (bastion host) מחובר ב-Distributed Cloud, צריך להגדיר את סשנים של קישור בין רשתות שכנות (peering) לכל מכונה וירטואלית של יעד מבוצר (bastion host):
- צפונה. חיבור המכונה הוירטואלית של יעד מבוצר (bastion host) לאינטרנט. נדרשת גישה לאינטרנט, וצריך לאפשר חיבורים ביציאה 22 מכתובות IP ספציפיות ש-Google מספקת כחלק מקובץ אימג' של פתרון יעד מבוצר (bastion host) וחבילת קוד מקור.
- דרומה. החיבור של המכונה הווירטואלית של יעד מבוצר (bastion host) מתבצע דרך יציאה 22 לאזורים המחוברים המתאימים של Distributed Cloud באזור Google Cloud יחיד.
- ניהול. מחבר את המכונה הווירטואלית של יעד מבוצר (bastion host) לרשת המקומית למטרות תפעול ותחזוקה. צריך להגדיר את סשן ה-Peering הזה בהתאם למדיניות האבטחה של הארגון.
שיטות מומלצות לאבטחה
Google ממליצה מאוד לפעול לפי השיטות המומלצות לאבטחה שמתוארות בקטע הזה כשמגדירים פתרון של שרת Bastion בפריסה שמחוברת ל-Distributed Cloud, בנוסף למדיניות האבטחה של הארגון:
- כדאי לפעול לפי כלל ההרשאות המינימליות ולשמור על הפרדת תפקידים ברורה בין המשתמשים.
- לכל חשבונות המשתמשים מלבד חשבון האדמין, משתמשים רק באימות מבוסס-אישור. משביתים את האימות מבוסס-הסיסמה ואת גישת הרמה הבסיסית (root) למכונות הווירטואליות של יעד מבוצר (bastion host).
- דחיית גישה מכל כתובות ה-IP בסשן הפירינג הצפוני שלא נכללות ברשימת כתובות ה-IP לתמיכה ש-Google מספקת.
- סוגרים את כל היציאות בסשן הפירינג מדרום לצפון, מלבד יציאה 22 (SSH), ומאפשרים אותה רק לכתובות IP ברשימת כתובות ה-IP לתמיכה ש-Google מספקת.
- חשוב לוודא שכל המכונות הווירטואליות של יעד מבוצר (bastion host) עדכניות. Google מספקת חבילת קוד מקור חדשה עם כל תיקון אבטחה ועדכון גרסה.
- הגדרת פתרון להתראות ולביקורת שעומד בדרישות של מדיניות האבטחה של הארגון.
הפעלת תמיכה ביעד מבוצר (bastion host)
כדי להפעיל תמיכה ביעד מבוצר (bastion host) בפריסה שלכם ב-Distributed Cloud במודל מחובר, צריך להגיש בקשה.
צריך להפעיל ולהגדיר תמיכה ביעד מבוצר (bastion host) בנפרד לכל אחד מהאזורים המחוברים ל-Distributed Cloud. כך תוכלו לפרוס הגדרות שונות של גישה ורשת שמתאימות בצורה הטובה ביותר לצרכים העסקיים של הארגון שלכם בכל אזור שמחובר ל-Distributed Cloud.
השגת תוכנת יעד מבוצר (bastion host)
חבילת התוכנה של יעד מבוצר (bastion host) נשלחת אליכם אחרי שהתמיכה של Google מפעילה את התכונה של יעד מבוצר (bastion host) עבור הפריסה המחוברת שלכם ב-Distributed Cloud. החבילה מכילה את הפריטים הבאים:
- קוד מקור. אתם יכולים להתאים אישית וליצור תמונות של מכונות וירטואליות של יעדים מבוצרים (bastion host) על סמך הדרישות העסקיות שלכם.
- מסמכי תיעוד תיעוד נוסף למשימות כמו הגדרת אישורים.
יצירת קובץ אימג' של מכונה וירטואלית של יעד מבוצר (bastion host)
בקטע הזה מוסבר איך ליצור קובץ אימג' של מכונה וירטואלית של יעד מבוצר (bastion host) מקוד המקור ש-Google מספקת. הוראות מלאות מופיעות בקובץ README שמצורף לקוד המקור.
דרישות מוקדמות
כדי ליצור תמונת מכונה וירטואלית של יעד מבוצר (bastion host), צריך את הפריטים הבאים:
- מחשב עם Debian 11.
- קובץ האימג' העדכני ביותר של שרת הענן של Debian.
- התוכנות
qemu-img,qemu-system-x86_x64ו-GNUmtoolsשהותקנו במחשב. - קובץ בשם
host-user-key.pubשמכיל מפתח SSH ציבורי להתחברות למופע של יעד מבוצר (bastion host) ולהפעלת סשןhost-user. אפשר להשתמש במפתח הזה לאימות ישיר או כמפתח חתימה של רשות אישורים. מופע של יעד מבוצר (bastion host) צריך להיות מהימן על ידי ה-CA הזה. - קובץ בשם
admin-user-key.pubשמכיל מפתח ציבורי SSH לביצוע משימות ניהול במכונת המארח של ה-bastion. אפשר להשתמש במפתח הזה לאימות ישיר או כמפתח חתימה של רשות אישורים. מופע של יעד מבוצר (bastion host) צריך להיות מהימן על ידי ה-CA הזה. - קובץ בשם
guest-user-key.pubשמכיל מפתח חתימה של רשות אישורים ציבורית של SSH, שסופק על ידי Google ומאפשר לתמיכה של Google לבצע אימות בתורguest-userכשמתחברים למופע של יעד מבוצר (bastion host).
יצירת קובץ אימג' של מכונה וירטואלית
פועלים לפי ההוראות שמופיעות בקובץ README שמצורף לקוד המקור כדי ליצור את קובץ האימג' של המכונה הווירטואלית של מארח הבסטיון מקוד המקור שסופק על ידי Google. בדוגמאות במדריך הזה, קובץ התמונה שנוצר נקרא bastion-host.img.
יצירת חבילת HIBA
כדי ליצור את חבילת ההתקנה של Debian עבור שכבת האימות של תוכנת ההרשאות מבוססת-זהות מארח (HIBA) ל-SSH:
מתקינים את יחסי התלות הנדרשים באמצעות הפקודה הבאה:
sudo apt-get install autoconf autogen build-essential git libssl-dev libtool zlib1g-dev
מריצים את הפקודה הבאה כדי ליצור את חבילת ההתקנה:
./build-hiba.sh -j $(nproc) /tmp/hiba-build-workdir
חבילת ההתקנה מועברת לספרייה /tmp/hiba-build-workdir והשם שלה הוא hiba_x.y-z_amd64.deb, כאשר x, y ו-z מציינים את מספר הגרסה של HIBA.
יצירת הגדרות cloud-init
משתמשים בסקריפט generate-cloud-init.py כדי ליצור את ההגדרות הנדרשות של cloud-init.
אפשר גם ליצור את ההגדרות האלה באמצעות כלים משלכם. ההגדרות האלה מבצעות את הפעולות הבאות:
- יוצרים את חשבונות המשתמשים הנדרשים בתמונת המכונה הווירטואלית של יעד מבוצר (bastion host) ומגדירים את החשבונות האלה עם מפתחות ה-SSH שמתוארים בהמשך.
- מוסיפים סקריפט שמגביל את ההרשאות של חשבון
guest-userכך שיוכל להצטרף רק לסשן מרובה משתמשים של מסוף שכבר נוצר. - להוסיף סקריפטים שיוצרים ומנהלים סשן של טרמינל מולטיפלקסר.
- מכינים את קובצי ההגדרה של HIBA.
סקריפט generate-cloud-init.py דורש את חבילת HIBA שיצרתם קודם לכן, ואת שלושת הקבצים שמכילים את מפתחות ה-SSH הנדרשים. מריצים את הסקריפט באופן הבא:
./generate-cloud-init.py \ --hiba-package="${WORK_DIR}/hiba_1.0-1_amd64.deb" \ --host-user-key="HOST_USER_KEY_FILE" \ --manager-user-key="ADMIN_USER_KEY_FILE" \ --guest-user-ca="GUEST_USER_KEY_FILE" \ "${WORK_DIR}/cloud-init/"
מחליפים את מה שכתוב בשדות הבאים:
-
HOST_USER_KEY_FILE: הנתיב המלא והשם של קובץhost-user-key.pub. -
ADMIN_USER_KEY_FILE: הנתיב המלא והשם של קובץadmin-user-key.pub. -
GUEST_USER_KEY_FILE: הנתיב המלא והשם של קובץguest-user-key.pub.
הסקריפט מעביר את הקובץ cloud-init.img לספרייה cloud-init בתוך ספריית העבודה המקומית.
החלת ההגדרות של cloud-init על קובץ האימג' של המכונה הווירטואלית של יעד מבוצר (bastion host)
משתמשים בכלי qemu-system-x86_64 כדי להחיל את ההגדרות cloud-init שיצרתם קודם על קובץ האימג' של המכונה הווירטואלית של יעד מבוצר (bastion host), באופן הבא:
qemu-system-x86_64 \ -nographic \ -enable-kvm \ -smp 1 \ -m 1g \ -drive format=qcow2,index=0,file=${WORK_DIR}/bastion-host.img \ -drive format=raw,index=1,file=${WORK_DIR}/cloud-init/cloud-init.img \ -nic user,hostfwd=tcp::10022-:22
אם הפקודה הזו מחזירה שגיאה, יכול להיות שתצטרכו לשנות את גודל הדיסק בתמונה של מכונת ה-VM של מארח ה-bastion.
אחרי שמפעילים את המכונה הווירטואלית, אפשר לוודא שההגדרות הוחלו בהצלחה. הפלט שיוצג ביומני auditd יהיה דומה לזה:
[ 52.659013] cloud-init[615]: Cloud-init v. 20.4.1 finished at Fri, 28 Apr 2023 18:53:55 +0000.
אפשר גם לבדוק באופן ידני את חשבונות המשתמשים ואת ההגדרות של sshd כדי לאמת אותם.
ייבוא של קובץ אימג' של מכונה וירטואלית של יעד מבוצר (bastion host)
לפני שמייבאים את קובץ האימג' של המכונה הווירטואלית של יעד מבוצר (bastion host) שהוגדר במלואו אל תשתית הפריסה, צריך ליצור לו תמונת מצב באמצעות הכלי qemu-img באופן הבא:
qemu-img snapshot -c installed bastion-image.img
פועלים לפי התהליכים שנקבעו בארגון כדי לייבא את קובץ האימג' של המכונה הווירטואלית של יעד מבוצר (bastion host) לתשתית הפריסה.
הגדרת המכונה הווירטואלית של יעד מבוצר (bastion host)
כדי להגדיר מכונה וירטואלית של יעד מבוצר (bastion host), פועלים לפי השלבים שמפורטים בקטע הזה.
הגדרת חשבונות המשתמשים הנדרשים
התכונה 'יעד מבוצר (bastion host)' ב-Distributed Cloud במודל מחובר דורשת חשבון משתמש אחד או יותר בכל אחת מהקטגוריות הבאות:
- ניהול. זהו חשבון האדמין של המכונה הווירטואלית של יעד מבוצר (bastion host). יש לו גישת רוט (Root).
- משתמש מארח. זה החשבון של מהנדס התפעול. הוא יכול להתחיל ולנהל סשנים של טרמינל מולטיפלקסר לתמיכה של Google, אבל הוא לא יכול להזין פקודות בסשנים האלה.
- משתמש אורח. זהו חשבון של מהנדס תמיכה של Google. הוא יכול ליצור חיבור SSH בתוך סשן של טרמינל מולטיפלקסר שמשותף עם מהנדס התפעול שלכם במכונה וירטואלית של יעד מבוצר (bastion host). אין לו הרשאות אחרות.
- משתמש משותף. חשבון זה יוצר את סשן ה-terminal multiplexer במכונה הוירטואלית של יעד מבוצר (bastion host). מהנדס התפעול שלכם ומהנדס תמיכה של Google יתחברו יחד לסשן הזה.
הגדרת אישורים
צריך להגדיר אישורים שמאפשרים לחשבונות שמתוארים בקטע הקודם לגשת למכונה הוירטואלית של יעד מבוצר (bastion host). חבילת התוכנה של יעד מבוצר (bastion host) כוללת סקריפט בשם generate-cloud-init.py שיוצר את ההגדרה הנדרשת cloud-init עם החשבונות, מפתחות ה-SSH והאישורים הנדרשים לכל חשבון.
הוראות מפורטות מופיעות במאמר יצירת קובצי ההגדרות של cloud-init.
הגדרת רישום ביומן
יומני יעד מבוצר (bastion host) זמינים בזמן אמת ועל פי דרישה מהדימון (daemon) audit.
אפשר לנהל את הגדרות הרישום ביומן באמצעות הקובץ auditd.conf. אתם אחראים לסיבוב ולייצוא של יומנים ממכונות וירטואליות של יעד מבוצר (bastion host) על סמך הדרישות העסקיות שלכם. בנוסף, צריך להקצות מספיק מקום בדיסק כדי לאחסן אותם במכונה הווירטואלית.
בדיקת ההגדרה
כדי להשלים את השלבים בקטע הזה ולבדוק את ה-Deployment (פריסה) של המכונה הווירטואלית של יעד מבוצר (bastion host), כולל הקישוריות משני הצדדים ובקרת הגישה המתאימה לחשבונות המשתמשים הנדרשים, צריך לבצע את השלבים שמפורטים בקטע הזה. מומלץ גם לפנות לתמיכה של Google כדי לבצע בדיקה של גרסה פעילה.
בדיקה מקומית של הפריסה
מוודאים שאפשר ליצור סשן SSH בתור
host-userעם המכונה הווירטואלית של יעד מבוצר (bastion host). אם הפעולה נכשלת, צריך לבדוק את מפתחות ה-SSH ואת האישורים.מוודאים שאפשר להתחיל סשן של טרמינל מולטיפלקסר באמצעות הפקודה הבאה:
./opt/create-shared-tmux-session
מריצים את הפקודה הבאה כדי לוודא שאפשר להגיע לפריסה המחוברת של Distributed Cloud מהמכונה הווירטואלית של יעד מבוצר (bastion host):
ssh -vv bastion-user@TARGET_ADDRESS
מחליפים את
TARGET_ADDRESSבכתובת ה-IP של מכונת Distributed Cloud או של מתג ToR.הבקשה תידחה על ידי אימות SSH, אבל בקשות התעבורה והאימות של SSH עדיין צריכות להגיע לפריסה המחוברת של Distributed Cloud. אם הפעולה הזו נכשלת, צריך לבדוק את הגדרות חומת האש.
מוודאים ש-Access Transparency ואישור הגישה הופעלו בארגון Google Cloud ובפרויקט היעד, כמו שמתואר בהמשך המדריך הזה.
בדיקת הפריסה בזמן אמת עם צוות התמיכה של Google
אחרי שתסיימו לבדוק את ה-Deployment (פריסה) של יעד מבוצר (bastion host) באופן מקומי, תוכלו ליצור קשר עם תמיכה של Google כדי לתאם פגישת בדיקה בזמן אמת. לפני הפגישה, צוות התמיכה של Google ישלח לכם בקשה לאישור גישה. במהלך סשן הבדיקה של הגרסה הפעילה, אתם ו-Google תבדקו את הנושאים הבאים:
- יצירה ואישור של בקשות לאישורי גישה.
- תהליך עבודה של גישה מקצה לקצה לפריסת יעד מבוצר (bastion host).
- יומנים של Access Approval ו-Access Transparency.
- איך פותרים את הבעיה בתרחישים הבאים:
- Google מנסה להתחבר למופע של יעד מבוצר (bastion host) שלא צוין בבקשה לאישור גישה.
- Google מנסה להתחבר למכונה של יעד מבוצר (bastion host) כשלא התחלתם סשן של טרמינל מולטיפלקסר.
- Google מנסה להתחבר למופע של יעד מבוצר (bastion host) אחרי שבקשת אישור הגישה המתאימה נדחתה או בוטלה.
- התנתקות מהטרמינל או סיום הפעילות של הטרמינל.
המאמרים הבאים
- פריסת עומסי עבודה ב-Distributed Cloud במודל מחובר
- ניהול מכונות
- יצירה וניהול של אשכולות
- יצירה וניהול של רשתות
- יצירה וניהול של מאגרי צמתים