אכיפה סלקטיבית של כללי מדיניות של חומת אש ב-GKE

בדף הזה מוסבר איך לאכוף באופן סלקטיבי מדיניות של חומת אש ברשת Cloud Next Generation Firewall ב-Google Kubernetes Engine ‏ (GKE) באמצעות תגים. תגים מאפשרים לכם לארגן את היררכיית המשאבים בצורה פרטנית יותר בהשוואה ל Google Cloud היררכיית המשאבים שמוגדרת כברירת מחדל. התגים מאפשרים גם לאכוף מדיניות באופן מותנה.

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

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

מידע על תגים

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

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

שימוש בתגים כדי לאכוף מדיניות של חומת אש בין רשתות

אתם יכולים להשתמש בתגים כדי להחיל באופן מותנה מדיניות חומת אש בין רשתות גלובלית או אזורית על צמתי GKE. צריך להגדיר את GCE_FIREWALL המטרה של התגים שרוצים להשתמש בהם עם כללי מדיניות של חומת אש ברשת. כשמחילים תגי ייעוד של חומת אש על אשכולות GKE או על מאגרי צמתים, GKE מצרף באופן אוטומטי את התגים האלה למכונות הווירטואליות (VM) התואמות ב-Compute Engine.

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

תהליך העבודה של תגים למדיניות חומת אש בין רשתות

כדי להשתמש בתגים עם מדיניות חומת אש ברשת ב-GKE, צריך לבצע את הפעולות הבאות:

  1. יוצרים תג:

    1. מגדירים מפתח תג ברמת הארגון או הפרויקט, כמו env.
    2. מגדירים את הערכים האפשריים של התג למפתח, כמו dev,‏ staging ו-prod.

    3. מגדירים את התג לשימוש במדיניות חומת אש בין רשתות.

  2. נותנים למשתמשים גישה לאינטראקציה עם תג חומת האש.

  3. אפשר להחיל צמדי מפתח/ערך של תגים על אשכולות GKE ספציפיים, על מאגרי צמתים או להשתמש בהם ב-ComputeClasses בהתאמה אישית כדי להחיל אותם על צמתים עבור עומסי עבודה ספציפיים. מערכת GKE מצרפת את התגים באופן אוטומטי למכונות הווירטואליות הבסיסיות של Compute Engine כדי לאכוף את מדיניות חומת האש.

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

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

  • מפעילים את ממשק ה-API של Google Kubernetes Engine.
    • הפעלת Google Kubernetes Engine API
  • כדי להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז לאתחל את ה-CLI של gcloud. אם התקנתם בעבר את ה-CLI של gcloud, מריצים את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שגרסאות קודמות של ה-CLI של gcloud לא יתמכו בהרצת הפקודות שמופיעות במסמך הזה.

דרישות ומגבלות

  • תגים למדיניות חומת אש ברשת נתמכים ב-GKE בגרסה 1.28 ואילך. אם אתם משתמשים בגרסה של GKE שקודמת לגרסה 1.28, אתם צריכים להשתמש במקום זאת בתגי רשת עם כללים לחומת אש של VPC.
  • אפשר להשתמש בתגים שאינם חומת אש במאגרי צמתים ב-GKE מגרסה 1.34 ואילך, ועם ComputeClasses בהתאמה אישית מגרסה 1.35.0-gke.2398000 ואילך.
  • כל אחד ממאגרי הצמתים הרגילים, מאגדי Autopilot ומ-ComputeClasses בהתאמה אישית תומך בעד חמישה תגים בסך הכול (כולל תגים של חומת אש ותגים שאינם של חומת אש).
  • ‫GKE דוחה מפתחות תגים שמשתמשים בקידומת gke-managed.
  • כדי לצרף צמדים של מפתח/ערך של תגים לאשכולות או למאגרי צמתים, צריך ליצור אותם קודם.

תפקידים והרשאות של IAM

