פתרון בעיות

בדף הזה מוסבר איך לפתור בעיות ב-Secure Source Manager.

הודעת שגיאה כשיוצרים מאגר

השגיאה הבאה מופיעה כשמנסים ליצור מאגר:

There was an error while loading /repo/create. Try refreshing the page.

הבעיה הזו מתרחשת במקרים הבאים:

• ‫Secure Source Manager API לא מופעל בפרויקט.
• אין לכם את התפקיד Repo Admin בפרויקט או הרשאות ליצור מאגרי קוד במכונה של Secure Source Manager.

כדי לפתור את הבעיה:

• מפעילים את Secure Source Manager API בפרויקט.
• צריך לבקש מהאדמין להקצות לכם את התפקידים הבאים:
  • תפקיד Repo Admin (roles/securesourcemanager.repoAdmin) בפרויקט.
  • ‫Instance Accessor ‏ (roles/securesourcemanager.instanceAccessor) במופע של Secure Source Manager.
  • ‫Instance Repository Creator‏ (roles/securesourcemanager.instanceRepositoryCreator) במכונה של Secure Source Manager.

מידע נוסף זמין במאמר בקרת גישה באמצעות IAM.

הודעת שגיאה בשכפול מאגר ב-Mac

השגיאה הבאה מופיעה כשמנסים לשכפל מאגר:

git: 'credential-gcloud.sh' is not a git command.  See 'git --help'.
fatal: Authentication failed for [repo-url]

הבעיה הזו מתרחשת במקרים הבאים:

• ה-CLI של gcloud מותקן באמצעות Homebrew או התקנה לא סטנדרטית אחרת.
• ‫git-credential-gcloud.sh לא נוסף לנתיב.

כדי לפתור את הבעיה:

• מריצים את source $HOMEBREW_PREFIX/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/path.zsh.inc

• מריצים את הפקודה הבאה כדי לוודא ש-git-credential-gcloud.sh נמצא בנתיב:

  which git-credential-gcloud.sh
  

חיבור SSH נכשל עם השגיאה 'אין התאמה'

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

• Unable to negotiate with <host> port <port>: no matching key exchange method found.
• Unable to negotiate with <host> port <port>: no matching cipher found.
• Unable to negotiate with <host> port <port>: no matching MAC found.

הבעיה הזו מתרחשת כשלקוח ה-SSH לא תומך באלגוריתמים הקריפטוגרפיים שנדרשים על ידי Secure Source Manager. זה יכול לקרות אם אתם משתמשים בלקוח SSH ישן יותר או אם הלקוח שלכם לא מוגדר לשימוש באלגוריתמים נתמכים.

ב-Secure Source Manager צריך להשתמש באחד מהאלגוריתמים הבאים:

• אלגוריתמים מרכזיים להחלפת מפתחות: curve25519-sha256, diffie-hellman-group14-sha256
• Ciphers: [e-mail], aes128-ctr, aes192-ctr, aes256-ctr, [e-mail], [e-mail]
• ‫MACs: [e-mail], hmac-sha2-256

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

בקשות Git HTTPS נכשלות עם שגיאה של דחיית הרשאה או חוסר הרשאה

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

הבעיה הזו מתרחשת באחד מהמקרים הבאים:

• קובץ התצורה הגלובלי של Git לא כולל את כלי העזר לאימות של Secure Source Manager.
• נעשה שימוש במאגר פרטי הכניסה המובנה של Git במקום להפעיל את כלי העזר לאימות של Secure Source Manager כדי לקבל פרטי כניסה חדשים.
• במקום לקרוא לכלי העזר לאימות של Secure Source Manager כדי לקבל פרטי כניסה חדשים, נעשה שימוש בכלי עזר של המערכת לפרטי כניסה.
• כשמבצעים אינטראקציה עם מאגרי Secure Source Manager באמצעות HTTPS, נעשה שימוש בגרסה ישנה יותר של Google Cloud CLI. ‫Secure Source Manager דורש גרסה 395.0.0 או גרסה חדשה יותר של Google Cloud CLI.

כדי לפתור את הבעיה:

1. מריצים את הפקודה הבאה כדי לראות את התוכן של קובץ ההגדרות הגלובלי של Git.

   git config --list | grep credential
   

2. אם אתם רואים שורה שדומה ל-*credential*.helper=store ב-macOS, או ל-credential.helper = manager ב-Windows OS, צריך להסיר את השורות האלה ואז לבצע אימות מחדש באמצעות gcloud auth login לפני שמנסים שוב את פקודת Git.

