מידע על Agent Identity ל-GKE

עומסי עבודה של סוכנים דורשים לרוב אמצעי הגנה שונים, בקרת גישה ותהליכי אימות שונים מאלה של סוגים אחרים של עומסי עבודה. אפשר להשתמש בזהות הסוכן כדי להקצות לכל סוכן זהות מאומתת עם תוקף קצר לכל Pod. הזהות הזו עוזרת לכם לזהות את עומסי העבודה של הסוכן, לעקוב אחרי הפעולות של עומסי העבודה האלה ולנהל אותן ב- Google Cloud. במאמר הזה מוסבר איך Agent Identity פועל ב-Google Kubernetes Engine‏ (GKE), כולל איך לשלב אותו עםGoogle Cloud מוצרים אחרים, סוגי האימות שסוכנים יכולים להשתמש בהם ואיך לנהל את עומסי העבודה באמצעות הזהויות האלה.

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

כדאי כבר להכיר את הנושאים הבאים:

מהי זהות הסוכן?

Google Cloud מספקת סוגים שונים של זהויות לעומסי העבודה שלכם, וכל אחת מהן מיועדת לקבוצה ספציפית של תרחישי שימוש וסוגים של עומסי עבודה. זהות הסוכן היא סוג של זהות שמיועדת לעומסי עבודה של סוכני AI. סוכן שמשתמש בזהות סוכן מקבל זהות ייחודית שמבוססת על תקן SPIFFE. הזהות הזו קשורה למחזור החיים של הסוכן, מזהה את עומס העבודה כסוכן ומזוהה על ידי השירותים השונים של Gemini Enterprise Agent Platform, כמו Agent Registry ו-Agent Gateway. אתם יכולים לעקוב אחרי עומס עבודה שיש לו זהות סוכן ולנהל אותו בכל השירותים שעומס העבודה ניגש אליהם, בלי קשר למקום שבו עומס העבודה פועל. עומס עבודה שמשתמש בזהות של סוכן יכול לעבור אימות לשרתי MCP, למשאבים בתוך Google Cloudומחוצה לו, לסוכנים אחרים ולנקודות קצה באמצעות הזהות שלו או בשם משתמש קצה. מידע נוסף על זהות של סוכן זמין במאמר סקירה כללית על זהות של סוכן.

אתם יכולים להשתמש בזהות הסוכן כדי לשפר את האבטחה והניהול של סוכני AI שאתם פורסים באשכולות GKE, וכדי להפעיל תהליכי עבודה ספציפיים לסוכנים שלכם, כמו:

  • שילוב סוכנים ב-GKE עם מוצרים כמו Agent Registry ו-Agent Gateway.
  • ניהול תפקידים לעומסי עבודה של סוכנים בפרויקטים, בתיקיות או בארגונים באמצעות כללי מדיניות של ניהול זהויות והרשאות גישה (IAM).
  • הפחתת ההשפעה של סוכנים שנפרצו על צמתים ועל Pods אחרים באשכול.
  • הגדרת תהליכי עבודה שונים לאימות, כמו סוכנים שפועלים בשם משתמשי קצה, באמצעות מנהל האימות של Agent Identity.

השוואה עם איחוד זהויות של עומסי עבודה ל-GKE

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

Agent Identity איחוד זהויות של עומסי עבודה ל-GKE
אפשר לקשור אסימוני גישה לזהות של סוכן באופן מוצפן לאישור X.509 לכל Pod. כדי להשתמש בטוקן גישה מאוגד, צריך חיבור mTLS, והוא לא פועל כשמשתמשים בו מחוץ ל-Pod המקורי. טוקני גישה מאוחדים לא קשורים באופן מוצפן לזהויות של Pod, הם פועלים בחיבורים שלא משתמשים ב-mTLS, ואפשר להשתמש בהם מחוץ ל-Pod המקורי.
השילוב עם מנהל האימות של Agent Identity מאפשר תמיכה בתהליכי עבודה של OAuth ושימוש בפרטי כניסה של צד שלישי ללא ניהול ידני של פרטי הכניסה. נדרשת הטמעה ידנית של תהליכי עבודה של OAuth וניהול של פרטי כניסה של צד שלישי כשמבצעים אימות לכלים ולשירותים חיצוניים.
מתאים לעומסי עבודה אוטונומיים כמו סוכני AI. מתאים למיקרו-שירותים דטרמיניסטיים כמו שרתי אינטרנט, ממשקי API ומשימות באצווה.
נדרשת גרסה ‎1.37.0-gke.3503000 של GKE ומעלה. האפשרות זמינה בכל הגרסאות של GKE.
אסימוני גישה של זהות סוכן שמוגבלים לשרת תמיד משתמשים בהיקף הגישה https://www.googleapis.com/auth/cloud-platform. אין תמיכה בהיקפים בהתאמה אישית. טוקני גישה מאוחדים תומכים בהיקפי גישה בהתאמה אישית.
אפליקציות יכולות לקבל אסימונים מזהים של זהות הסוכן כדי לבצע אימות ישירות לעומסי עבודה אחרים או לשירותים במורד הזרם. אפליקציות לא יכולות לקבל טוקנים של מזהה אלא אם חשבון השירות של Kubernetes מוגדר להתחזות לחשבון שירות של IAM.

