כשסוכני AI גנרטיבי מקיימים אינטראקציה עם כלים, ממשקי API או שירותים חיצוניים (כמו BigQuery, Jira, GitHub או מפות Google), הם צריכים מנגנון מאובטח לאימות בקשות יוצאות. מנהל האימות של זהות הסוכן (מנהל האימות) מספק את זה על ידי פעולה ככספת מרכזית של פרטי כניסה וכמתווך אימות שמפשט את האימות של כלי דואר יוצא.
היתרונות של שימוש בכלי לניהול הרשאות
הכלי לניהול הרשאות מספק את היתרונות הבאים לפיתוח סוכנים:
- מאגר מרכזי של פרטי כניסה: מאחסן מפתחות API, סודות של לקוחות OAuth ואסימוני משתמשים במאגר שמנוהל על ידי Google, ועוזר להימנע מסודות שמוצפנים בהארדקוד ומאחסון מסדי נתונים בהתאמה אישית.
- OAuth 2.0 אוטומטי: מטפל בתהליכי OAuth 2.0 מרובי שלבים, כמו הסכמת משתמשים, החלפת קוד הרשאה ורענון אסימונים, ללא קוד קצה עורפי מותאם אישית.
- שילוב חלק עם ADK: משתלב באופן טבעי עם Agent Development Kit (ADK) כדי לאחזר ולהוסיף כותרות אימות יוצאות, כמו
AuthorizationאוX-Goog-Api-Key, לקריאות לכלים ולשרת Model Context Protocol (MCP). - בקרת גישה מפורטת למזהי SPIFFE: נעשה שימוש בזהויות של סוכנים שמבוססות על SPIFFE כדי להגדיר מדיניות מדויקת לניהול זהויות והרשאות גישה (IAM), וכך לוודא שרק מנהלים ומפתחים מורשים של סוכנים יכולים לגשת לספקי אימות ספציפיים.
איך פועל מרכז ניהול ההרשאות
מנהל ההרשאות פועל ככספת של פרטי כניסה בין סביבת Agent Runtime ב-Gemini Enterprise Agent Platform לבין נקודות קצה של שירותים חיצוניים.
כשסוכן קורא לכלי חיצוני, ה-ADK מיירט את ההפעלה של הכלי, מבקש את פרטי הכניסה המתאימים מהכספת של מנהל ההרשאות ומצרף את כותרות האימות הנדרשות לפני שהוא שולח את הבקשה לממשק ה-API של היעד.
תרשים הזרימה הבא ממחיש את הארכיטקטורה ברמה גבוהה ואת מחזור החיים של אחזור פרטי הכניסה:
- משתמש הקצה מפעיל אירוע או הנחיה שדורשים אימות של כלי יוצא.
- הסוכן שנפרס (באמצעות ADK) מיירט באופן שקוף את בקשת הכלי ושולח שאילתה לכספת של מנהל ההרשאות המאובטח.
- מנהל ההרשאות מחזיר את פרטי הכניסה המאובטחים (מפתח API או טוקן OAuth) לסוכן.
- הסוכן מפעיל את ה-API או הכלי החיצוניים עם פרטי הכניסה המצורפים.
- שירות הצד השלישי מאמת את פרטי הכניסה ומחזיר את הנתונים המבוקשים לסוכן.
- הסוכן משתמש בנתונים שהוחזרו כדי ליצור את התשובה הסופית ולשלוח אותה למשתמש.
דוגמאות לשילובים עם צד שלישי
מנהל ההרשאות תומך בדפוסי OAuth 2.0 ומפתחות API סטנדרטיים, ולכן הוא תואם לשירותים רבים של צד שלישי.
בטבלה הבאה מפורטים כמה שירותים מאומתים של צד שלישי, שיטות האימות הנתמכות שלהם ומסמכי ההגדרה.
| שירות | שיטות אימות נתמכות | מסמכי הגדרה של פרטי כניסה |
|---|---|---|
| Atlassian Jira | OAuth תלת-רגלי, מפתח API | מדריך Jira OAuth 2.0 |
| Dropbox | OAuth תלת-רגלי | מדריך OAuth של Dropbox |
| GitHub | OAuth תלת-רגלי* | אפליקציות GitHub OAuth |
| GitLab | OAuth תלת-רגלי | ספק OAuth של GitLab |
| Microsoft | OAuth תלת-רגלי* | Microsoft identity platform |
| Salesforce | OAuth תלת-רגלי, OAuth דו-רגלי | אפליקציות מקושרות של Salesforce |
| ServiceNow | OAuth תלת-רגלי*, OAuth דו-רגלי | הגדרת OAuth ב-ServiceNow |
* פרטים על מגבלות ודרישות של השירות מופיעים במאמר שיקולים ספציפיים לשירות.
שיקולים ספציפיים לשירות
- GitHub ו-Microsoft: מנהל ההרשאות תומך בשילובים עם היקף יחיד ב-GitHub וב-Microsoft. מנהל ההרשאות לא תומך בבקשה של כמה היקפי הרשאות. מידע נוסף זמין במאמר בנושא שגיאה ב-GitHub או ב-Microsoft בנוגע להיקפים מרובים.
- ServiceNow: ב-ServiceNow, האדמינים מגדירים את היקפי הגישה המותרים ברמת האפליקציה. לא משנה מה הסוכן מבקש, ServiceNow מעניקה רק את היקפי ההרשאות שהוגדרו. אם נציג דורש היקף שלא הוגדר, יכול להיות שהאימות ייכשל או שהבקשה תיכנס ללולאה. מוודאים שהגדרת אפליקציית ServiceNow כוללת את כל ההיקפים שהסוכן שלכם צריך. מידע נוסף זמין במאמר בנושא לולאת אימות או היקפי גישה לא צפויים ב-ServiceNow.
מיקומים
מנהל האימות של Agent Identity זמין באזורים באמריקה, באירופה ובאסיה-פסיפיק. לרשימת האזורים הנתמכים, ראו מיקומי Agent Identity.