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

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

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

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

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

מידע על תגים

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

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

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

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

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

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

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

1. כדי ליצור תג:

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

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

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

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

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

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

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

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

• תגים למדיניות חומת אש ברשת נתמכים ב-GKE בגרסה 1.28 ואילך. אם אתם משתמשים בגרסת GKE מוקדמת יותר מ-1.28, אתם צריכים להשתמש במקום זאת בתגי רשת עם כללי חומת אש של VPC.
• בקטרי תקן, כל מאגר צמתים תומך בעד חמישה תגי חומת אש מצורפים.
• אפשר להשתמש בעד חמישה תגי חומת אש באשכולות Autopilot.
• סוגי מחשוב בהתאמה אישית תומכים בעד חמישה תגים.
• ‫GKE דוחה מפתחות תגים שמשתמשים בקידומת gke-managed.
• צריך ליצור את צמדי מפתח/ערך של התגים לפני שמצרפים אותם לאשכולות או למאגרי צמתים.

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

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

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

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

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

יצירת תגים

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

מפתחות התגים יכולים להיות parent או organizations/ORGANIZATION_IDprojects/PROJECT_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: מזהה הפרויקט ב- Cloud de Confiance
     • ‫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: מזהה הפרויקט ב- Cloud de Confiance

     הערך 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

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

tagKeys/KEY_ID=tagValues/VALUE_ID

ORGANIZATION_ID/TAG_KEY=TAG_VALUE

PROJECT_ID/TAG_KEY=TAG_VALUE

PROJECT_NUMBER/TAG_KEY=TAG_VALUE

תגי יעד עם מדיניות חומת אש

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

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

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

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

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

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

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

2. מקצים את התפקיד Tag Holds Administrator (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.s3ns-system.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.s3ns-system.iam.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.s3ns-system.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.s3ns-system.iam.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.s3ns-system.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. כשמצרפים תגים לאשכול שלם, מערכת GKE מתייחסת לתגים האלה כאילו הם הוגדרו ברמת האשכול.

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

כברירת מחדל, מערכת 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. מפעילים הקצאת משאבים אוטומטית של צמתים באשכול:

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

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

אפשר לצרף תגים למאגרי צמתים חדשים או קיימים, בלי קשר לשאלה אם הם משתמשים בהקצאה אוטומטית של צמתים. מערכת 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 מחיל את התגיות החדשות על כל מאגרי הצמתים החדשים באשכול, ושומר את התגיות שצורפו למאגרי צמתים קיימים.

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

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

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

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

כשפורסים עומס עבודה שמבקש צומת עם תווית ספציפית של מחלקת מחשוב בהתאמה אישית, 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: מזהה הפרויקט ב- Cloud de Confiance .
   • ‫TAG_KEY_1: השם של מפתח התג הראשון.
   • ‫TAG_VALUE_1: השם של ערך התג הראשון.
   • ‫ORGANIZATION_ID: מזהה הארגון המספרי ב- Cloud de Confiance .
   • ‫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 מחילה באופן אוטומטי כתם על הצמתים שנוצרו עבור הסוג הזה, ומוסיפה סבילות תואמת ל-Pods של עומס העבודה, כך שרק Pods שמבקשים במפורש את הסוג הזה יתזמנו בצמתים האלה.

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

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

מדיניות ההרשאה הבאה דוחה בקשות ליצירת Pod אם ה-Pod מכיל toleration לאחד מה-taints של Compute Class שמפורטים וגם לא נמצא במרחב שמות מורשה.

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 מסיר תגים קיימים ממאגר הצמתים הזה.

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

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

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

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

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

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

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

במאגרי צמתים רגילים שלא משתמשים ב-Node Auto Provisioning ובאשכולות Autopilot, תגי רשת ותגים מתנהגים באופן דומה. בטבלה הבאה מפורטים ההבדלים הפונקציונליים בין תגי רשת לבין תגים במאגרי צמתים שהוקצו אוטומטית באשכולות רגילים:

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

• שימוש בתגים לצורך מעקב אחר השימוש ואכיפה של מדיניות IAM
• מידע נוסף על תגים לחומות אש
• מידע נוסף על תגים