כדי לקבל את ההרשאות שדרושות לשימוש בתגים בכללי מדיניות של חומת אש ב-GKE, צריך לבקש מהאדמין להקצות לכם את תפקידי ה-IAM הבאים:

  • כדי לתת את ההרשאות הנדרשות לתגים למשתמשים ולסוכני שירות של GKE:
  • כדי ליצור ולנהל תגים: Tag Administrator ‏ (roles/resourcemanager.tagAdmin) בארגון או בפרויקט
  • כדי לצרף תגים למשאבים: Tag User (roles/resourcemanager.tagUser) בפרויקט

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

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

יצירת תגים

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

מפתחות תגים יכולים לקבל את הערך parent של projects/PROJECT_ID או organizations/ORGANIZATION_ID

כדי להשתמש במפתח תג מאובטח עם Cloud NGFW, צריך להגדיר את המאפיין purpose לערך GCE_FIREWALL, ולציין את הערך של המאפיין purpose-data כ-network או כ-organization=auto.

  1. יוצרים את מפתח התג:

    • יוצרים את מפתח התג ברמת הרשת:

      מפתח התג הזה מוגבל לרשת ה-VPC שצוינה בשדה purpose-data.

      gcloud resource-manager tags keys create TAG_KEY \
    --parent=projects/PROJECT_ID \
    --purpose=GCE_FIREWALL \
    --purpose-data=network=PROJECT_ID/NETWORK_NAME

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

      • ‫TAG_KEY: השם של מפתח התג, למשל env
      • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud
      • ‫NETWORK_NAME: השם של רשת ה-VPC שבה תשתמשו בתג

    • יוצרים את מפתח התג בהיקף הארגון:

      אפשר להשתמש במפתח התג הזה בכל רשת VPC בארגון.

      gcloud resource-manager tags keys create TAG_KEY \
    --parent=projects/PROJECT_ID \
    --purpose=GCE_FIREWALL \
    --purpose-data=organization=auto

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

      • ‫TAG_KEY: השם של מפתח התג, למשל env
      • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud

      הערך organization=auto יוחלף אוטומטית במזהה הארגון. לדוגמה:

      purposeData:
  organization: '123456789012'

  2. מאתרים את המזהה של מפתח התג:

    gcloud resource-manager tags keys describe PROJECT_ID/TAG_KEY \
    --format="value(name)"

    הפלט הוא tagKeys/KEY_ID, כאשר KEY_ID הוא מזהה מספרי של המפתח. חשוב לרשום את המזהה הזה כדי להשתמש בו בהמשך.

  3. מוסיפים ערך תג למפתח התג:

    gcloud resource-manager tags values create TAG_VALUE \
    --parent=tagKeys/KEY_ID

    מחליפים את TAG_VALUE בשם של ערך מותר למפתח התג הזה, כמו dev.

שימוש בתחביר תגים נכון בפקודות של ה-CLI של gcloud

כשמפנים לתגים באמצעות ה-CLI של gcloud, צריך לעצב את צמדי מפתח/ערך באמצעות אחת מהתחבירות הבאות:

תחביר התגים 
tagKeys/KEY_ID=tagValues/VALUE_ID

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

  • ‫KEY_ID: מזהה המפתח המספרי
  • ‫VALUE_ID: מזהה הערך המספרי

לדוגמה, tagKeys/123456789=tagValues/987654321.

 
ORGANIZATION_ID/TAG_KEY=TAG_VALUE

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

  • ‫ORGANIZATION_ID: מזהה הארגון המספרי Google Cloud
  • ‫TAG_KEY: השם של מפתח התג שיצרתם
  • ‫TAG_VALUE: השם של ערך התג שיצרתם

לדוגמה, 12345678901/env=dev.

 
PROJECT_ID/TAG_KEY=TAG_VALUE

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

  • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud
  • ‫TAG_KEY: השם של מפתח התג שיצרתם
  • ‫TAG_VALUE: השם של ערך התג שיצרתם