3. אם התגובה לא כוללת את credential.https://*.*.sourcemanager.dev.helper=gcloud.sh ב-macOS או ב-Linux, או את credential.https://*.*.sourcemanager.dev.helper=gcloud.cmd ב-Windows, צריך להוסיף את כלי העזר לאימות של Secure Source Manager להגדרות ה-Git הגלובליות:

   Linux

   1. כדי להוסיף את כלי העזר לאימות של Secure Source Manager להגדרות ה-Git הגלובליות, מריצים את הפקודה הבאה:

      git config --global credential.'https://*.*.sourcemanager.dev'.helper gcloud.sh
      

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

      git config --list | grep credential
      

      הפלט צריך לכלול את המחרוזת credential.https://*.*.sourcemanager.dev.helper=gcloud.sh.

   3. מריצים את הפקודה gcloud auth login כדי לבצע אימות.

   4. מריצים פקודת Git כדי לבדוק את האימות.

   Windows

   1. כדי לבדוק את הגרסה של ה-CLI של gcloud, פועלים לפי ההוראות שבמאמר התקנה של Git ו-Google Cloud CLI.

   2. כדי להוסיף את כלי העזר לאימות של Secure Source Manager להגדרות ה-Git הגלובליות, מריצים את הפקודה הבאה:

      git config --global credential.https://*.*.sourcemanager.dev.helper gcloud.cmd
      

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

      git config --list | grep credential
      

      הפלט צריך לכלול את המחרוזת credential.https://*.*.sourcemanager.dev.helper=gcloud.cmd.

   4. מריצים את הפקודה gcloud auth login כדי לבצע אימות.

   5. מריצים פקודת Git כדי לבדוק את האימות.

4. אם הגדרתם בעבר את פרטי הכניסה למארח Git כ-gcloud.sh, אבל קיבלתם שגיאה כמו 'credential-gcloud.sh' is not a git command, זה מצביע על כך שמערכת Git לא מצליחה למצוא את הסקריפט git-credential-gcloud.sh ב-PATH במחשב שלכם. מעדכנים את PATH או מחליפים את gcloud.sh בקובץ gitconfig בנתיב המוחלט.

בקשות Git HTTPS נכשלות עם טוקן לא תקין

נדרש אסימון OAuth תקף כסיסמה לפעולות Git HTTPS. בדרך כלל, Git credential helper מטפל בזה, אבל אפשר גם להשתמש בטוקנים מסוג OAuth שנוצרו בשיטות אחרות (לדוגמה, application default credentials).

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

• יכול להיות שפג התוקף של הכניסה שלכם ל-CLI של gcloud.

  צריך להיכנס שוב באמצעות gcloud auth login.

• היקף ההרשאות של הטוקן לא מספיק. טוקנים של OAuth צפויים לכלול את ההיקפים הבאים:

  • https://www.googleapis.com/auth/cloud-platform
  • https://www.googleapis.com/auth/userinfo.email

  כדי לבדוק את היקף האסימון, אפשר להתקשר אלcurl https://oauth2.googleapis.com/tokeninfo?access_token=${TOKEN}

• אתם משתמשים באסימון שנוצר מWorkload Identity של צי GKE:

  • אין תמיכה באסימונים גולמיים שנוצרו מ-Workload Identity בצי GKE. מידע נוסף זמין במאמר SSM מחזירה שגיאה כשמשתמשים באסימוני KSA עם Workload Identity של Fleet ב-GKE.

• יש לכם מדיניות ארגונית שמונעת שימוש באסימונים מחוץ לגבולות מסוימים, למשל בקרת גישה מבוססת-הקשר.

  כדי לפתור את הבעיה, צריך להגדיר את מאפיין ההגדרה git_helper_use_adc ה-CLI של gcloud לערך true ולעדכן את פרטי הכניסה ב-Application Default Credentials ‏ (ADC):

  1. הגדרת המאפיין git_helper_use_adc:

     gcloud config set auth/git_helper_use_adc true
     

  2. מעדכנים את ה-ADC:

     gcloud auth login --update-adc
     

בקשות Git HTTPS נכשלות ב-macOS עם שגיאת 403 בגלל פרטי כניסה לא עדכניים

כשמבצעים פעולות Git באמצעות HTTPS ב-macOS, יכול להיות שתתקבל שגיאת 403.

הבעיה הזו יכולה להתרחש ב-macOS אם משתמשים ב-iCloud Keychain, שיכול להפריע לאסימוני אימות של ה-CLI של gcloud על ידי אחסון וסנכרון של אסימונים לא עדכניים. האסימונים האלה שפג תוקפם עלולים לגרום לכך שהאימות ייכשל ב-Secure Source Manager, גם אחרי שמבצעים אימות מחדש באמצעות gcloud auth login.

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

