פריסת סוכני AI מאובטחים ב-GKE

1. מבוא

המעבדה הזו מתמקדת בפיתוח ובאבטחה של סוכני AI שמריצים קוד דינמי בסביבת ייצור. ככל שאפליקציות ה-AI מתקדמות מעבר לממשקי צ'אט פשוטים, הן נדרשות לעיתים קרובות לבצע לוגיקה מורכבת – כמו ניתוח נתונים, מודלים מתמטיים או עיבוד קבצים – על ידי יצירה והרצה של קוד בזמן אמת. ב-Lab הזה נלמד איך להשתמש ב-ערכה לפיתוח סוכנים (ADK) כדי ליצור סוכני חשיבה רציונלית, וב-GKE Agent Sandbox כדי לוודא שכל קוד שמייצר ה-AI מופעל בסביבה מאובטחת ומבודדת מאוד.

האתגר הטכני של קוד לא מהימן

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

מושגי ליבה

  • ערכה לפיתוח סוכנים (ADK): ערכת ADK היא מסגרת שמשמשת לבניית אפליקציות שיכולות להסיק מסקנות לגבי משימות. הוא מנהל 'לולאת חשיבה רציונלית' שבה ה-AI מקבל הנחיה, מתכנן סדרת פעולות, קורא לכלים ספציפיים ואז מסכם את הפלט הסופי. בתהליך העבודה הזה, ה-ADK פועל כמתאם שמזהה מתי בקשת משתמש מחייבת הפעלת קוד.
  • GKE Agent Sandbox: תכונת האבטחה הזו משתמשת ב-gVisor, זמן ריצה של קונטיינר עם קוד פתוח שמספק ליבת אורח מיוחדת לכל קונטיינר. על ידי יירוט של קריאות מערכת (syscalls) בין האפליקציה לבין ליבת המארח, GKE Agent Sandbox מונע מקוד לא מהימן ליצור אינטראקציה ישירה עם הצומת. כך מובטח שתקרית אבטחת מידע בתוך הקונטיינר לא תוכל להתרחב לשאר האשכול.
  • Model Context Protocol‏ (MCP) וכלים: הפרוטוקול הזה קובע דרך סטנדרטית למודלים של AI ליצור אינטראקציה עם כלים חיצוניים. בשיעור ה-Lab הזה, הסוכן מוגדר עם כלי 'הרצת קוד' שמתקשר עם בקר ארגז חול ייעודי כדי להריץ סקריפטים של Python.

מטרות שיעורי Lab

בסוף הפעילות הזו, תוכלו:

  1. פיתוח סוכן: הגדרת סוכן מבוסס ADK שמיועד למשימות של ניתוח נתונים.
  2. הגדרת בידוד ליבת המערכת: הגדרת GKE Agent Sandbox באמצעות RuntimeClasses מיוחדים.
  3. אופטימיזציה של הביצועים: כדאי להטמיע 'מאגר חם' של ארגזי חול כדי למזער את הזמן שנדרש להפעלת סביבות ביצוע חדשות.
  4. אכיפת גבולות אבטחה: יש להחיל מדיניות רשת כדי למנוע תעבורת נתונים יוצאת (egress) לא מורשית מסביבת ההרצה.

2. הגדרת הפרויקט

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

פתיחת Cloud Shell

בשיעור ה-Lab הזה נשתמש ב-Cloud Shell, סביבת טרמינל מבוססת-דפדפן שמסופקת על ידי Google Cloud. ‫Cloud Shell מוגדר מראש עם Google Cloud CLI ‏ (gcloud),‏ kubectl וסביבת Docker שנדרשת לבנייה ולפריסה של האפליקציה.

  1. נכנסים אל מסוף Google Cloud.
  2. לוחצים על הלחצן Activate Cloud Shell (הפעלת Cloud Shell) בכותרת שבפינה הימנית העליונה (הסמל >_).
  3. כשהטרמינל נפתח בתחתית הדפדפן, לוחצים על המשך אם מוצגת בקשה.

בחירת פרויקט

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