לדוגמה, example-project/env=dev.

 
PROJECT_NUMBER/TAG_KEY=TAG_VALUE

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

  • ‫PROJECT_ID: המזהה המספרי של הפרויקט ב- Google Cloud
  • ‫TAG_KEY: השם של מפתח התג שיצרתם
  • ‫TAG_VALUE: השם של ערך התג שיצרתם

לדוגמה, 11223344556/env=dev.

טירגוט תגים באמצעות מדיניות חומת אש

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

מתן הרשאות IAM לסוכני שירות

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

  1. מקצים את התפקיד Tag User (roles/resourcemanager.tagUser) לסוכן השירות של Kubernetes Engine:

    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com \
    --role=roles/resourcemanager.tagUser \
    --condition=None

    מחליפים את הערך PROJECT_NUMBER במספר הפרויקט Google Cloud של האשכול. כדי למצוא את מספר הפרויקט, מריצים את הפקודה הבאה:

    gcloud projects describe PROJECT_ID --format="value(projectNumber)"

  2. מקצים את התפקיד 'אדמין של תגי השהיה' (roles/resourcemanager.tagHoldAdmin) לסוכן השירות של Kubernetes Engine לצמד מפתח/ערך של התג:

    gcloud resource-manager tags values add-iam-policy-binding PROJECT_ID/TAG_KEY/TAG_VALUE \
    --member=serviceAccount:service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com \
    --role=roles/resourcemanager.tagHoldAdmin

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

  3. מקצים את התפקיד Tag User ‏(roles/resourcemanager.tagUser) לסוכן שירות של Google APIs:

    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:PROJECT_NUMBER@cloudservices.gserviceaccount.com \
    --role=roles/resourcemanager.tagUser \
    --condition=None

הקצאת תפקידי IAM נוספים לתגים מחוץ לפרויקט

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

  1. נותנים לסוכן השירות של Kubernetes Engine גישה לתגים במשאב האב עם התפקיד Tag User (roles/resourcemanager.tagUser):

    gcloud resource-manager tags keys add-iam-policy-binding PARENT_RESOURCE/TAG_KEY \
    --member=serviceAccount:service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com \
    --role=roles/resourcemanager.tagUser \
    --condition=None

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

    • ‫PARENT_RESOURCE: מזהה הפרויקט או מזהה הארגון של המשאב שבבעלותו התג הזה
    • ‫PROJECT_NUMBER: מספר הפרויקט של פרויקט האשכול

  2. נותנים לסוכן השירות של Google APIs גישה לתגים במשאב האב באמצעות התפקיד Tag User (משתמש בתגים) (roles/resourcemanager.tagUser):

    gcloud resource-manager tags keys add-iam-policy-binding PARENT_RESOURCE/TAG_KEY \
    --member=serviceAccount:PROJECT_NUMBER@cloudservices.gserviceaccount.com \
    --role=roles/resourcemanager.tagUser \
    --condition=None

  3. מקצים את התפקיד Tag Holds Administrator (אדמין של תגי השהיה) ‏(roles/resourcemanager.tagHoldAdmin) לסוכן השירות של Kubernetes Engine לצמד מפתח/ערך של התג:

    gcloud resource-manager tags values add-iam-policy-binding PARENT_RESOURCE/TAG_KEY/TAG_VALUE \
    --member=serviceAccount:service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com \
    --role=roles/resourcemanager.tagHoldAdmin

צירוף תגי חומת אש לאשכולות של Autopilot

מצרפים תגי חומת אש לאשכולות Autopilot ברמת האשכול. ‫GKE מחיל באופן אוטומטי את התגים האלה ברמת האשכול על כל צומת.

צירוף תגים כשיוצרים אשכול חדש של Autopilot

מריצים את הפקודה הבאה:

