יצירת רשימות היתרים לעומסי עבודה עם הרשאות מיוחדות ב-Autopilot

במאמר הזה מוסבר איך ליצור רשימות היתרים שמאפשרות לפרוס עומסי עבודה עם הרשאות מיוחדות בצמתי Autopilot. אתם מאחסנים את רשימות ההיתרים האלה בקטגוריות של Cloud Storage. המסמך הזה מיועד לאדמינים ולמפעילים של פלטפורמות שרוצים להחריג עומסי עבודה ספציפיים שבבעלות הלקוח מאילוצי האבטחה שמוגדרים כברירת מחדל ב-Autopilot עבור עומסי עבודה ספציפיים של Kubernetes. כדאי שתכירו את השליטה בהוספת עומסי עבודה עם הרשאות מיוחדות ב-Autopilot.

מידע על עומסי עבודה עם הרשאות ב-Autopilot

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

לקוחות GKE שעומדים בדרישות יכולים ליצור ולנהל רשימות היתרים לעומסי עבודה עם הרשאות מיוחדות שלא תואמים למגבלות ברירת המחדל של Autopilot. רשימות ההיתרים האלה הן משאבים מותאמים אישית של Kubernetes מסוג WorkloadAllowlist שמוגדרים בקובצי YAML ומאוחסנים בקטגוריות של Cloud Storage. אדמינים של זהויות וחשבונות משתמשים במדיניות ארגונית כדי לאפשר לכם להגדיר את האשכולות כך שיזהו את רשימות ההיתרים ואת מאגרי הנתונים (buckets) שמנוהלים על ידי הלקוח. אדמינים של אשכולות יכולים להתקין את רשימות ההיתרים האלה כדי שעומסי העבודה עם הרשאות מיוחדות יוכלו לפעול במצב Autopilot.

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

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

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

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

• מפעילים את Cloud Storage API.

  תפקידים שנדרשים להפעלת ממשקי API

  כדי להפעיל ממשקי API, צריך את תפקיד ה-IAM 'אדמין של שימוש בשירות' (roles/serviceusage.serviceUsageAdmin), שכולל את ההרשאה serviceusage.services.enable. איך מקצים תפקידים

  להפעלת ה-API

• מוודאים שיש לכם אשכול GKE שפועלת בו גרסה 1.35 ואילך. אפשר גם ליצור אשכול Autopilot למשימה הזו.
• מוודאים שיש לכם קטגוריה ב-Cloud Storage שבה תוכלו לאחסן קבצים של רשימת ההיתרים. אפשר גם ליצור מאגר למשימה הזו.
• פותחים את מניפסט ה-YAML שמגדיר את עומס העבודה עם הרשאות מיוחדות שרוצים להריץ ב-Autopilot.

התפקידים הנדרשים

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

• שמירת רשימות ההיתרים בקטגוריה: משתמש באובייקטים באחסון (roles/storage.objectUser)
• נותנים גישה לסוכן השירות של GKE:‏ אדמין אחסון (roles/storage.admin)

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

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

יצירה והעלאה של WorkloadAllowlist

רשימות ההיתרים הן משאבים בהתאמה אישית מסוג WorkloadAllowlist שמוגדרים בקובצי YAML. השדות במפרט של WorkloadAllowlist דומים לשדות במפרט של Pod ב-Kubernetes. כשמתקינים רשימת היתרים באשכול ומפעילים עומס עבודה עם הרשאות, GKE מאמת את המפרט של עומס העבודה עם ההרשאות מול רשימת ההיתרים שהותקנה. עומס העבודה יכול לפעול רק אם כל השדות במפרט של הרשימה הלבנה תואמים לשדות המקבילים במפרט של עומס העבודה.

כדי ליצור רשימת היתרים חדשה של עומסי עבודה ולהעלות אותה לקטגוריה שלכם ב-Cloud Storage, פועלים לפי השלבים הבאים:

1. מזהים את עומס העבודה עם ההרשאות שרוצים להוסיף לרשימת ההיתרים.

2. מוסיפים את ההערה הבאה לשדה metadata.annotations במפרט של ה-Pod:

   cloud.google.com/generate-allowlist: "true"
   

   ל-Pods שמנוהלים על ידי בקר, כמו DaemonSet או Deployment, מוסיפים את ההערה לשדה spec.template.metadata.annotations.

3. מנסים ליצור את עומס העבודה עם הרשאות מיוחדות באשכול:

   kubectl apply -f WORKLOAD_FILE_PATH
   

   מחליפים את הערך ב-WORKLOAD_FILE_PATH בנתיב לקובץ המניפסט של עומס העבודה. ‫GKE דוחה את עומס העבודה עם הודעת שגיאה שכוללת מניפסט של WorkloadAllowlist. הפלט אמור להיראות כך:

   This workload can be enabled using the following Custom Resource. To be used in-cluster, the WorkloadAllowlist must be uploaded to Google Cloud Storage and then installed using an AllowlistSynchronizer. Refer to https://cloud.google.com/kubernetes-engine/docs/how-to/autopilot-privileged-allowlists.
   
   Note that many common partner workloads are already allowlisted. These can be installed directly using an AllowlistSynchronizer. Refer to https://cloud.google.com/kubernetes-engine/docs/resources/autopilot-partners.
   ---
   apiVersion: auto.gke.io/v1
   kind: WorkloadAllowlist
   metadata:
       name: test-pod-allowlist-2025-09-11t22-40-37
       annotations:
           autopilot.gke.io/no-connect: "true"
   exemptions:
       - autogke-disallow-privilege
   matchingCriteria:
       containers:
           - name: pause-container2
             image: k8s.gcr.io/pause2
             securityContext:
               privileged: true
   