1. פותחים את האפליקציה Keychain Access ב-Mac (נמצאת בתיקייה /Applications/Utilities/).
2. חיפוש של sourcemanager.dev.
3. מוחקים את כל הרשומות מסוג 'סיסמה לאינטרנט' שתואמות ל-*.*.sourcemanager.dev או לכתובת ה-URL של מופע Secure Source Manager. כדי לעשות זאת, לוחצים לחיצה ימנית על הרשומה ובוחרים באפשרות מחיקה.
4. אחרי שמוחקים את הרשומות, מנסים שוב לבצע את הפעולה ב-Git. יכול להיות שתתבקשו לבצע אימות מחדש באמצעות ה-CLI של gcloud. אם פעולות Git ממשיכות להיכשל, מריצים את הפקודה gcloud auth login לפני שמנסים שוב.

‫SSM מחזיר שגיאה כשמשתמשים באסימונים של חשבון שירות של Kubernetes ‏ (KSA) עם Workload Identity של צי GKE

כשמשתמשים ב-Workload Identity של GKE Fleet,‏ Secure Source Manager לא תומך בטוקנים גולמיים של KSA. השימוש באסימונים האלה יוביל לשגיאה.

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

iam.gke.io/gcp-service-account: SERVICE_ACCOUNT@PROJECT_ID.iam.gserviceaccount.com

הפרויקט לא מופיע בבורר המוצרים בממשק האינטרנט

כשמשתמשים בבורר המוצרים בממשק האינטרנט של Secure Source Manager, הפרויקט לא מופיע.

הבעיה הזו מתרחשת אם יש לכם כמה פרטי כניסה ל-Secure Source Manager.

כדי לפתור את הבעיה:

• כדי למחוק את קובצי ה-Cookie, מוסיפים את המחרוזת הבאה לכתובת ה-URL של מופע Secure Source Manager: /_oauth/consent

  לדוגמה, אם כתובת ה-URL של המופע היא https://my-instance-098765432123.us-central1.sourcemanager.dev/, מזינים https://my-instance-098765432123.us-central1.sourcemanager.dev/_oauth/consent בסרגל הכתובות של הדפדפן ואז נכנסים באמצעות פרטי הכניסה הנכונים.

קובץ ההפעלה לא מפעיל את ה-build

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

• קובץ הטריגרים לא נמצא בענף ברירת המחדל. כדי לפתור את הבעיה, צריך להעביר את קובץ הטריגרים לענף ברירת המחדל.
• הפורמט של קובץ הטריגרים לא תקין. השגיאה הזו מסומנת בבאנר בדף המאגר עם הכיתוב Build triggers configuration error: .... כדי לפתור את הבעיה, כדאי לעיין בסכימת קובץ הטריגרים. אם ההגדרה של קובץ הטריגרים נכונה, בבאנר בדף המאגר יופיע הכיתוב Valid build triggers configuration.

שגיאה בהגדרת טריגרים של build

אחרי ששולחים את קובץ triggers.yaml למאגר Secure Source Manager, השגיאה הבאה מוצגת בבאנר:

Build cannot be created.

הבעיה הזו מתרחשת מהסיבות הבאות:

• קובץ ההגדרות של Cloud Build מכיל אפשרויות לא חוקיות.
• הפורמט של קובץ תצורת ה-build של Cloud Build לא תקין.
• לחשבון השירות של Secure Source Manager אין את ההרשאות הנדרשות לשימוש בחשבון השירות של Cloud Build שצוין על ידי המשתמש.

כדי לפתור את הבעיה:

• חשוב לוודא שאתם פועלים בהתאם לסכימת קובץ הטריגרים הנכונה.
• מוודאים שלחשבון השירות של Secure Source Manager ולחשבון השירות של Cloud Build יש הרשאות מספיקות. במאמר תפקידים נדרשים בחשבון שירות מפורטות ההרשאות הנדרשות.

ה-build נכשל במהלך הביצוע

אם ה-build מופעל בהצלחה, אבל נכשל במהלך ההרצה, סטטוס הקומיט המשויך הוא Failure.

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

יומן הביצוע של Cloud Build ייפתח. מידע נוסף על פתרון בעיות ב-builds ב-Cloud Build זמין במאמר פתרון שגיאות ב-build.

המכסה היומית לא מתאפסת אחרי יצירה מחדש

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

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

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

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