gcloud container clusters create-auto CLUSTER_NAME \
    --location=LOCATION \
    --autoprovisioning-resource-manager-tags=TAG1,TAG2,...

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

  • ‫CLUSTER_NAME: השם של האשכול החדש.
  • ‫LOCATION: האזור של Compute Engine שבו נמצא האשכול.
  • ‫TAG1,TAG2,...: קבוצה מופרדת בפסיקים של צמדי מפתח/ערך לצירוף. לכל צמד של מפתח וערך צריך להיות תחביר נתמך, כפי שמתואר בקטע תחביר התגים בפקודות. לדוגמה, example-project/env=dev,1234567901/team=sre.

צירוף תגים לאשכולות קיימים של Autopilot

מריצים את הפקודה הבאה:

gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --autoprovisioning-resource-manager-tags=TAG1,TAG2,...

כשמעדכנים את התגים באשכול, GKE דורס את כל התגים הקיימים בכל הצמתים.

צירוף תגי חומת אש לאשכולות ולמאגרי צמתים מסוג Standard

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

תגי חומת אש סטנדרטיים של אשכול
--autoprovisioning-resource-manager-tags

הגדרה ברמת האשכול

‫GKE מחיל את התגים על כל מאגרי הצמתים החדשים שהוקצו אוטומטית באשכול.

אם משתמשים בדגל הזה באשכול קיים, מערכת GKE לא מוסיפה את התגים למאגרי הצמתים הקיימים באשכול. מאגרי צמתים קיימים שומרים על התגים שכבר הוחלו לפני העדכון. כדי לעדכן את התגים של מאגרי צמתים קיימים, משתמשים בדגל --resource-manager-tags.
--resource-manager-tags

הגדרה ברמת מאגר הצמתים

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

צירוף תגי חומת אש לאשכולות רגילים

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

צירוף תגים לאשכול רגיל חדש עם הקצאת משאבים אוטומטית לצמתים

כברירת מחדל, GKE משתמש בתגים ברמת האשכול לצמתים חדשים שהוקצו אוטומטית. מאגר הצמתים שמוגדר כברירת מחדל ש-GKE יוצר באשכול לא מוקצה באופן אוטומטי ולא מקבל את התגים האלה.

gcloud container clusters create CLUSTER_NAME \
    --location=LOCATION \
    --autoprovisioning-resource-manager-tags=TAG1,TAG2,... \
    --enable-autoprovisioning \
    --max-cpu=MAX_CPU \
    --max-memory=MAX_MEMORY

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

  • ‫CLUSTER_NAME: השם של האשכול החדש
  • ‫LOCATION: האזור או התחום של Compute Engine שבו נמצא האשכול
  • ‫TAG1,TAG2,...: קבוצה מופרדת בפסיקים של צמדי מפתח/ערך לצירוף. לכל צמד של מפתח וערך צריך להיות תחביר נתמך, כפי שמתואר בקטע תחביר התגים בפקודות. לדוגמה, example-project/env=dev,1234567901/team=sre.
  • ‫MAX_CPU: המספר המקסימלי של ליבות לאשכול
  • ‫MAX_MEMORY: נפח הזיכרון המקסימלי של האשכול בג'יגה-בייט

צירוף תגים כשמפעילים הקצאת משאבים אוטומטית של צמתים באשכול קיים

‫GKE מחיל את התגים האלה רק על מאגרי צמתים חדשים שהוקצו אוטומטית. מאגרי צמתים קיימים ישמרו על התגים שהיו להם לפני העדכון.

  1. מצרפים תגים לאשכול:

    gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --autoprovisioning-resource-manager-tags=TAG1,TAG2,...

  2. הפעלת הקצאת צמתים אוטומטית (NAP) באשכול:

    gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --enable-autoprovisioning \
    --max-cpu=MAX_CPU \
    --max-memory=MAX_MEMORY

צירוף תגי חומת אש למאגרי צמתים

אפשר לצרף תגים למאגרי צמתים חדשים או קיימים, בלי קשר לשאלה אם הם משתמשים בהקצאת צמתים אוטומטית (NAP). מערכת GKE מתייחסת לתגים האלה כהגדרה ברמת מאגר הצמתים.