4. בעורך טקסט, יוצרים קובץ YAML שמכיל את רשימת ההיתרים שנוצרה.

5. מגדירים את השדה metadata.name של רשימת ההיתרים.

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

   • שדות מסוימים תומכים בביטויים רגולריים, כמו matchingCriteria.containers[*].image ו-matchingCriteria.containers[*].args. משתמשים בביטוי רגולרי שתואם לכמה ערכים בעומסי עבודה שונים.

   • שדות ספציפיים, כמו matchingCriteria.containers ו-matchingCriteria.securityContext.capabilities.add, מתאימים לכל עומס עבודה עם קבוצת משנה של הערכים מ-WorkloadAllowlist. ברשימת ההיתרים של עומס העבודה, מציינים ערכים נוספים להתאמה לעומסי עבודה אחרים.

   מידע נוסף על כל השדות והערכים הנתמכים שאפשר להשתמש בהם מופיע במאמר בנושא WorkloadAllowlist CustomResourceDefinition.

7. מעלים את קובץ המניפסט לקטגוריה של Cloud Storage.

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

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

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

הגדרה לדוגמה של רשימת היתרים

השדה matchingCriteria במפרט של WorkloadAllowlist דומה במבנה שלו למפרט של Pod ב-Kubernetes. ‫WorkloadAllowlist CustomResourceDefinition הוא המקור המהימן לכל השדות, הערכים והביטויים שבהם אפשר להשתמש.

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

• הקונטיינר container-1 בעומס העבודה פועל במצב הרשאות.
• עומס העבודה מטמיע את הספרייה /var/log/ ממערכת הקבצים של הצומת במצב כתיבה.

1. בודקים את עומס העבודה לדוגמה:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: example-privileged-workload
     labels:
       env: dev
   spec:
     selector:
       matchLabels:
         env: dev
     template:
       metadata:
         labels:
           env: dev
       spec:
         containers:
         - name: container-1
           image: example-image-1
           resources:
             requests:
               cpu: "400m"
               memory: "4Gi"
           # Run the container in privileged mode
           securityContext:
             privileged: true
         - name: container-2
           image: example-image-2
           volumeMounts:
           - name: write-varlog
             mountPath: /logs
             readOnly: false
         # Mount a host directory
         volumes:
         - name: write-varlog
           hostPath:
             path: /var/log
             type: Directory
   

   כברירת מחדל, Autopilot דוחה את עומס העבודה הזה.

2. בודקים את הרשימה לדוגמה WorkloadAllowlist:

   apiVersion: auto.gke.io/v1
   kind: WorkloadAllowlist
   minGKEVersion: 1.32.0-gke.1000000
   metadata:
     name: example-privileged-workload
     annotations:
       autopilot.gke.io/no-connect: "true"
   # List of constraints that the allowlist modifies
   exemptions:
   - autogke-disallow-privilege
   - autogke-no-write-mode-hostpath
   matchingCriteria:
     containers:
     - name: container-1
       image: example-image-1
       securityContext:
         privileged: true
     - name: container-2
       image: example-image-2
       volumeMounts:
       - name: write-varlog
         mountPath: /logs
         readOnly: false
     volumes:
     - name: write-varlog
       hostPath:
         path: /var/log
   

   ל-WorkloadAllowlist הזה יש את המאפיינים הבאים:

   • הערכים בשדה exemptions מציינים את האילוצים של Autopilot שהרשימה הלבנה עוקפת.
   • הערכים בשדה matchingCriteria מציינים את הקונטיינרים שבהם נעשה שימוש בעומס העבודה לדוגמה ואת השדות שבדרך כלל חורגים מהמגבלות של Autopilot.

   ברשימת ההיתרים מופיעים רק הערכים של השדות שלא עומדים במגבלות. המערכת מתעלמת משדות אחרים בעומס העבודה, כמו השדה resources.requests.

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

הקצאת גישה לסוכן השירות של GKE

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

• צפייה בקטגוריות באחסון (roles/storage.bucketViewer)
• צפייה באובייקטים באחסון (roles/storage.objectViewer)

כדי להקצות את התפקידים האלה לסוכן השירות:

1. כדי למצוא את מספר הפרויקט של פרויקט האשכול:

   gcloud projects describe CLUSTER_PROJECT_ID \
       --format='value(projectNumber)'
   

2. הקצאת התפקיד roles/storage.bucketViewer:

   gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME \
       --member=serviceAccount:service-CLUSTER_PROJECT_NUMBER@container-engine-robot.s3ns-system.iam.gserviceaccount.com \
       --project=BUCKET_PROJECT_ID \
       --role=roles/storage.bucketViewer
   

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

   • ‫BUCKET_NAME: השם של קטגוריית Cloud Storage.
   • ‫CLUSTER_PROJECT_NUMBER: מספר הפרויקט של פרויקט האשכול, מתוך הפלט של השלב הקודם.
   • ‫BUCKET_PROJECT_ID: מזהה הפרויקט שמכיל את הדלי.

3. הקצאת התפקיד roles/storage.objectViewer:

   gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME \
       --member=serviceAccount:service-CLUSTER_PROJECT_NUMBER@container-engine-robot.s3ns-system.iam.gserviceaccount.com \
       --project=BUCKET_PROJECT_ID \
       --role=roles/storage.objectViewer
   

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

• הוספת נתיבים לרשימת ההיתרים למדיניות הארגון
• הגדרת אשכולות והוספה לרשימת ההיתרים