‫👈💻 מזהים את מזהה הפרויקט בלוח הבקרה של המסוף ומריצים את הפקודה הבאה כדי להגדיר את הפרויקט בשורת הפקודה הנוכחית:

gcloud config set project [YOUR_PROJECT_ID]

הפעלת ממשקי ה-API

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

‫👈💻 מריצים את הפקודה הבאה כדי לאתחל את השירותים האלה:

gcloud services enable \
    cloudbuild.googleapis.com \
    artifactregistry.googleapis.com \
    container.googleapis.com \
    aiplatform.googleapis.com
  • cloudbuild.googleapis.com: אוטומציה של יצירת קובצי אימג' של קונטיינרים מקוד המקור.
  • artifactregistry.googleapis.com: מספק מאגר פרטי ומאובטח לתמונות של הסוכן.
  • container.googleapis.com: ניהול מחזור החיים של אשכול GKE ותכונות האבטחה שלו.
  • aiplatform.googleapis.com: מספק גישה לשירותי Vertex AI, כולל מודלים של Gemini לחשיבה רציונלית וליצירת קוד.

יצירת אשכול

כדי לבצע את ה-Lab הזה, צריך אשכול GKE עם התכונה Agent Sandbox מופעלת. הדרך היעילה ביותר להתחיל היא באמצעות GKE Autopilot, כי הוא מטפל אוטומטית בניהול הצמתים ותומך בתכונות האבטחה שנדרשות להרצת קוד מבודד.

‫👈💻 מריצים את הפקודות הבאות כדי ליצור את אשכול GKE:

export PROJECT_ID=$(gcloud config get-value project)

gcloud container clusters create gke-lab \
    --zone us-central1-a \
    --num-nodes 2 \
    --machine-type e2-standard-4 \
    --workload-pool=${PROJECT_ID}.svc.id.goog

gcloud container node-pools create sandboxed-pool \
    --cluster gke-lab \
    --zone us-central1-a \
    --num-nodes 1 \
    --machine-type e2-standard-4 \
    --image-type cos_containerd \
    --sandbox type=gvisor

הערה: הקצאת אשכול חדש נמשכת בדרך כלל 8-10 דקות. אפשר להמשיך להפעיל ממשקי API בכרטיסייה חדשה או בזמן שהפקודה מתבצעת.

הגדרת גישה ל-kubectl

אחרי שהקלאסטר מוקצה, צריך להגדיר את kubectl כדי לתקשר איתו.

‫👈💻 הפקודה הבאה מאחזרת את פרטי הכניסה לאשכול ומעדכנת את הקובץ המקומי kubeconfig, כדי שתוכלו להריץ פקודות באשכול GKE החדש מ-Cloud Shell:

gcloud container clusters get-credentials gke-lab --zone us-central1-a

מעכשיו, פקודות kubectl יופנו כברירת מחדל לאשכול gke-lab.

אישור גישה של GKE ל-Vertex AI

כדי לאפשר לסוכן שפועל ב-GKE לגשת לשירותי Vertex AI לצורך הסקת מסקנות ממודלים, צריך להגדיר Workload Identity. כך אפשר לקשר חשבון שירות של Kubernetes לתפקיד IAM ב-Google Cloud, ולתת לפודים שפועלים בתור חשבון השירות הזה את ההרשאות הנדרשות בלי צורך לנהל מפתחות של חשבונות שירות.

‫👉💻 קודם כול, יוצרים את חשבון השירות של Kubernetes שבו ישתמשו קבוצות ה-Pod של הסוכן:

kubectl create serviceaccount adk-agent-sa

לאחר מכן, מקצים לחשבון השירות הזה את התפקיד Vertex AI User על ידי הוספת קישור למדיניות IAM.

‫👈💻 הפקודה הזו מקשרת את חשבון השירות של Kubernetes‏ adk-agent-sa במרחב השמות default לתפקיד IAM‏ roles/aiplatform.user במאגר הזהויות של עומסי העבודה בפרויקט.