צירוף תגים למאגר הצמתים שמוגדר כברירת מחדל

כשיוצרים אשכול, GKE מצרף את התגים שמציינים באמצעות הדגל --resource-manager-tags למאגר הצמתים שמוגדר כברירת מחדל ש-GKE יוצר באשכול.

gcloud container clusters create CLUSTER_NAME \
    --location=LOCATION \
    --resource-manager-tags=TAG1,TAG2,...

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

  • ‫CLUSTER_NAME: השם של האשכול החדש
  • ‫LOCATION: האזור או התחום של Compute Engine שבו נמצא האשכול
  • ‫TAG1,TAG2,...: קבוצה מופרדת בפסיקים של צמדי מפתח/ערך לצירוף. לכל צמד של מפתח וערך צריך להיות תחביר נתמך, כפי שמתואר בקטע תחביר התגים בפקודות. לדוגמה, example-project/env=dev,1234567901/team=sre.

צירוף תגים למאגר צמתים חדש

כשמשתמשים בדגל --resource-manager-tags במהלך יצירת מאגר הצמתים, GKE מצרף את התגים שציינתם למאגר הצמתים הזה.

gcloud container node-pools create NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --resource-manager-tags=TAG1,TAG2,...

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

  • ‫NODE_POOL_NAME: השם של מאגר הצמתים החדש
  • ‫CLUSTER_NAME: שם האשכול
  • ‫LOCATION: האזור או התחום של Compute Engine שבו נמצא האשכול
  • ‫TAG1,TAG2,...:קבוצה מופרדת בפסיקים של צמדי מפתח/ערך לצירוף. לכל צמד של מפתח וערך צריך להיות תחביר נתמך, כפי שמתואר בקטע תחביר התגים בפקודות. לדוגמה, example-project/env=dev,1234567901/team=sre.

צירוף תגים למאגר צמתים קיים

כשמעדכנים את התגים במאגר צמתים קיים באמצעות הדגל --resource-manager-tags, ‏ GKE מחליף את כל התגים הקיימים במאגר הצמתים הזה. אפשר להשתמש בפקודה הזו כדי לעדכן את התגים במאגרי צמתים שהוקצו אוטומטית.

gcloud container node-pools update NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --resource-manager-tags=TAG1,TAG2,...

מחליפים את NODE_POOL_NAME בשם של מאגר הצמתים שרוצים לעדכן.

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

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

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

  • כשמפעילים או משביתים הקצאת צמתים אוטומטית (NAP), מאגר הצמתים שומר על התגים הקיימים. ‫GKE לא מחליף את התגים האלה בתגים ברמת האשכול, גם במהלך יצירה מחדש של הצומת.
  • אם מעדכנים ידנית את התגים במאגרי צמתים ספציפיים, GKE מחליף את התגים הקיימים בתגים שצוינו למאגר הצמתים הזה.

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

אפשר להחיל תגי חומת אש על מאגרי צמתים ספציפיים באשכולות Autopilot ובאשכולות רגילים שמשתמשים בהקצאת צמתים אוטומטית (NAP) באמצעות ComputeClasses מותאמים אישית (CCC). סוג מחשוב מותאם אישית הוא משאב שמאפשר להגדיר קבוצת צמתים, כולל הגדרת התגים של מנהל המשאבים שיוחלו על הצמתים.

כשפורסים עומס עבודה שמבקש צומת עם תווית ספציפית של מחלקת מחשוב בהתאמה אישית, NAP בודק קודם אם כבר קיים מאגר צמתים שתואם לכל הדרישות של מחלקת המחשוב בהתאמה אישית, כולל תגי Resource Manager שצוינו.

אם לא קיים מאגר צמתים תואם, NAP יוצר מאגר צמתים חדש עבור עומס העבודה עם ההגדרה שצוינה ומצרף את התגים למכונות הווירטואליות הבסיסיות של Compute Engine. היצירה האוטומטית של מאגר הצמתים עוזרת לוודא שעומסי העבודה (workloads) פועלים בצמתים עם תגי חומת האש הנכונים לאכיפת המדיניות.