שילוב עם Agent Platform

‫Gemini Enterprise Agent Platform כוללת מספר מוצרים ושירותים שנועדו ליצירה, לניהול ולהפעלה של סוכנים בהיקפים גדולים. אם אתם מפעילים עומסי עבודה של סוכנים ב-GKE, אתם יכולים להשתמש במוצרי Agent Platform על ידי הקצאת זהויות סוכנים לעומסי העבודה ורישום עומסי העבודה כסוכנים ב-Agent Registry. כדי לשלב את שירותי Agent Platform ולהשתמש בהם עם סוכני GKE, מפעילים של האפליקציה מוסיפים הערות ותוויות למפרטי Kubernetes של עומסי העבודה של הסוכן. חוץ מלוודא שאיחוד זהויות של עומסי עבודה ל-GKE מופעל, לא צריך לבצע שינויים בתצורה של האשכול או של מאגר הצמתים. אחרי זה תוכלו לנהל ולפקח על סוכני GKE באותו אופן שבו אתם מפקחים על סוכן שפועל ב-Agent Runtime או ב-Cloud Run.

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

איך זה עובד ב-GKE

ב-GKE, Agent Identity משתמש במושגים כמו שרת המטא-נתונים של GKE ומאגרי זהויות, בדומה ל-Workload Identity Federation for GKE. כדי להשתמש ב-Agent Identity, צריך גם להפעיל את איחוד זהויות של עומסי עבודה ל-GKE באשכול. Google Cloud יוצר אוטומטית מאגר זהויות של סוכנים ברמת הפרויקט או ברמת הארגון. מאגר הזהויות של הסוכן הוא מתחם אמון (trust domain) של SPIFFE והוא הבסיס לאמון בזהויות ובפרטי הכניסה של הסוכן. מפתחי אפליקציות יכולים לבקש זהות של סוכן עבור הסוכן שלהם על ידי הוספת הערות ותוויות למפרט ה-Pod. כשעומס העבודה נפרס באשכול, GKE מקצה לעומס העבודה את פרטי הכניסה הבאים:

  • זהות SPIFFE שמזהה את עומס העבודה. כל ה-Pods בעומס עבודה מנוהל, כמו Deployment, חולקים את מזהה ה-SPIFFE של עומס העבודה הזה. מזהה SPIFFE מזהה את הסוכן בכל השירותים של Google Cloud . אפשר לעקוב אחרי כל הפעולות ש-Pods מבצעים, בין אם כסוכן או בשם משתמש קצה, באמצעות מזהה SPIFFE. תחביר מזהה SPIFFE:

    spiffe://TRUST_DOMAIN/resources/container/projects/PROJECT_NUMBER/locations/CONTROL_PLANE_LOCATION/clusters/CLUSTER_NAME/ns/NAMESPACE/sa/SERVICEACCOUNT_NAME

    מחרוזת המזהה הזו כוללת את המאפיינים הבאים:

    • ‫TRUST_DOMAIN: תחום האמון של SPIFFE, שיש לו אחד מהערכים הבאים, בהתאם לשאלה אם הפרויקט שמכיל את האשכול נמצא בארגון או לא:
      • פרויקטים שנמצאים בארגון: ‫agents.global.org-ORGANIZATION_ID.system.id.goog, כאשר ORGANIZATION_ID הוא מזהה הארגון.
      • ‫Projects that aren't in an organization: ‏agents.global.proj-PROJECT_NUMBER.system.id.goog, כאשר PROJECT_NUMBER הוא מספר הפרויקט של פרויקט האשכול.
    • ‫PROJECT_NUMBER: מספר הפרויקט של פרויקט האשכול.
    • ‫CONTROL_PLANE_LOCATION: האזור או האזור שבו נמצא מישור הבקרה של האשכול.
    • ‫CLUSTER_NAME: השם של האשכול שבו נמצא ה-Pod.
    • ‫NAMESPACE: השם של מרחב השמות של Kubernetes שה-Pod נמצא בו.
    • ‫SERVICEACCOUNT_NAME: השם של Kubernetes ServiceAccount שהוקצה ל-Pod.

  • חבילת אישורים של זהות הסוכן (x509.credential-bundle.private-key.pem) שמוצמדת כנפח בכל Pod ואפשר להשתמש בה לאימות mTLS ל-APIs של Google Cloud . הקובץ הזה כולל את פרטי הכניסה הבאים:

    • שרשרת אישורים מסוג X.509 שכוללת את מזהה ה-SPIFFE של עומס העבודה של הסוכן כפרמטר Subject Alternative Name‏ (SAN) שתוקף האישור שלו פג תוך 24 שעות. שרשרת האישורים משמשת לקבלת טוקני גישה קשורים ואסימוני זהות לצורך אימות מול שירותים אחרים.
    • מפתח פרטי שתהליך kubelet יוצר באופן אוטומטי לכל Pod. המפתח קושר באופן קריפטוגרפי את אישור X.509 של ה-Pod ל-Pod. המפתח הזה מוכיח שה-Pod ששלח בקשה הוא הבעלים של אישור X.509 ששימש ליצירת חיבור TLS.

  • חבילת מהימנות של CA בסיסי (TRUST_DOMAIN.spiffe-trust-bundle.pem) שמוצמדת כנפח בכל Pod, ואפשר להשתמש בה כדי להגדיר אימות mTLS בין סוכנים שמשתמשים באותו דומיין מהימנות. במהלך לחיצת יד ב-mTLS, סוכן משתמש בחבילת האמון של ה-CA הבסיסי כדי לאמת את שרשרת האישורים שמוצגת על ידי סוכן עמית.

