פתרון בעיות

בדף הזה מוסבר איך לפתור בעיות ב-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. כדי לבדוק את הגרסה של gcloud CLI, פועלים לפי ההוראות שבמאמר התקנה של 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 של Fleet ב-GKE:

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

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

  כדי לפתור את הבעיה, צריך להגדיר את מאפיין ההגדרה git_helper_use_adc gcloud CLI לערך 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, שיכול להפריע לאסימוני אימות של gcloud CLI על ידי אחסון וסנכרון של אסימונים לא עדכניים. האסימונים האלה שפג תוקפם עלולים לגרום לכך שהאימות ייכשל ב-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 שגוי או שהוא מכיל אפשרויות לא חוקיות.
• לסוכן השירות של Secure Source Manager אין את התפקיד Service Account Token Creator בחשבון השירות בניהול המשתמש של המאגר.
• לחשבון השירות בניהול המשתמש אין את התפקיד Service Account User בחשבון השירות של Cloud Build.
• לחשבון השירות בניהול המשתמש אין את התפקיד Cloud Build Editor בפרויקט שבו מופעלות הבנייה.
• מדיניות הארגון iam.disableCrossProjectServiceAccountUsage חוסמת את השימוש בחשבון השירות בניהול המשתמשים (אם חשבון השירות נמצא בפרויקט אחר).

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

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

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

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

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

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

העלאה ל-Git נדחתה בגלל זיהוי של מידע אישי רגיש

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

remote: Push rejected: Sensitive data detected.

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

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

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

• אם המידע שזוהה מקובל ויש לכם הרשאות מתאימות, אפשר לדלג על הבדיקה באמצעות האפשרות -o dlpskip=true push:

  git push -o dlpskip=true origin BRANCH_NAME
  

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

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

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

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

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

שגיאה בהגדרת חשבון שירות למאגר

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

Permission denied on resource ...

הבעיה הזו מתרחשת כשאין לכם את התפקיד Service Account User ‏(roles/iam.serviceAccountUser) בחשבון השירות שאתם מנסים לשייך למאגר. מערכת Secure Source Manager מוודאת שיש לכם הרשאה לפעול כחשבון השירות לפני שהיא מאפשרת לכם לשייך אותו למאגר.

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