במסמך הזה מפורטות שיטות מומלצות ליצירת סביבת רישות מאובטחת ועמידה לעומסי עבודה של AI Hypercomputer. ההמלצות האלה מיועדות לאדריכלי רשת, למהנדסי רשת ולמפתחים שרוצים להגדיר ולפרוס עומסי עבודה של בינה מלאכותית (AI) ולמידת מכונה (ML) ב-AI Hypercomputer.
הגדרת תפקידים ברורים ומוגבלים ב-IAM
הגדרה נכונה של IAM עוזרת לשפר את האבטחה ואת ההצלחה של פריסות AI Hypercomputer. בסביבות ייצור, הרשאות לא מספיקות או הרשאות שהוגדרו בצורה שגויה עלולות להוביל לכשלים בפריסה. פריסות של AI Hypercomputer, במיוחד כאלה שמשתמשות ב-Cluster Toolkit, נכשלות לעיתים קרובות בסביבות עם אמצעי אבטחה מחמירים שבהן לחשבון השירות שמשמש כברירת המחדל של Compute Engine אין את התפקיד Editor עם ההרשאות הרחבות.
כדי לצמצם את הסיכוי לבעיות בהטמעה שעלולות לקרות בגלל בעיות בהרשאות, כדאי לפעול לפי השיטות המומלצות שמפורטות בקטע הזה.
שימוש בחשבונות שירות ייעודיים
כדי לשפר את האבטחה והשליטה, מומלץ להימנע משימוש בחשבון השירות שמוגדר כברירת מחדל של Compute Engine. במקום זאת, צריך ליצור חשבון שירות ייעודי לפריסת AI Hypercomputer.
הענקת תפקידי IAM נדרשים
מקצים לחשבון השירות הייעודי שיצרתם את תפקידי ה-IAM הבאים:
- אדמין Compute (
roles/compute.admin): מאפשר שליטה מלאה במשאבי Compute Engine. - משתמש בחשבון השירות (
roles/iam.serviceAccountUser): מאפשר לצרף את חשבון השירות למשאבים אחרים, וזה חשוב לכלים כמו Packer כשיוצרים תמונות בהתאמה אישית. - אדמין לניהול נפח האחסון (
roles/storage.admin): נדרשת גישה לקטגוריות של Cloud Storage וניהול שלהן, למשל כדי לאחסן תמונות של Packer או פריטים אחרים. - אדמין של יומנים (
roles/logging.admin): מאפשר לחשבון השירות להגדיר יומנים ולהציג אותם, וזה חיוני לניפוי באגים.
אימות ההרשאות לפני הפריסה
לפני שמתחילים פריסה, צריך לוודא שלחשבון השירות יש את ההרשאות הנדרשות. מריצים את הפקודה gcloud projects get-iam-policy:
gcloud projects get-iam-policy PROJECT_ID \
--flatten="bindings[].members" \ format='table(bindings.role)' \
--filter="bindings.members:serviceAccount:SERVICE_ACCOUNT_EMAIL"
מחליפים את מה שכתוב בשדות הבאים:
-
PROJECT_ID: מזהה הפרויקט ב- Google Cloud . -
SERVICE_ACCOUNT_EMAIL: כתובת האימייל של חשבון השירות שרוצים לאמת.
הפקודה הזו מציגה את כל התפקידים שמוקצים לחשבון השירות בפרויקט שצוין. מוודאים שהתפקידים שמפורטים בקטע מתן התפקידים הנדרשים ב-IAM מופיעים בפלט.
הגבלת הגישה לרשת ציבורית וחיזוק ההגדרות של חומת האש
כדי לשפר את האבטחה, כדאי להגביל את הגישה לרשתות ציבוריות ולחזק את ההגדרות של חומת האש. השיטה הבסיסית הזו לאבטחה מצמצמת את הסיכון לכללי חומת אש שברירת המחדל שלהם היא מתן הרשאות רחבות מדי.
יכול להיות שיהיו כשלים בהגדרת מכונה וירטואלית (VM) בסביבות ייצור בגלל הגדרות חומת אש מגבילות שלא קיימות בבדיקות פנימיות. מהנדסים עלולים להתקשות באבחון הכשלים האלה בלי לדעת את כללי חומת האש הספציפיים.
כדי לצמצם את החשיפה הישירה לאינטרנט, צריך לבדוק ולעדכן את הכללים של חומת האש. מידע נוסף על הכללים של חומת האש ב-VPC זמין במאמר הכללים של חומת האש ב-VPC.
סטנדרטיזציה של ברירות המחדל של הרשת הפנימית
הגדרת ברירות מחדל סטנדרטיות לרשתות פנימיות כדי להפחית סיכונים ובעיות בהגדרות. התנהגויות ברירת מחדל של רשתות עלולות ליצור סיכונים או אתגרים בהגדרות בסביבות מורכבות או בסביבות שבהן האבטחה מוגברת. Google ממליצה על ההגדרות הבאות:
- שימוש ב-Zonal DNS: בפרויקטים חדשים, מגדירים את מערכת שמות הדומיינים (DNS) הפנימית ל-Zonal DNS בלבד. הגישה הזו עוזרת לצמצם את ההשפעה של הפסקת שירות DNS גלובלית פוטנציאלית. מידע נוסף על שימוש ב-DNS אזורי זמין במאמר סקירה כללית של שימוש ב-DNS אזורי.
- השבתה של כתובות IP חיצוניות: כשזה אפשרי, משביתים כתובות IP חיצוניות. לפני שמשביתים את כתובות ה-IP, צריך לתכנן ולבדוק בקפידה בסביבת פיתוח, כי שירותים מסוימים כמו קבוצות מנוהלות של מופעים (MIG) או אשכולות GKE עם צמתים ציבוריים מסתמכים עליהן. מידע נוסף על הגבלת כתובות IP ציבוריות זמין במאמר הגבלת כתובות IP ציבוריות ב-Google Cloud.
סיכום השיטות המומלצות
בטבלה הבאה מפורטות השיטות המומלצות שמופיעות במסמך הזה:
| נושא | משימה |
|---|---|
| IAM | הגדרת תפקידים ברורים ומוגבלים ב-IAM |
| חומת אש | הגבלת הגישה לרשת ציבורית וחיזוק ההגדרות של חומת האש |
| ברירות מחדל של רשת | קביעת ברירות מחדל סטנדרטיות לרשתות פנימיות |
המאמרים הבאים
- מידע נוסף על שיטות מומלצות לשימוש בחשבונות שירות
- מידע נוסף על כללי חומת אש של VPC
- מידע נוסף על ארכיטקטורת רשת AI Hypercomputer