בידוד עומסי עבודה במאגרי צמתים ייעודיים

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

סקירה כללית

באשכולות GKE ב-AWS נעשה שימוש בעומסי עבודה עם הרשאות מיוחדות שאנחנו מנהלים, כדי להפעיל פונקציונליות ותכונות ספציפיות של האשכול, כמו איסוף מדדים. לעומסי העבודה האלה מוקצות הרשאות מיוחדות כדי שהם יפעלו בצורה תקינה באשכול.

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

מניעת בריחה מקונטיינרים

ההגנה העיקרית שלכם צריכה להיות האפליקציות. ל-GKE ב-AWS יש כמה תכונות שבהן אפשר להשתמש כדי להקשיח את האשכולות ואת ה-Pods. ברוב המקרים, מומלץ מאוד להשתמש ב-Policy Controller ובתכונות אבטחה של ליבת מערכת ההפעלה כדי לחזק את עומסי העבודה. המלצות נוספות בנושא אבטחה מופיעות בסקירה הכללית על אבטחה.

איך נמנעים מהתקפות של הסלמת הרשאות

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

הכתמת צומת אומרת ל-GKE ב-AWS להימנע מתזמון עומסי עבודה ללא טולרנטיות תואמת (כמו עומסי עבודה שמנוהלים על ידי GKE ב-AWS) בצמתים האלה. ההגדרה של זיקה לצומת בעומסי העבודה שלכם אומרת ל-GKE on AWS לתזמן את ה-Pods בצמתים הייעודיים.

המגבלות של בידוד הצמתים

  • תוקפים עדיין יכולים ליזום התקפות מניעת שירות (DoS) מהצומת שנפרץ.
  • צמתים שנפרצו עדיין יכולים לקרוא משאבים רבים, כולל כל ה-Pods ומרחבי השמות באשכול.
  • צמתים שנפרצו יכולים לגשת לערכי Secrets ולפרטי הכניסה שמשמשים כל Pod שפועל בצומת הזה.
  • שימוש במאגר צמתים נפרד כדי לבודד את עומסי העבודה יכול להשפיע על היעילות של העלויות, על התאמה אוטומטית לעומס ועל ניצול המשאבים.
  • צמתים שנפרצו עדיין יכולים לעקוף את מדיניות הרשת לתעבורת נתונים יוצאת (egress).
  • חלק מעומסי העבודה שמנוהלים על ידי GKE ב-AWS צריכים לפעול בכל צומת באשכול, והם מוגדרים כך שיוכלו לפעול גם בצמתים עם כל ההגבלות.
  • אם פורסים DaemonSets עם הרשאות גבוהות שיכולים לסבול כל taint, יכול להיות שה-Pods האלה יהיו דרך להסלמת הרשאות מצומת שנפרצה.

איך פועל בידוד הצמתים

כדי להטמיע בידוד של צמתים בעומסי העבודה, צריך לבצע את הפעולות הבאות:

  1. הוספת כתם ותווית למאגר צמתים בשביל עומסי העבודה.
  2. מעדכנים את עומסי העבודה עם כלל הסבילות והזיקה לצומת המתאים.

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

לפני שמתחילים

כדי לבצע את השלבים בדף הזה, קודם צריך לבצע את הפעולות הבאות:

הוספת כתם ותווית למאגר צמתים בשביל עומסי העבודה

יוצרים מאגר צמתים חדש לעומסי העבודה ומחילים עליו taint של צומת ותווית צומת. כשמחילים דחייה (taint) או תווית ברמת מאגר הצמתים, כל הצמתים החדשים, כמו אלה שנוצרו על ידי התאמה אוטומטית לעומס (automatic scaling), מקבלים באופן אוטומטי את הדחייה (taint) והתוויות שצוינו.

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

כדי להוסיף taint ותווית למאגר צמתים חדש, מריצים את הפקודה הבאה:

gcloud container aws node-pools create POOL_NAME \
    --cluster CLUSTER_NAME \
    --node-taints TAINT_KEY=TAINT_VALUE:TAINT_EFFECT \
    --node-labels LABEL_KEY=LABEL_VALUE