הגדרות ברמת עומס העבודה

כדי להקצות זהות של סוכן ופרטי כניסה לכל Pod לעומס עבודה,‏ GKE מחפש את ההערות הבאות במפרט של ה-Pod:

  • ‫iam.gke.io/identity: "spiffe://TRUST_DOMAIN/*": ‫GKE משתמש באנוטציה הזו כדי להקצות ל-Pods מזהה SPIFFE ממתחם האמון המתאים.

  • ‫iam.gke.io/inject-podcertificates: "true": GKE משתמש בהערה הזו כדי להוסיף את חבילת פרטי הכניסה של זהות הסוכן ואת חבילת האמון של האשכול לכל Pod בעומס העבודה. אם לא מציינים את האנוטציה הזו, אי אפשר לקבל טוקני גישה שמשויכים ל-Pods ספציפיים. פרטי הכניסה שמוזרקים משמשים לאימות mTLS מה-Pods שלכם לכל ממשקי ה-API שלGoogle Cloud או לסוכנים עמיתים.

בנוסף, Agent Registry משתמש בתווית ובהערה הבאות כדי לרשום באופן אוטומטי את סוכני GKE שלכם:

  • ‫registry.gke.io/functional-type: "AGENT" label: מזהה את עומס העבודה כסוכן AI ומוסיף את הסוכן למאגר הסוכנים. התווית הזו נתמכת רק בפריסות, וצריך לציין אותה בשדה metadata.labels של מניפסט הפריסה.
  • הערת iam.gke.io/spiffe-identity-type: "agent-identity": מציינת שהסוכן משתמש ב-Agent Identity. ההערה הזו מוגדרת במפרט של ה-Pod. אם התווית registry.gke.io/functional-type: "AGENT" מצוינת בפריסה, חובה להוסיף את ההערה הזו במפרט של ה-Pod.

כדי לשלב את סוכני GKE עם Agent Platform, צריך לרשום את עומסי העבודה ב-Agent Registry בנוסף לשימוש ב-Agent Identity. כדאי לאכוף את הרישום של עומסי עבודה של סוכנים או להפוך את הרישום לאוטומטי בצינור עיבוד הנתונים לפריסה.

טוקני גישה לסוכנים

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