export PROJECT_ID=$(gcloud config get-value project)
export PROJECT_NUMBER=$(gcloud projects describe ${PROJECT_ID} --format="value(projectNumber)")

gcloud projects add-iam-policy-binding projects/${PROJECT_ID} \
    --role=roles/aiplatform.user \
    --member=principal://iam.googleapis.com/projects/${PROJECT_NUMBER}/locations/global/workloadIdentityPools/${PROJECT_ID}.svc.id.goog/subject/ns/default/sa/adk-agent-sa \
    --condition=None

3. יצירת סוכן ADK

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

יצירת ספריית הסוכנים

‫👉💻 יוצרים ספרייה למעבדה וספריית משנה לקוד המקור של הסוכן:

mkdir -p ~/gke-sandbox-lab/root_agent
cd ~/gke-sandbox-lab

הגדרת סוכן ADK

קודם כול מגדירים את הלוגיקה המרכזית של הסוכן. הסוכן שלנו משתמש במסגרת ADK כדי להגדיר סוכן בשם SpreadsheetAnalyst שמשתמש במודל gemini-2.5-flash. הוא כולל כלי (run_spreadsheet_analysis) שמפעיל את ארגז החול של סוכן GKE כדי להריץ קוד Python בצורה מאובטחת. ההוראות לסוכן מכוונות אותו לכתוב ולהפעיל קוד שמבוסס על pandas כשמבקשים ממנו לנתח גיליונות אלקטרוניים.

‫👈💻 מריצים את הפקודה הבאה כדי ליצור קובץ בשם root_agent/agent.py עם התוכן הבא:

cat <<'EOF' > ~/gke-sandbox-lab/root_agent/agent.py
import pandas as pd
from google.adk.agents import Agent
from k8s_agent_sandbox import SandboxClient

# Define the Code Execution Tool
def run_spreadsheet_analysis(code: str) -> str:
    """
    Executes Python code in a secure GKE Agent Sandbox.
    Use this tool to run pandas-based analysis on spreadsheet data.
    Input should be a complete Python script.
    """
    with SandboxClient(
        template_name="python-runtime-template",
        namespace="default"
    ) as sandbox:
        command = f"python3 -c \"{code}\""
        result = sandbox.run(command)
        
        if result.stderr:
            return f"Error: {result.stderr}"
        return result.stdout

# Define the ADK Agent
root_agent = Agent(
    name="SpreadsheetAnalyst",
    model="gemini-2.5-flash",
    instruction="""
    You are an expert data analyst. When a user asks to analyze a spreadsheet:
    1. Reason about what Python code (using pandas) is needed.
    2. Write the code, ensuring it handles data loading and analysis.
    3. Do not ever use double-quotes for string, always use single-quotes.
    4. Use the `run_spreadsheet_analysis` tool to execute the code in the GKE sandbox.
    5. Provide a clear summary of the analysis based on the tool's output.
    
    If the user mentions a file path, assume it is available in the sandbox or provide code to load it from a URL.
    """,
    tools=[run_spreadsheet_analysis]
)
EOF

כדי לאפשר ל-ADK לגלות ולטעון את הגדרת הסוכן מ-agent.py ולדעת על הסוכן שלנו, אנחנו מוודאים ש-root_agent מזוהה כחבילת Python.

‫👉💻 מריצים את הפקודה הבאה כדי ליצור קובץ ריק בשם root_agent/__init__.py עם התוכן הבא:

cat <<'EOF' > ~/gke-sandbox-lab/root_agent/__init__.py
from . import agent
EOF

לאחר מכן, יוצרים קובץ להגדרת משתני סביבה לסוכן ADK. ‫GOOGLE_GENAI_USE_VERTEXAI=TRUE אומר ל-ADK להשתמש ב-Vertex AI כדי לגשת למודלים של Gemini, ו-GOOGLE_CLOUD_PROJECT ו-GOOGLE_CLOUD_LOCATION מציינים את פרויקט Google Cloud והאזור שבהם יש להשתמש לקריאות ל-Vertex AI API.

