‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

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

Autopilot

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

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

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

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

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

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

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

מפעילים את ממשק ה-API של Google Kubernetes Engine.

הפעלת Google Kubernetes Engine API

כדי להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז לאתחל את ה-CLI של gcloud. אם התקנתם בעבר את ה-CLI של gcloud, מריצים את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שבגרסאות קודמות של ה-CLI של gcloud אי אפשר להריץ את הפקודות שבמסמך הזה.
הערה: אם כבר התקנתם את ה-CLI של gcloud, הקפידו להגדיר את compute/region המאפיין. אם אתם משתמשים בעיקר באשכולות אזוריים, צריך להגדיר את compute/zone במקום זאת. אם מגדירים מיקום ברירת מחדל, אפשר להימנע משגיאות ב-CLI של gcloud כמו השגיאה הבאה: One of [--zone, --region] must be supplied: Please specify location. יכול להיות שתצטרכו לציין את המיקום בפקודות מסוימות אם המיקום של האשכול שונה מברירת המחדל שהגדרתם.

מפעילים את Cloud Storage API, אם הוא עדיין לא מופעל.
התפקידים שנדרשים כדי להפעיל ממשקי API
כדי להפעיל ממשקי API, צריך את ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד 'בעלים' (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד 'אדמין בממשק 'שימוש בשירות'' (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים
להפעלת ה-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, פועלים לפי השלבים הבאים:

מזהים את עומס העבודה עם הרשאות היתר שרוצים להוסיף לרשימת ההיתרים.
מוסיפים את ההערה הבאה לשדה metadata.annotations במפרט של ה-Pod:
```
cloud.google.com/generate-allowlist: "true"
```
ב-Pods שמנוהלים על ידי בקר, כמו DaemonSet או Deployment, מוסיפים את ההערה לשדה spec.template.metadata.annotations.

הערה: כדי להשתמש בהערה הזו באשכול שנוצר לפני שהפרויקט או הארגון קיבלו גישה לתכונה, צריך קודם להפעיל פקודת gcloud container clusters update כלשהי עם הדגל --autopilot-privileged-admission. אם עדיין לא הגדרתם נתיבים מותאמים אישית לרשימת ההיתרים, אתם יכולים לשמור על התנהגות ברירת המחדל של GKE באמצעות הדגל --autopilot-privileged-admission=gke://*. מידע נוסף מופיע במאמר בנושא הפקודה gcloud container clusters update.

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

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://docs.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://docs.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

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

שיטה מומלצת:
כדאי להשתמש בסכימת ניהול גרסאות לקבצים של רשימת ההיתרים. קבצים עם גרסאות עוזרים לשמור על שמות קבצים ייחודיים בקטגוריה.
מגדירים את השדה metadata.name ברשימת ההיתרים.
שיטות מומלצות:
מגדירים את שם רשימת ההיתרים לאותו ערך כמו שם הקובץ. כך אפשר לוודא ששם רשימת ההיתרים הוא ייחודי בקטגוריה של Cloud Storage. ניסיון להתקין כמה רשימות היתרים עם אותו שם עלול להוביל להתנהגות לא צפויה.
אופציונלי: הופכים את רשימת ההיתרים של עומס העבודה לכללית יותר, כדי שתוכל להחריג עומסי עבודה דומים. אפשר להשתמש באחת מהשיטות הבאות:
- שדות מסוימים תומכים בביטויים רגולריים, כמו matchingCriteria.containers[*].image ו-matchingCriteria.containers[*].args. משתמשים בביטוי רגולרי שתואם לכמה ערכים בעומסי עבודה שונים.
- שדות ספציפיים, כמו matchingCriteria.containers ו-matchingCriteria.securityContext.capabilities.add, מתאימים לכל עומס עבודה עם קבוצת משנה של הערכים מ-WorkloadAllowlist. ב-WorkloadAllowlist, מציינים ערכים נוספים שיתאימו לעומסי עבודה אחרים.
למידע נוסף על כל השדות והערכים הנתמכים שאפשר להשתמש בהם, ראו WorkloadAllowlist CustomResourceDefinition.
מעלים את קובץ המניפסט לקטגוריה של Cloud Storage.

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

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

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

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

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

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

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

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

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 דוחה את עומס העבודה הזה.

בודקים את הרשימה לדוגמה 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)

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

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

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

מקצים את התפקיד roles/storage.bucketViewer:
```
gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME \
    --member=serviceAccount:service-CLUSTER_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com \
    --project=BUCKET_PROJECT_ID \
    --role=roles/storage.bucketViewer
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫BUCKET_NAME: שם הקטגוריה של Cloud Storage.
- ‫CLUSTER_PROJECT_NUMBER: מספר הפרויקט של פרויקט האשכול, מתוך הפלט של השלב הקודם.
- ‫BUCKET_PROJECT_ID: מזהה הפרויקט שמכיל את הדלי.

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

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