טוקן הגישה יכול להיות קשור או לא קשור, באופן הבא:

  • אסימון גישה מאוגד: מאוגד באופן קריפטוגרפי לאישור X.509 של ה-Pod, ואפשר להשתמש בו רק בחיבורי mTLS שאומתו באמצעות אישור X.509 הזה. כל בקשה לאסימון גישה שכוללת את אישור X.509 במטען הייעודי (payload) מניבה אסימון קשור.
  • אסימון גישה לא קשור: לא קשור באופן מוצפן ל-Pod ספציפי ואפשר להשתמש בו בחיבורים שלא מבוססים על mTLS. אסימוני גישה לא קשורים פגיעים יותר למתקפות של הפעלה מחדש של אסימונים, כי אפשר להשתמש באסימון שדלף על ידי פוד אחר.

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

אם ל-Pods יש את ההערה iam.gke.io/inject-podcertificates: "true", ספריות הלקוח ב-Cloud וספריות האימות של Google משתמשות ב-Application Default Credentials ‏ (ADC) כדי לקבל באופן אוטומטי אסימון גישה של סוכן מאוגד לזהות עבור Pods. יכול להיות שהתהליך האוטומטי הזה לא יתרחש בכל ספרייה או בכל שפת תכנות. כדי לבקש טוקני גישה לא קשורים, מפתחים יכולים להשתמש באחת מהשיטות הבאות:

  • מציינים את ההערה iam.gke.io/inject-podcertificates: "true" ומגדירים את משתנה הסביבה GOOGLE_API_ENABLE_RUNTIME_BOUND_TOKEN לערך false במפרט של ה-Pod. ‫GKE מוסיף את חבילת פרטי הכניסה X.509 ל-Pod, אבל משתנה הסביבה גורם ל-ADC לקבל טוקני גישה לא מאוגדים.

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

  • אל תציינו את ההערה iam.gke.io/inject-podcertificates: "true" במפרט של ה-Pod. ‫GKE לא מוסיף את חבילת האישורים X.509 ל-Pod, ולכן ADC מקבל טוקני גישה לא קשורים ל-Pods.

  • שליחת בקשת HTTP GET ישירה לנקודת הקצה של האסימון בשרת המטא-נתונים של GKE, שמחזירה אסימון גישה לא מאוגד.

תהליכי עבודה לאימות נציגים

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

  • Google Cloud ממשקי API
  • כלים ושירותים חיצוניים
  • אימות בין נציגים

אימות ל- Google Cloud APIs

סוכן יכול להשתמש בזהות שלו כדי לבצע אימות לממשקי Google Cloud API, כמו BigQuery או Agent Platform. כדי לבצע אימות, ה-Pod מקבל אסימון גישה לזהות הסוכן משרת המטא-נתונים של GKE בצומת. אפשר גם לקשר את טוקן הגישה לאישור X.509 של ה-Pod, כלומר אפשר להשתמש בטוקן הגישה רק בחיבור mTLS שאומת באמצעות אישור X.509.

אם האפליקציה שלכם משתמשת בגרסה 2.61.0 ואילך של ספריית האימות google-auth Python, ‏ Application Default Credentials ‏ (ADC) מבקש באופן אוטומטי טוקני גישה שמשויכים ל-Pods שיש להם חבילת פרטי כניסה של זהות הסוכן. אם אתם משתמשים בספריות הלקוח של Cloud ל-Python, אתם צריכים לוודא שאתם משתמשים בגרסה שכוללת את גרסה 2.61.0 ואילך של ספריית google-auth. בשפות תכנות אחרות או בגרסאות של ספריית google-authPython שקודמות לגרסה 2.61.0, צריך לבקש במקום זאת טוקני גישה לא מאוגדים.

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

כדי להגדיר את קוד האפליקציה כך שיקבל טוקני גישה קשורים או לא קשורים באמצעות השיטות האלה, אפשר לעיין במאמר אימות באמצעות Agent Identity ב-GKE.

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

אימות של סוכנים בשירותים חיצוניים

