חיזוק הבידוד של עומסי עבודה באמצעות GKE Sandbox

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

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

לפני שקוראים את הדף הזה, חשוב להכיר את הסקירה הכללית על GKE Sandbox.

הפעלת GKE Sandbox

אפשר להשתמש ב-GKE Sandbox באשכולות Autopilot שמריצים GKE בגרסה 1.27.4-gke.800 ואילך. כדי להתחיל לפרוס עומסי עבודה של Autopilot בסביבת Sandbox, אפשר לדלג אל עבודה עם GKE Sandbox.

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

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

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

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

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

הפעלת GKE Sandbox באשכול Standard חדש

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

gcloud container node-pools create NODE_POOL_NAME \
  --cluster=CLUSTER_NAME \
  --node-version=NODE_VERSION \
  --machine-type=MACHINE_TYPE \
  --image-type=cos_containerd \
  --sandbox type=gvisor

gcloud container node-pools create NODE_POOL_NAME \
  --cluster=CLUSTER_NAME \
  --node-version=NODE_VERSION \
  --machine-type=MACHINE_TYPE \
  --accelerator=type=GPU_TYPE,gpu-driver-version=DRIVER_VERSION \
  --image-type=cos_containerd \
  --sandbox type=gvisor

gcloud container node-pools create NODE_POOL_NAME \
  --cluster=CLUSTER_NAME \
  --node-version=NODE_VERSION \
  --num-nodes=NUM_NODES \
  --tpu-topology=TPU_TOPOLOGY \
  --machine-type=MACHINE_TYPE \
  --image-type=cos_containerd \
  --sandbox type=gvisor

הפעלת GKE Sandbox באשכול Standard קיים

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

gcloud container node-pools create NODE_POOL_NAME \
  --cluster=CLUSTER_NAME \
  --machine-type=MACHINE_TYPE \
  --image-type=cos_containerd \
  --sandbox type=gvisor

gcloud container node-pools create NODE_POOL_NAME \
  --cluster=CLUSTER_NAME \
  --node-version=NODE_VERSION \
  --machine-type=MACHINE_TYPE \
  --accelerator=type=GPU_TYPE,gpu-driver-version=DRIVER_VERSION \
  --image-type=cos_containerd \
  --sandbox type=gvisor

gcloud container node-pools create NODE_POOL_NAME \
  --cluster=CLUSTER_NAME \
  --node-version=NODE_VERSION \
  --num-nodes=NUM_NODES \
  --tpu-topology=TPU_TOPOLOGY \
  --machine-type=MACHINE_TYPE \
  --image-type=cos_containerd \
  --sandbox type=gvisor

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

מומלץ להפעיל את Cloud Logging ואת Cloud Monitoring באשכול, כדי שההודעות של gVisor יירשמו ביומן. השירותים האלה מופעלים כברירת מחדל באשכולות חדשים.

אתם יכולים להשתמש במסוף Cloud de Confiance כדי להפעיל את התכונות האלה באשכול קיים.

1. נכנסים לדף Google Kubernetes Engine במסוף Cloud de Confiance .

   מעבר אל Google Kubernetes Engine

2. לוחצים על השם של האשכול שרוצים לשנות.

3. בקטע Features (מאפיינים), בשדה Cloud Logging (רישום ביומן ב-Cloud), לוחצים על edit ואז על Edit Cloud Logging (עריכת רישום ביומן ב-Cloud).

4. מסמנים את תיבת הסימון Enable Cloud Logging (הפעלת Cloud Logging).

5. לוחצים על שמירת השינויים.

6. חוזרים על אותם השלבים בשדות Cloud Monitoring וManaged Service for Prometheus כדי להפעיל את התכונות האלה.

שימוש ב-GKE Sandbox במצבי Autopilot ו-Standard