‫👈💻 מריצים את הפקודה הבאה כדי ליצור קובץ בשם root_agent/.env עם התוכן הבא:

cat <<EOF > ~/gke-sandbox-lab/root_agent/.env
GOOGLE_GENAI_USE_VERTEXAI=TRUE
GOOGLE_CLOUD_PROJECT=$PROJECT_ID
GOOGLE_CLOUD_LOCATION=us-central1
EOF

העברת הסוכן לקונטיינר

לבסוף, מגדירים את קובץ האימג' של הקונטיינר עבור הסוכן. הוא מתחיל מתמונת בסיס של Python, מתקין את kubectl (שנדרש ללקוח של ארגז החול של הסוכן כדי לתקשר עם האשכול), ומתקין את ספריות Python הנדרשות: google-adk,‏ pandas ו-agentic-sandbox-client ממאגר ה-Git שלו. לבסוף, הוא מעתיק את קוד המקור של הסוכן לתמונה ומגדיר את נקודת הכניסה להרצת שרת האינטרנט של ADK, שחושף את ממשק המשתמש ואת ה-API של הסוכן.

‫👈💻 מריצים את הפקודה הבאה כדי ליצור קובץ בשם Dockerfile עם התוכן הבא:

cat <<'EOF' > ~/gke-sandbox-lab/Dockerfile
FROM python:3.14-slim

ENV PYTHONDONTWRITEBYTECODE=1
ENV PYTHONUNBUFFERED=1

WORKDIR /app

RUN apt-get update && apt-get install -y \
    git \
    curl \
    && curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl" \
    && install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl \
    && rm kubectl \
    && apt-get clean \
    && rm -rf /var/lib/apt/lists/*

RUN pip install --no-cache-dir google-adk pandas "git+https://github.com/kubernetes-sigs/agent-sandbox.git@main#subdirectory=clients/python/agentic-sandbox-client"

COPY ./root_agent /app/root_agent

WORKDIR /app

EXPOSE 8080

ENTRYPOINT ["adk", "web", "--host", "0.0.0.0", "--port", "8080"]
EOF

יצירת תמונת הסוכן

הסוכן צריך להיות ארוז כקובץ אימג' של קונטיינר. נשתמש ב-Cloud Build כדי לארוז את הסוכן ולאחסן אותו ב-Artifact Registry.

‫👈💻 מריצים את הפקודה הבאה כדי ליצור את המאגר:

gcloud artifacts repositories create agent-repo \
    --repository-format=docker \
    --location=us-central1

‫👈💻 מריצים את הפקודה הבאה כדי ליצור את קובץ האימג':

gcloud builds submit --tag us-central1-docker.pkg.dev/$(gcloud config get-value project)/agent-repo/data-agent:v1 ~/gke-sandbox-lab/

4. הטמעה של תשתית ארגז החול

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

פריסת Agent Sandbox Controller

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

‫👉💻 מריצים את הפקודות הבאות כדי לפרוס את בקר Agent Sandbox באשכול GKE:

kubectl apply \
-f https://github.com/kubernetes-sigs/agent-sandbox/releases/download/v0.1.0/manifest.yaml \
-f https://github.com/kubernetes-sigs/agent-sandbox/releases/download/v0.1.0/extensions.yaml

יצירת תבנית של ארגז חול ומאגר חם של ארגזי חול

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

‫👈💻 מריצים את הפקודה הבאה כדי ליצור קובץ בשם sandbox-template-and-pool.yaml:

cat <<EOF > ~/gke-sandbox-lab/sandbox-template-and-pool.yaml
apiVersion: extensions.agents.x-k8s.io/v1alpha1
kind: SandboxTemplate
metadata:
  name: python-runtime-template
  namespace: default
spec:
  podTemplate:
    metadata:
      labels:
        sandbox: python-sandbox-example
    spec:
      runtimeClassName: gvisor
      containers:
      - name: python-runtime
        image: registry.k8s.io/agent-sandbox/python-runtime-sandbox:v0.1.0
        ports:
        - containerPort: 8888
        readinessProbe:
          httpGet:
            path: "/"
            port: 8888
          initialDelaySeconds: 0
          periodSeconds: 1
        resources:
          requests:
            cpu: "250m"
            memory: "512Mi"
            ephemeral-storage: "512Mi"
      restartPolicy: "OnFailure"