לסוכנים יש לעיתים קרובות צורך לגשת לכלים ולשירותים חיצוניים באמצעות פרטי כניסה ספציפיים, כמו מפתחות API או טוקנים של OAuth. יכול להיות שהסוכן יצטרך לעבור אימות בתור הזהות שלו או בשם משתמש קצה. אפשר לספק לסוכנים פרטי כניסה ספציפיים באמצעות מנהל האימות של Agent Identity (בגרסת Preview). מנהל ההרשאות מרכז את תהליך קבלת פרטי הכניסה והגדרת תהליך האימות לסוכנים שמופעלים ב- Google Cloud.

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

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

  • גישה לשירותים חיצוניים מטעם משתמש קצה.
  • גישה לשירותים חיצוניים בתור הזהות שלו.
  • גישה לממשקי API באמצעות מפתח API.

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

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

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

  1. ספק האימות מפנה את המשתמש לאימות בשירות החיצוני.
  2. המשתמש מתחבר ומאשר את הגישה שהסוכן צריך.
  3. השירות החיצוני מחזיר פרטי כניסה לספק האימות.

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

  1. האדמין של הפלטפורמה מגדיר את ספק האימות:
    1. יוצרים ספק אימות OAuth תלת-רגלי במרכז ניהול ההרשאות.
    2. מגדירים את ספק האימות להפניה לשרת ההרשאה של צד שלישי.
    3. מגדירים את שירות הצד השלישי כך שישלח את אסימון הגישה של המשתמש לספק האימות.
    4. נותנים לסוכן הרשאה לגשת לספק האימות.
  2. מפתח האפליקציה משנה את האפליקציה:
    1. משנים את קוד הסוכן כדי לבצע אימות באמצעות ספק האימות.
    2. משנים את קוד האפליקציה בצד הלקוח כדי לטפל בכניסה של המשתמש, בהפניה מחדש ובחידוש השיחה.

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

גישה לשירותים חיצוניים בתור הזהות של הסוכן

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

  1. מנהל ההרשאות מבקש טוקן גישה מהשירות החיצוני.
  2. השירות החיצוני מאמת את הבקשה ומחזיר את אסימון הגישה למנהל ההרשאות.

כדי להגדיר OAuth עם 2 רגליים לסוכן שפועל ב-GKE, מבצעים את הפעולות הבאות:

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

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

גישה לממשקי API באמצעות מפתח API

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

  1. האדמין של הפלטפורמה מגדיר את ספק האימות:
    1. יוצרים ספק אימות באמצעות מפתח API במנהל האימות.
    2. יוצרים את מפתח ה-API ושומרים אותו בספק האימות.
    3. נותנים לסוכן הרשאה לגשת לספק האימות.
  2. משנים את קוד הסוכן כדי לבצע אימות באמצעות ספק האימות.

מידע נוסף זמין במאמר אימות באמצעות מפתח API עם מנהל ההרשאות.

אימות בין נציגים

בקטע הזה מתואר תהליך עבודה מתקדם של אימות. כדאי להכיר את הנושאים הבאים:

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

  1. קבלת טוקן של מזהה של סוכן משרת המטא-נתונים של GKE עבור הסוכן שמבצע את הקריאה. באסימון המזהה הזה צריך להגדיר את ההצהרה aud לנקודת הקצה של הסוכן המקבל.
  2. כוללים את האסימון המזהה בכותרת הבקשה Authorization: Bearer של בקשת ה-HTTP.
  3. בסוכן המקבל, מאמתים את אסימון המזהה הנכנס באמצעות מפתחות JWK ציבוריים של מאגר הזהויות של הסוכן, ופרמטרים שונים של הכותרת והגוף באסימון המזהה.

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

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

שליטה בגישה ל Google Cloud משאבים של סוכנים

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

  • כל הסוכנים במתחם אמון (trust domain) ספציפי:

    principalSet://TRUST_DOMAIN/*

    במזהה הזה, TRUST_DOMAIN הוא תחום האמון של היררכיית המשאבים, והוא תלוי בשאלה אם הסוכן נמצא בפרויקט ששייך לארגון:

    • פרויקטים שנמצאים בארגון: ‫agents.global.org-ORGANIZATION_ID.system.id.goog, כאשר ORGANIZATION_ID הוא מזהה הארגון.
    • ‫Projects that aren't in an organization: ‏agents.global.proj-PROJECT_NUMBER.system.id.goog, כאשר PROJECT_NUMBER הוא מספר הפרויקט של אשכול.

  • סוכן יחיד במתחם אמון (trust domain):

    principal://TRUST_DOMAIN/resources/container/projects/PROJECT_NUMBER/locations/CONTROL_PLANE_LOCATION/clusters/CLUSTER_NAME/ns/NAMESPACE_NAME/sa/SERVICEACCOUNT_NAME

    במזהה הזה, הפרמטרים הבאים מזהים את הסוכן הספציפי:

    • ‫PROJECT_NUMBER: מספר הפרויקט של הפרויקט של האשכול.
    • ‫CONTROL_PLANE_LOCATION: האזור או התחום של מישור הבקרה של האשכול.
    • ‫CLUSTER_NAME: השם של האשכול שבו נמצא הסוכן.
    • ‫NAMESPACE_NAME: השם של מרחב השמות של Kubernetes שבו נמצא הסוכן.
    • ‫SERVICEACCOUNT_NAME: השם של חשבון השירות של Kubernetes שעומס העבודה של הסוכן משתמש בו.