יצירת ComputeClass בהתאמה אישית באמצעות תגים

  1. כדי ליצור ComputeClass עם תגים, שומרים את קובץ המניפסט הבא בתור my-compute-class.yaml. בשדה resourceManagerTags, מציינים את מפתחות התגים והערכים שרוצים לשייך למאגרי הצמתים שנוצרים באמצעות המחלקה הזו.

    apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: COMPUTE_CLASS_NAME
spec:
    nodePoolConfig:
      resourceManagerTags:
        - key: "PROJECT_ID/TAG_KEY_1"
          value: "TAG_VALUE_1"
        - key: "ORGANIZATION_ID/TAG_KEY_2"
          value: "TAG_VALUE_2"
        - key: "tagKeys/KEY_ID"
          value: "tagValues/VALUE_ID"

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

    • ‫COMPUTE_CLASS_NAME: השם של סוג המכונה המותאם אישית, למשל my-custom-class.
    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
    • ‫TAG_KEY_1: השם של מפתח התג הראשון.
    • ‫TAG_VALUE_1: השם של ערך התג הראשון.
    • ‫ORGANIZATION_ID: מזהה הארגון המספרי ב- Google Cloud .
    • ‫TAG_KEY_2: השם של מפתח התג השני.
    • ‫TAG_VALUE_2: השם של ערך התג השני.
    • ‫KEY_ID: המזהה המספרי של מפתח התג.
    • ‫VALUE_ID: המזהה המספרי של ערך התג.

  2. החלת המניפסט:

    kubectl apply -f my-compute-class.yaml

אם מציינים תג לא תקין או אם לסוכני השירות של GKE אין את הרשאות ה-IAM הנדרשות לתג, GKE לא מקצה מאגר צמתים לעומס העבודה, ועומס העבודה נשאר במצב Pending. מידע נוסף על השגיאה זמין בשדה Status של משאב ComputeClass.

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

kubectl get cc COMPUTE_CLASS_NAME -o jsonpath='{.status}' | jq .

מחליפים את COMPUTE_CLASS_NAME בשם של מחלקת המחשוב המותאמת אישית.

טירגוט של מחלקת מחשוב בהתאמה אישית בעומס העבודה

  1. כדי לטרגט את ComputeClass שיצרתם, שומרים את המניפסט הבא בתור pod-with-ccc.yaml. במניפסט הזה נעשה שימוש בשדה nodeSelector כדי לטרגט את Compute Class.

    apiVersion: v1
kind: Pod
metadata:
  name: nginx-server
spec:
  nodeSelector:
    cloud.google.com/compute-class: "COMPUTE_CLASS_NAME"
  containers:
    - name: nginx
      image: nginx:latest

    מחליפים את COMPUTE_CLASS_NAME בשם של מחלקת המחשוב המותאמת אישית, לדוגמה, my-custom-class.

  2. החלת המניפסט:

    kubectl apply -f pod-with-ccc.yaml

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

איך מאשרים עומסי עבודה באמצעות מדיניות אימות של הרשאות גישה (VAP)

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

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

  1. שומרים את קובץ המניפסט הבא בשם restrict-toleration.yaml:

    # Copyright 2025 Google LLC
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#      http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: restrict-toleration
spec:
  failurePolicy: Fail
  paramKind:
    apiVersion: v1
    kind: ConfigMap
  matchConstraints:
    # GKE will mutate any pod specifying a CC label in a nodeSelector
    # or in a nodeAffinity with a toleration for the CC node label.
    # Mutation hooks will always mutate the K8s object before validating
    # the admission request.  
    # Pods created by Jobs, CronJobs, Deployments, etc. will also be validated.
    # See https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#admission-control-phases for details
    resourceRules:
    - apiGroups:   [""]
      apiVersions: ["v1"]
      operations:  ["CREATE", "UPDATE"]
      resources:   ["pods"]
  matchConditions:
    - name: 'match-tolerations'
      # Validate only if compute class toleration exists
      # and the CC label tolerated is listed in the configmap.
      expression: > 
        object.spec.tolerations.exists(t, has(t.key) &&
        t.key == 'cloud.google.com/compute-class' &&
        params.data.computeClasses.split('\\n').exists(cc, cc == t.value))
  validations:
    # ConfigMap with permitted namespace list referenced via `params`.
    - expression: "params.data.namespaces.split('\\n').exists(ns, ns == object.metadata.namespace)"
      messageExpression: "'Compute class toleration not permitted on workloads in namespace ' + object.metadata.namespace"