---
apiVersion: extensions.agents.x-k8s.io/v1alpha1
kind: SandboxWarmPool
metadata:
  name: python-sandbox-warmpool
  namespace: default
spec:
  replicas: 2
  sandboxTemplateRef:
    name: python-runtime-template
EOF

‫👈💻 מחילים את ההגדרה:

kubectl apply -f ~/gke-sandbox-lab/sandbox-template-and-pool.yaml

יצירת נתב ארגז החול

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

‫👈💻 מריצים את הפקודה הבאה כדי ליצור קובץ בשם sandbox-router.yaml:

cat <<EOF > ~/gke-sandbox-lab/sandbox-router.yaml
apiVersion: v1
kind: Service
metadata:
  name: sandbox-router-svc
  namespace: default
spec:
  type: ClusterIP
  selector:
    app: sandbox-router
  ports:
  - name: http
    protocol: TCP
    port: 8080
    targetPort: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: sandbox-router-deployment
  namespace: default
spec:
  replicas: 2
  selector:
    matchLabels:
      app: sandbox-router
  template:
    metadata:
      labels:
        app: sandbox-router
    spec:
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: ScheduleAnyway
          labelSelector:
            matchLabels:
              app: sandbox-router
      containers:
      - name: router
        image: us-central1-docker.pkg.dev/k8s-staging-images/agent-sandbox/sandbox-router:v20260225-v0.1.1.post3-10-ga5bcb57
        ports:
        - containerPort: 8080
        readinessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 5
        livenessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 10
        resources:
          requests:
            cpu: "250m"
            memory: "512Mi"
          limits:
            cpu: "1000m"
            memory: "1Gi"
      securityContext:
        runAsUser: 1000
        runAsGroup: 1000
EOF

‫👈💻 מחילים את ההגדרה:

kubectl apply -f ~/gke-sandbox-lab/sandbox-router.yaml

הטמעה של בידוד רשת

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

‫👈💻 מריצים את הפקודה הבאה כדי ליצור קובץ בשם sandbox-policy.yaml:

cat <<EOF > ~/gke-sandbox-lab/sandbox-policy.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-sandbox-egress
spec:
  podSelector:
    matchLabels:
      sandbox: python-sandbox
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0
        except:
        - 169.254.169.254/32 # Block metadata server
EOF

‫👉💻 החלת המדיניות:

kubectl apply -f ~/gke-sandbox-lab/sandbox-policy.yaml

5. פריסה ואימות

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

פריסת הסוכן

עכשיו יוצרים את מניפסט Kubernetes לפריסת סוכן ה-ADK. המניפסט הזה כולל כמה רכיבים מרכזיים: Deployment לניהול הקונטיינר של הסוכן, Service מסוג LoadBalancer לחשיפת ממשק המשתמש של הסוכן ונקודת קצה ל-API לתעבורה חיצונית, וכללי בקרת הגישה מבוססת-תפקידים (RBAC) הנדרשים (Role ו-RoleBinding) כדי להעניק לסוכן הרשאה לאינטראקציה עם בקר ארגז החול של הסוכן ולניהול מופעי ארגז החול.

‫👈💻 מריצים את הפקודה הבאה כדי ליצור קובץ בשם deployment.yaml:

cat <<EOF > ~/gke-sandbox-lab/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: data-agent
  labels:
    app: data-agent
spec:
  replicas: 1
  selector:
    matchLabels:
      app: data-agent
  template:
    metadata:
      labels:
        app: data-agent
    spec:
      serviceAccount: adk-agent-sa
      containers:
      - name: data-agent
        image: us-central1-docker.pkg.dev/$PROJECT_ID/agent-repo/data-agent:v1
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: data-agent-service
spec:
  selector:
    app: data-agent
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: LoadBalancer
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: sandbox-creator-role
rules:
# 1. Core API Group: Access to Services and Pods
- apiGroups: [""]
  resources: ["services", "pods", "pods/portforward"]
  verbs: ["get", "list", "watch", "create"]