מחליפים את מה שכתוב בשדות הבאים:

  • ‫POOL_NAME: השם של מאגר הצמתים החדש לעומסי העבודה.
  • ‫CLUSTER_NAME: השם של אשכול GKE ב-AWS.
  • ‫TAINT_KEY=TAINT_VALUE: זוג מפתח/ערך שמשויך לתזמון TAINT_EFFECT. לדוגמה: workloadType=untrusted.
  • ‫TAINT_EFFECT: אחד מערכי האפקט הבאים: NoSchedule,‏ PreferNoSchedule או NoExecute. ‫NoExecute מספקת התחייבות טובה יותר לפינוי מאשר NoSchedule.
  • ‫LABEL_KEY=LABEL_VALUE: צמדי מפתח/ערך של תוויות הצמתים, שתואמים לסלקטורים שציינתם במניפסטים של עומסי העבודה.

הוספת כלל טולרנטיות וכלל שיוך צומת לעומסי העבודה

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

אם הוספתם תווית למאגר הצמתים הייעודי, אתם יכולים גם להוסיף כלל של זיקה לצומת כדי להגדיר ל-GKE on AWS לתזמן את עומסי העבודה רק במאגר הצמתים הזה.

בדוגמה הבאה מוסיפים toleration ל-taint‏ workloadType=untrusted:NoExecute וכלל של node affinity לתווית הצומת workloadType=untrusted.

kind: Deployment
apiVersion: apps/v1
metadata:
  name: my-app
  namespace: default
  labels:
    app: my-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      tolerations:
      - key: TAINT_KEY
        operator: Equal
        value: TAINT_VALUE
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: LABEL_KEY
                operator: In
                values:
                - "LABEL_VALUE"
      containers:
      - name: sleep
        image: ubuntu
        command: ["/bin/sleep", "inf"]

מחליפים את מה שכתוב בשדות הבאים:

  • ‫TAINT_KEY: מפתח הכתם שהוחל על מאגר הצמתים הייעודי.
  • ‫TAINT_VALUE: ערך ה-taint שהוחל על מאגר הצמתים הייעודי.
  • ‫LABEL_KEY: מפתח התווית של הצומת שהוספתם למאגר הצמתים הייעודי.
  • ‫LABEL_VALUE: ערך התווית של הצומת שהחלתם על מאגר הצמתים הייעודי.

כשמעדכנים את הפריסה באמצעות kubectl apply, ‏ GKE on AWS יוצר מחדש את ה-Pods המושפעים. כלל ההתאמה של הצומת מאלץ את ה-Pods להיכנס למאגר הצמתים הייעודי שיצרתם. הסבילות מאפשרת להציב רק את ה-Pods האלה בצמתים.

איך מוודאים שההפרדה פועלת

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

kubectl get pods -o=wide

המלצות ושיטות מומלצות

אחרי שמגדירים בידוד של צמתים, מומלץ לבצע את הפעולות הבאות:

  • כדי להגביל מאגרי צמתים ספציפיים לעומסי עבודה שמנוהלים על ידי GKE ב-AWS בלבד, מוסיפים את ה-taint‏ components.gke.io/gke-managed-components. הוספת ההכתמה הזו מונעת מה-Pods שלכם להיות מתוזמנים בצמתים האלה, וכך משפרת את הבידוד.
  • כשיוצרים מאגרי צמתים חדשים, אפשר למנוע מרוב עומסי העבודה שמנוהלים על ידי GKE ב-AWS לפעול בצמתים האלה על ידי הוספת כתם משלכם למאגרי הצמתים האלה.
  • בכל פעם שפורסים עומסי עבודה חדשים באשכול, למשל כשמתקינים כלי צד שלישי, צריך לבדוק את ההרשאות שנדרשות ל-Pods. ככל האפשר, מומלץ להימנע מפריסת עומסי עבודה שמשתמשים בהרשאות מורחבות לצמתים משותפים.

המאמרים הבאים