---
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicyBinding
metadata:
  name: restrict-toleration-binding
spec:
  policyName: restrict-toleration
  validationActions: ["Deny"]
  paramRef:
    name: allowed-ccc-namespaces
    namespace: default
    parameterNotFoundAction: Deny
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: allowed-ccc-namespaces
  namespace: default
data:
  # Replace example namespaces in line-separated list below.
  namespaces: |
    foo
    bar
    baz
  # ComputeClass names to monitor with this validation policy.
  # The 'autopilot' and 'autopilot-spot' CCs are present on
  # all NAP Standard and Autopilot clusters.
  computeClasses: |
    MY_COMPUTE_CLASS
    autopilot
    autopilot-spot

  2. החלת המניפסט:

    kubectl apply -f restrict-toleration.yaml

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

אימות תגי חומת האש באשכול

  • מציגים את רשימת התגים באשכולות של Autopilot:

    gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --format="value(nodePoolAutoConfig.resourceManagerTags)"

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

    • ‫CLUSTER_NAME: שם האשכול.
    • ‫LOCATION: האזור או התחום של Compute Engine שבו נמצא האשכול.

  • כדי להציג את התגים במאגרי צמתים ספציפיים:

    הפקודה הזו מאמתת גם תגים במאגרי צמתים שהוקצו אוטומטית על ידי Custom Compute Class.

    gcloud container node-pools describe NODE_POOL_NAME \
  --cluster=CLUSTER_NAME \
  --location=LOCATION \
  --format="value(config.resourceManagerTags)"

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

    • ‫NODE_POOL_NAME: שם מאגר הצמתים.
    • ‫CLUSTER_NAME: שם האשכול.
    • ‫LOCATION: האזור או התחום של Compute Engine שבו נמצא האשכול.

ניתוק תגי חומת אש מאשכולות וממאגרי צמתים

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

ניתוק תגים מקלאסטרים של Autopilot

מריצים את הפקודה הבאה:

gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --autoprovisioning-resource-manager-tags=

ניתוק תגים ממאגרי צמתים

  1. הסרת התגים של צומת ברמת האשכול autoprovisioning:

    gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --autoprovisioning-resource-manager-tags=

    ‫GKE לא יצרף תגים למאגרי צמתים חדשים שמוקצים אוטומטית.

  2. מנתקים תגים ממאגר הצמתים:

    gcloud container node-pools update NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --resource-manager-tags=

    ‫GKE מסיר תגים קיימים ממאגר הצמתים הזה.

מחיקת מפתחות וערכים של תגים

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

השוואה בין תגי רשת לבין תגים

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

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

השוואה מפורטת בין תגים לתגי רשת מופיעה במאמר השוואה בין תגים לתגי רשת במאמרי העזרה של Cloud NGFW.

הבדלים פונקציונליים במאגרי צמתים שהוקצו אוטומטית

באשכולות Autopilot ובמאגרי צמתים רגילים שלא משתמשים בהקצאת צמתים אוטומטית (NAP), תגי רשת ותגים מתנהגים באופן דומה. בטבלה הבאה מפורטים ההבדלים הפונקציונליים בין תגי רשת לבין תגים במאגרי צמתים שהוקצו אוטומטית באשכולות רגילים:

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

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