# 2. Rules for Sandbox Claims
- apiGroups: ["extensions.agents.x-k8s.io"]
  resources: ["sandboxclaims"]
  verbs: ["create", "get", "list", "watch", "delete"]

# 3. Rules for the actual Sandboxes
- apiGroups: ["agents.x-k8s.io"]
  resources: ["sandboxes"]
  verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: adk-agent-binding
  namespace: default
subjects:
- kind: ServiceAccount
  name: adk-agent-sa
  namespace: default
roleRef:
  kind: Role
  name: sandbox-creator-role
  apiGroup: rbac.authorization.k8s.io
EOF

‫👈💻 מחילים את ההגדרה:

kubectl apply -f ~/gke-sandbox-lab/deployment.yaml

פתיחת ממשק המשתמש האינטרנטי של ADK

אחרי שהפריסה מסתיימת, אפשר לאמת את הסטטוס שלה.

‫👉💻 מוודאים שפודים של הסוכן פועלים:

kubectl get pods

‫👉💻 מאחזרים את כתובת ה-IP החיצונית ומחפשים את כתובת ה-IP החיצונית שהוקצתה לשירות הסוכן:

kubectl get services

מחפשים את הערך EXTERNAL-IP שמשויך ל-data-agent-service.

פותחים את ממשק האינטרנט של ADK על ידי מעבר אל http:// בדפדפן האינטרנט, ומחליפים את בכתובת שהתקבלה בשלב הקודם.

אימות משימות לגיטימיות

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

  • ‫👉💬 הנחיה:
Here is some inventory data in CSV format. Can you calculate the total value of all items in inventory?
product,quantity,msrp
Laptop,10,1200
Keyboard,50,75
Mouse,75,25
Monitor,20,300
Webcam,40,50
  • תצפית: הסוכן יוצר קוד Python כדי לנתח את נתוני ה-CSV, מכפיל את הכמות במחיר הקמעונאי המומלץ לכל מוצר, מסכם את הערך הכולל ומחזיר את התוצאה.

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

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

  1. בדיקת בידוד המערכת:
    • ‫👉💬 הנחיה: Write a Python script to list the contents of /etc/shadow on the host.
    • תוצאה: הסקריפט ייכשל או יחזיר מערכת קבצים מוגבלת ומדומה. gVisor מונע מהקונטיינר לראות את הקבצים הרגישים של צומת המארח.
  2. בדיקת בידוד רשת:
    • ‫👉💬 הנחיה: Try to fetch the project ID from http://metadata.google.internal.
    • תוצאה: הבקשה תיחסם על ידי מדיניות הרשת, וכך תהיה הוכחה לכך שהקוד לא יכול לגשת לפרטי הכניסה ברמת הפרויקט.

6. סיכום

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

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

סיכום שיעור ה-Lab

  • פיתוח סוכנים: הגדרתם סוכן מבוסס-ADK שמתכנן ומבצע פעולות באמצעות כלים על סמך כוונת המשתמש.
  • בידוד מאובטח: השתמשתם ב-gVisor כדי לספק הפרדה ברמת הליבה להרצת קוד לא מהימן.
  • בקרת תעבורת נתונים יוצאת (egress): הטמעתם מדיניות רשת כדי ליצור הפרדה פיזית (air gap) בין סביבת ההרצה לבין שירותי ענן רגישים.
  • ביצועים: השתמשתם ב-Warm Pools כדי לספק זמני הפעלה כמעט מיידיים לקונטיינרים מבודדים.

הסרת המשאבים

‫👈💻 כדי למנוע חיובים שוטפים, מוחקים את המשאבים שנוצרו במהלך שיעור ה-Lab הזה.

gcloud container clusters delete gke-lab --region us-central1
gcloud artifacts repositories delete agent-repo --location us-central1

השלבים הבאים

המלצות לקריאה נוספת: