פתרון בעיות

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

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

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

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

הבעיה הזו קורית כש:

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

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

• מפעילים את Secure Source Manager API בפרויקט.
• מבקשים מהאדמין להקצות לכם את התפקידים הבאים:
  • תפקיד אדמין של מאגר (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 לא נוסף ל-PATH.

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

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

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

  which git-credential-gcloud.sh
  

חיבור SSH נכשל עם השגיאה "no matching"

כשמנסים לבצע פעולות 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]
• ‫MAC: ‏[e-mail], ‏hmac-sha2-256

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

בקשות Git HTTPS נכשלות עם השגיאה permission denied או unauthorized

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

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

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

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

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

   git config --list | grep credential
   

2. אם מופיעה שורה שדומה ל-*credential*.helper=store ב-macOS או ל-credential.helper = manager ב-Windows, צריך להסיר את השורות האלה, לאמת מחדש באמצעות 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 נכשלות עם טוקן לא חוקי

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

אם בקשת 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:

  • אין תמיכה בטוקנים גולמיים שנוצרו מזהות עומס העבודה של צי GKE. מידע נוסף זמין במאמר SSM returns an error when using KSA tokens with GKE fleet workload identity.

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

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

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

     gcloud auth application-default login
     

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

     gcloud config set auth/git_helper_use_adc true
     

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

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

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

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

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

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

כשמשתמשים בWorkload Identity של fleet ב-GKE, 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

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

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

שגיאה בהגדרת הטריגרים לפיתוח גרסת Build

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

Build cannot be created.

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

• הפורמט או האפשרויות בקובץ התצורה של Cloud Build לא תקינים.
• ל-Service Agent של Secure Source Manager אין את התפקיד יצירת אסימונים בחשבון שירות בחשבון השירות בניהול המשתמש של המאגר.
• לחשבון השירות בניהול המשתמש אין את התפקיד משתמש בחשבון שירות בחשבון השירות של Cloud Build.
• לחשבון השירות בניהול המשתמש אין את התפקיד עריכה ב-Cloud Build בפרויקט שבו פועלים ה-builds.
• מדיניות הארגון iam.disableCrossProjectServiceAccountUsage חוסמת את השימוש בחשבון השירות בניהול המשתמשים (אם חשבון השירות נמצא בפרויקט אחר).

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

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

ה-build נכשל במהלך ההרצה

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

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

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

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

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

remote: Push rejected: Sensitive data detected.

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

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

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

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

  git push -o dlpskip=true origin BRANCH_NAME
  

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

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

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

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

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

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

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

Permission denied on resource ...

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

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