באשכולות Autopilot ובאשכולות Standard שבהם מופעל GKE Sandbox, כדי לבקש סביבת ארגז חול עבור Pod, צריך לציין את gvisor RuntimeClass במפרט של ה-Pod.

במקרים של אשכולות Autopilot, צריך לוודא שפועלת גרסת GKE‏ 1.27.4-gke.800 ואילך.

הפעלת אפליקציה בארגז חול

כדי להפעיל פריסה בצומת עם GKE Sandbox מופעל, מגדירים את הערך של spec.template.spec.runtimeClassName ל-gvisor, כמו בדוגמה הבאה:

# httpd.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: httpd
  labels:
    app: httpd
spec:
  replicas: 1
  selector:
    matchLabels:
      app: httpd
  template:
    metadata:
      labels:
        app: httpd
    spec:
      runtimeClassName: gvisor
      containers:
      - name: httpd
        image: httpd

יוצרים את הפריסה:

kubectl apply -f httpd.yaml

ה-Pod נפרס לצומת עם GKE Sandbox מופעל. כדי לאמת את הפריסה, מאתרים את הצומת שבו ה-Pod נפרס:

kubectl get pods

הפלט אמור להיראות כך:

NAME                    READY   STATUS    RESTARTS   AGE
httpd-db5899bc9-dk7lk   1/1     Running   0          24s

בפלט, מחפשים את שם ה-Pod בפלט ואז בודקים את הערך של RuntimeClass:

kubectl get pods POD_NAME -o jsonpath='{.spec.runtimeClassName}'

הפלט הוא gvisor.

אפשר גם להציג את RuntimeClass של כל Pod ולחפש את ה-Pods שבהם הוא מוגדר ל-gvisor:

kubectl get pods -o jsonpath=$'{range .items[*]}{.metadata.name}: {.spec.runtimeClassName}\n{end}'

הפלט שיתקבל:

POD_NAME: gvisor

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

הפעלת Pod עם מאיצים ב-GKE Sandbox

כדי להריץ עומס עבודה של GPU או TPU ב-GKE Sandbox, מוסיפים את השדה runtimeClassName: gvisor למניפסט כמו בדוגמאות הבאות:

• קובץ מניפסט לדוגמה של GPU Pods במצב רגיל:

  apiVersion: v1
  kind: Pod
  metadata:
    name: my-gpu-pod
  spec:
    runtimeClassName: gvisor
    containers:
    - name: my-gpu-container
      image: nvidia/samples:vectoradd-cuda10.2
      resources:
        limits:
          nvidia.com/gpu: 1
  

• דוגמה למניפסט של Pods של GPU במצב Autopilot:

  apiVersion: v1
  kind: Pod
  metadata:
    name: my-gpu-pod
  spec:
    runtimeClassName: gvisor
    nodeSelector:
      cloud.google.com/gke-gpu-driver-version: "latest"
      cloud.google.com/gke-accelerator: nvidia-tesla-t4
    containers:
    - name: my-gpu-container
      image: nvidia/samples:vectoradd-cuda10.2
      resources:
        limits:
          nvidia.com/gpu: 1
  

• דוגמה לקובץ מניפסט עבור TPU Pods במצב רגיל או במצב טייס אוטומטי:

  apiVersion: v1
  kind: Pod
  metadata:
    name: my-tpu-pod
  spec:
    runtimeClassName: gvisor
    nodeSelector:
      cloud.google.com/gke-tpu-accelerator: tpu-v5-lite-podslice
      cloud.google.com/gke-tpu-topology: 1x1
    containers:
    - name: my-tpu-container
      image: us-docker.pkg.dev/cloud-tpu-images/jax-ai-image/tpu:latest
      command:
        - bash
        - -c
        - |
          python -c 'import jax; print("TPU cores:", jax.device_count())'
      resources:
        limits:
          google.com/tpu: 1
        requests:
          google.com/tpu: 1
  

אפשר להריץ ב-GKE Sandbox כל Pod של מאיץ במצב Autopilot או Standard שעומד בדרישות לגבי הגרסה וסוג המאיץ, על ידי הוספת השדה runtimeClassName: gvisor למניפסט. כדי להפעיל GPU Pods ב-GKE, אפשר לעיין במאמרים הבאים:

• פריסת עומסי עבודה של GPU ב-Autopilot
• הפעלת יחידות GPU במאגרי צמתים של GKE Standard

כדי להריץ TPU Pods ב-GKE, אפשר לעיין במאמרים הבאים:

• פריסת עומסי עבודה של TPU ב-Autopilot
• הרצת TPU במאגרי צמתים רגילים ב-GKE

אלה סוגי ה-GPU שנתמכים ב-Autopilot:

• ‫nvidia-gb200: NVIDIA GB200 NVL72 (תצוגה מקדימה)
• ‫nvidia-b200: NVIDIA B200 (180GB) (תצוגה מקדימה)
• ‫nvidia-h200-141gb: NVIDIA H200 (141GB) (תצוגה מקדימה)
• ‫nvidia-h100-mega-80gb: NVIDIA H100 Mega (80GB)
• ‫nvidia-h100-80gb: NVIDIA H100 (80GB)
• ‫nvidia-a100-80gb: NVIDIA A100 (80GB)
• ‫nvidia-tesla-a100: NVIDIA A100 (40GB)
• ‫nvidia-rtx-pro-6000: NVIDIA RTX PRO 6000 (תצוגה מקדימה) (למעט סוגי מכונות G4 עם פחות מ-GPU אחד)
• ‫nvidia-l4: NVIDIA L4
• ‫nvidia-tesla-t4: NVIDIA T4

הפעלת Pod רגיל לצד Pods בארגז חול

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

אחרי שמפעילים את GKE Sandbox במאגר צמתים, אפשר להריץ צמתים מהימנים בלי להשתמש בארגז חול, באמצעות taints ו-tolerations של צמתים. ה-Pods האלה נקראים 'Pods רגילים' כדי להבדיל אותם מ-Pods בסביבת ארגז חול.

ל-Pods רגילים, בדיוק כמו ל-Pods עם ארגז חול, אין גישה לCloud de Confiance שירותים אחרים או למטא-נתונים של האשכול. המניעה הזו היא חלק מההגדרה של הצומת. אם קבוצות ה-Pod הרגילות או קבוצות ה-Pod בסביבת ארגז חול צריכות גישה לשירותים שלCloud de Confiance , צריך להשתמש ב-Workload Identity Federation for GKE.

‫GKE Sandbox מוסיף את התווית והכתם הבאים לצמתים שיכולים להריץ Pods ב-Sandbox:

labels:
  sandbox.gke.io/runtime: gvisor

taints:
- effect: NoSchedule
  key: sandbox.gke.io/runtime
  value: gvisor

בנוסף להגדרות של זיקה לצומת וסובלנות במניפסט של ה-Pod,‏ GKE Sandbox מחיל את ההגדרות הבאות של זיקה לצומת וסובלנות על כל ה-Pods עם RuntimeClass שמוגדר ל-gvisor:

affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: sandbox.gke.io/runtime
          operator: In
          values:
          - gvisor

tolerations:
  - effect: NoSchedule
    key: sandbox.gke.io/runtime
    operator: Equal
    value: gvisor

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

• אם ה-Pod שלכם יכול לפעול בצמתים עם GKE Sandbox מופעל, מוסיפים את ה-toleration.
• אם ה-Pod שלכם חייב לפעול בצמתים שבהם מופעל GKE Sandbox, צריך להוסיף גם את ההגדרה node affinity וגם את ההגדרה toleration.

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

# httpd-no-sandbox.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: httpd-no-sandbox
  labels:
    app: httpd
spec:
  replicas: 1
  selector:
    matchLabels:
      app: httpd
  template:
    metadata:
      labels:
        app: httpd
    spec:
      containers:
      - name: httpd
        image: httpd
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: sandbox.gke.io/runtime
                operator: In
                values:
                - gvisor
      tolerations:
        - effect: NoSchedule
          key: sandbox.gke.io/runtime
          operator: Equal
          value: gvisor

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

kubectl get pods -o jsonpath=$'{range .items[*]}{.metadata.name}: {.spec.runtimeClassName}\n{end}'

הפלט אמור להיראות כך:

httpd-db5899bc9-dk7lk: gvisor
httpd-no-sandbox-5bf87996c6-cfmmd:

פריסת httpd שנוצרה קודם פועלת בסביבת sandbox, כי runtimeClass שלה הוא gvisor. לפריסת httpd-no-sandbox אין ערך ל-runtimeClass, ולכן היא לא פועלת בסביבת ארגז חול.

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

kubectl get pod -o jsonpath=$'{range .items[*]}{.metadata.name}: {.spec.nodeName}\n{end}'

השם של מאגר הצמתים מוטמע בערך של nodeName. מוודאים ש-Pod פועל בצומת במאגר צמתים עם GKE Sandbox מופעל.

אימות של הגנה על מטא-נתונים

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

1. יוצרים פריסה בסביבת ארגז חול מהמניפסט הבא באמצעות kubectl apply -f. הוא משתמש בתמונה fedora, שכוללת את הפקודה curl. ה-Pod מריץ את הפקודה /bin/sleep כדי לוודא שהפריסה תפעל למשך 10,000 שניות.

   # sandbox-metadata-test.yaml
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: fedora
     labels:
       app: fedora
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: fedora
     template:
       metadata:
         labels:
           app: fedora
       spec:
         runtimeClassName: gvisor
         containers:
         - name: fedora
           image: fedora
           command: ["/bin/sleep","10000"]
   

2. כדי לקבל את שם ה-Pod, משתמשים בפקודה kubectl get pods, ואז משתמשים בפקודה kubectl exec כדי להתחבר ל-Pod באופן אינטראקטיבי.

   kubectl exec -it POD_NAME /bin/sh
   

   אתם מחוברים למאגר שפועל ב-Pod, בסשן /bin/sh.

3. בסשן האינטראקטיבי, מנסים לגשת לכתובת URL שמחזירה מטא-נתונים של האשכול:

   curl -s "http://169.254.169.254/computeMetadata/v1/instance/attributes/kube-env" -H "Metadata-Flavor: Google"
   

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

4. מקישים על Ctrl+C כדי להפסיק את הפקודה curl, ומקלידים exit כדי להתנתק מה-Pod.

5. מסירים את השורה RuntimeClass ממניפסט ה-YAML ומבצעים פריסה מחדש של ה-Pod באמצעות kubectl apply -f FILENAME. ה-Pod ב-Sandbox מופסק ונוצר מחדש בצומת ללא GKE Sandbox.

6. מקבלים את השם החדש של ה-Pod, מתחברים אליו באמצעות kubectl exec ומריצים שוב את הפקודה curl. הפעם, התוצאות מוחזרות. הפלט של הדוגמה הזו קוצר.

   ALLOCATE_NODE_CIDRS: "true"
   API_SERVER_TEST_LOG_LEVEL: --v=3
   AUTOSCALER_ENV_VARS: kube_reserved=cpu=60m,memory=960Mi,ephemeral-storage=41Gi;...
   ...
   

   מקלידים exit כדי להתנתק מה-Pod.

7. מסירים את הפריסה:

   kubectl delete deployment fedora
   

השבתת GKE Sandbox

אי אפשר להשבית את GKE Sandbox באשכולות GKE Autopilot או במאגרי צמתים של GKE Standard. אם רוצים להפסיק להשתמש ב-GKE Sandbox, צריך למחוק את מאגר הצמתים.

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

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