מידע נוסף על איתור מזהי ישויות של סוכני GKE ועל ניהול גישה זמין במאמר ניהול גישה ל Google Cloud ממשקי API של סוכנים.

זהות הסוכן תומכת בכל סוגי המדיניות של IAM, כמו מדיניות הרשאות, מדיניות דחייה ומדיניות לקביעת הגישה לישויות מורשות (PAB). כדי לנהל את הגישה של סוכן באשכול GKE שמשתמש בזהות סוכן, צריך לכלול את מזהה החשבון הראשי של הסוכן בסוג המדיניות המתאים. למידע נוסף על הגדרת כל סוג של מדיניות IAM, אפשר לעיין בנושאים הבאים:

הצגה וניהול של סוכנים ב- Google Cloud

אם מפתחי אפליקציות רושמים את הסוכנים שלהם במאגר הסוכנים, תוכלו לראות את סוכני GKE לצד הסוכנים האחרים שאתם מפעילים ב- Google Cloud. במאגר הסוכנים מופיע מזהה ה-SPIFFE של הסוכן, המקום שבו הסוכן פועל וכל מידע נוסף על הסוכן. כל הבקשות ל-API שאומתו באמצעות זהות סוכן יוצרות יומני ביקורת של Agent Registry. בהתאם לתהליך העבודה של האימות שבו הסוכן משתמש, יומני הביקורת של Cloud מספקים את המידע הבא:

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

בנוסף ל-Cloud Audit Logs, מפתחי אפליקציות יכולים להגדיר את עומסי העבודה של הסוכן שלהם כך שיפלטו עקבות, יומנים ומדדים שיהיו גלויים ב-Google Cloud Observability. למידע נוסף על הגדרת עומסי העבודה, אפשר לעיין במסמכים הבאים:

שיפור האבטחה של סוכני GKE

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

  • כדי להגביל את ההשפעה של סוכן שנפרץ, מגדירים מדיניות לקביעת PAB לזהויות של סוכנים.
  • כדי לשפר את האבטחה של ספקי האימות במנהל האימות, צריך להגדיר מדיניות ארגונית לזהויות של סוכנים.
  • כדי לרכז את ניהול הסוכנים ולעקוב אחרי פעולות של סוכנים במקורות מידע שונים, צריך לאכוף את ההרשמה למאגר הסוכנים באמצעות הערות ותוויות, בעזרת בקרי הרשאה כמו ValidatingAdmissionPolicies ו-MutatingAdmissionPolicies.
  • כדי לנהל את האבטחה של תנועה ישירה בין סוכנים, אפשר להשתמש באמצעי הבקרה הבאים:

מגבלות

  • אפשר לרשום באופן אוטומטי רק פריסות במאגר סוכנים. בקרי עומסי עבודה אחרים ו-Pods סטטיים לא תומכים ברישום אוטומטי.
  • אסימוני גישה של סוכן עם זהות מוגבלת משתמשים רק בהיקף ההרשאות https://www.googleapis.com/auth/cloud-platform של OAuth. אי אפשר לציין היקף שונה לטוקנים של גישה שמוגבלים לכתובת IP.
  • אחזור אוטומטי של אסימוני גישה או טוקנים של מזהה שמשויכים למשאב נתמך רק באפליקציות Python שמשתמשות בספריית google-auth בגרסה 2.61.0 ואילך. אם אתם משתמשים בספריות הלקוח של Cloud ל-Python, אתם צריכים להשתמש בגרסה שכוללת את גרסה 2.61.0 ואילך של ספריית google-auth.
  • יכול להיות שספריות לקוח מסוימות של Cloud לא ינתבו באופן אוטומטי את הבקשות שלכם לנקודות קצה של mTLS.
  • כדי לבצע אימות בין סוכנים, אפשר להשתמש בטוקנים של מזהה קשורים רק כדי לבצע אימות בין סוכנים שנמצאים באותו תחום של אמון זהויות סוכנים.

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