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

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

שינויים צפויים בהרשאות

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

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

בעקבות העדכון:

  • כדי להריץ שילוב, צריך הרשאה לפעול כחשבון השירות של run-as.
  • אם אף אחת מהזהויות לא זמינה, הפעלת השילוב תיכשל.

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

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

  1. נותנים הרשאת משתמש בחשבון שירות לכל חשבון שירות מסוג run-as שבו אתם כבר משתמשים, לכל מי שמריץ, מאשר, עורך או מפרסם את השילוב – כולל חשבונות השירות שבהם האוטומציה שלכם משתמשת.
  2. מגדירים חשבון שירות להרצת תהליכים בשילובים שפועלים ללא התערבות של אדם ואין להם חשבון שירות כזה.
  3. Grant Service Account User בחשבון השירות שמופיע בכל פרופיל אימות מהסוגים Service account או OIDC token. בדרך כלל אלה חשבונות שונים מחשבון השירות שלכם להרצת תהליכים.

שילובים שדורשים חשבון שירות מסוג run-as

בודקים אם נדרש שילוב

צריך חשבון שירות מסוג run-as רק כשאין פרטי כניסה של אף אחד שזמינים לכל ההרצה. זה קורה בשני מצבים בלבד:

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

זיהוי השילובים המושפעים

קודם כל, האם הוא פועל אי פעם בלי אדם? היא תעשה זאת אם אחד מהתנאים הבאים מתקיים:

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

curl -s -G -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  --data-urlencode "filter=state=ACTIVE" \
  --data-urlencode "pageSize=1000" \
  "https://REGION-integrations.googleapis.com/v1/projects/PROJECT_ID/locations/REGION/integrations/-/versions" \
| jq -r '.integrationVersions[]
         | [ .name, (.runAsServiceAccount // "NONE") ]
         | @tsv'

מחליפים את מה שכתוב בשדות הבאים:

  • ‫REGION: האזור של השילוב. רשימת האזורים הנתמכים מופיעה במאמר מיקומים.
  • ‫PROJECT_ID: מזהה הפרויקט ב-Google Cloud
  • שורות עם הערך NONE דורשות פעולה רק אם גם החלק הראשון חל עליהן.
  • כדי לבדוק שילוב יחיד, פותחים אותו במסוף Google Cloud ומסתכלים עלהחלונית Integration summary (סיכום השילוב) בסרגל הכלים של השילוב.

עדכון השילובים

הענקת הרשאה 'משתמש בחשבון שירות'

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

gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT \
    --project=SERVICE_ACCOUNT_PROJECT_ID \
    --member='user:PRINCIPAL' \
    --role='roles/iam.serviceAccountUser'

מחליפים את מה שכתוב בשדות הבאים:

  • ‫SERVICE_ACCOUNT: כתובת האימייל של חשבון השירות מסוג run-as או של החשבון שצוין בפרופיל אימות
  • ‫SERVICE_ACCOUNT_PROJECT_ID: מזהה הפרויקט שבבעלותו חשבון השירות
  • ‫PRINCIPAL: כתובת האימייל של המשתמש

לסוגים אחרים של חשבונות משתמש, משתמשים בקידומת --member המתאימה:

  • קבוצות: משתמשים ב-group:. כדי לפשט את ניהול הגישה כשחברי הצוות משתנים, מומלץ להשתמש בקבוצות Google ולא בחשבונות משתמשים פרטניים.
  • חשבונות שירות: משתמשים ב-serviceAccount: לתהליכים אוטומטיים ולאפליקציות.

כדי לעשות את אותו הדבר במסוף Google Cloud :

  1. עוברים אל IAM & Admin > Service Accounts (ניהול הרשאות גישה ושליטה > חשבונות שירות).
  2. בוחרים את חשבון השירות.
  3. לוחצים על הרשאות > מתן גישה.

מידע נוסף מופיע במאמר בנושא ניהול הגישה לחשבונות שירות.

הגדרת חשבון שירות מסוג 'הרצה בתור'

  1. בוחרים או יוצרים את חשבון השירות ומעניקים לו את התפקידים שהמשימות של השילוב צריכות במשאבים שהן ניגשות אליהם. כדי להבין אילו הרשאות צריך לתת, בודקים אילו תפקידים יש לסוכן השירות של שילוב האפליקציות בפרויקט, service-PROJECT_NUMBER@gcp-sa-integrations., נכון לעכשיו, ונותנים לחשבון החדש רק את החלק שמשמש את השילוב הזה.
  2. צריך להעניק את ההרשאה 'משתמש בחשבון שירות' לכל מי שמריץ, מאשר, עורך או מפרסם את השילוב, כולל כל אוטומציה.
  3. פותחים את השילוב ומגדירים את חשבון השירות בחלונית Integration summary בסרגל הכלים של השילוב.
  4. מפרסמים את השילוב. מידע נוסף זמין במאמר בנושא בדיקה ופרסום של אינטגרציות.

מומלץ להשתמש בחשבון שירות ייעודי עם היקף הרשאות מינימלי לכל שילוב, ולא בחשבון אחד עם הרשאות רחבות שמשותף לכולם, כי זה מאפשר:

  • מכיל את האפקט של כל שילוב.
  • מופיע בשם ביומני הביקורת.

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

פתרון בעיות שקשורות להרשאות חסרות

יש שתי סיבות אפשריות לדחיית פעולה, וכדאי להבחין ביניהן:

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

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

שגיאות בחשבון שירות מסוג Run-as

מצב מה יוצג לכם מה לעשות?
מישהו מפעיל שילוב אבל אין לו הרשאה לפעול בתור חשבון השירות של השילוב הטריגר נדחה עם PERMISSION_DENIED. הבדיקה מופעלת לפני שהריצה מתווספת לתור, כך שלא מופיע כלום ביומני הביצוע – נראה כאילו לא קרה כלום, ולא כאילו משימה נכשלה Grant Service Account User to whoever triggers it
בהרצה ללא פרטי כניסה של משתמש, לא מוגדר חשבון שירות להרצה בתורו משימות של מחברים, קריאה לנקודת קצה של REST ופונקציות Cloud Run נכשלות מול כל מה שהן מנסות להגיע אליו. בפרסום: The integration is missing run-as service account since governance is enabled for your project. הגדרת חשבון שירות להרצה
משימה משתמשת בפרופיל אימות שחשבון השירות שלו לא מאפשר למבצע הקריאה לפעול בשמו הגישה למשימה הזו נדחית, אבל שאר הריצה ממשיכה: You do not have permission to use Auth Config ID because you cannot act as its service account: SERVICE_ACCOUNT. Grant Service Account User on the account named in the profile
המאשר לא יכול לפעול כחשבון השירות להרצה תהליך האישור נכשל בלי להציג שגיאה. ההרצה נשארת בהשהיה עד שהיא מסתיימת, ולכן נראה שהאישורים הפסיקו לפעול נותנים את התפקיד Service Account User לכל מי שעשוי לאשר
מישהו עורך או מפרסם אינטגרציה ללא הרשאה Publisher does not have required permission to publish integration with service account: SERVICE_ACCOUNT. כל מה שכבר פורסם ממשיך לפעול. אם האוטומציה מפרסמת בשבילכם, היא מופיעה בצינור הפריסה ולא במסוף הענקת הרשאת משתמש בחשבון שירות לעורכים, לבעלי אתרים ולמערכות אוטומטיות
המשימה מופעלת על ידי האדם שהפעיל אותה, ולאדם הזה אין גישה למשאב ההפעלה מתחילה כרגיל, ואז משימה אחת נכשלת בשם משאב, למרות שלא חל שינוי בשילוב לתת לאנשים האלה גישה למשאב, או להעביר את השילוב לחשבון שירות מסוג run-as שכבר יש לו גישה – בדרך כלל זו האפשרות הטובה יותר, כי היא מונעת את השינוי בגישה של השילוב בהתאם למי שמריץ אותו.

לרשימה המלאה של קודי השגיאה של Application Integration, ראו קודי שגיאה.

שגיאות בתפקידי IAM

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

כדי לעשות זאת צריך להיות לכם אחד מהתפקידים האלה
איך רואים ופותחים שילובים roles/integrations.integrationViewer
הצגת יומני הביצוע ופרטים ‫roles/integrations.integrationViewer או roles/integrations.integrationInvoker
הרצת שילוב ‫roles/integrations.integrationInvoker או roles/integrations.integrationEditor
יצירה ועריכה של שילובים roles/integrations.integrationEditor
פרסום שילוב ‫roles/integrations.integrationDeployer או roles/integrations.integrationEditor
אישור או הפעלה מחדש של ריצה מושהית ‫roles/integrations.suspensionResolver או roles/integrations.integrationAdmin
גישה מלאה לכל האינטגרציות roles/integrations.integrationAdmin

כדי להקצות תפקיד, מריצים את הפקודה הבאה:

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member='user:PRINCIPAL' \
    --role='ROLE'

למידע נוסף, קראו את המאמרים הבאים:

שאלות נפוצות

נתתי את התפקיד ועדיין יש שגיאה. מה חסר לי?

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

למה תפקיד מפעיל האינטגרציה כבר לא מספיק?

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

  • roles/integrations.integrationAdmin
  • roles/integrations.integrationEditor
  • roles/integrations.integrationInvoker

השילוב שלי פועל רק באופן סינכרוני. צריך חשבון שירות מסוג run-as?

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

אף פריט לא מסומן במסוף. האם אני יכול להמשיך?

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

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