פתרון בעיות

בדף הזה מוסבר איך לפתור בעיות נפוצות ב-Certificate Authority Service.

בקשת API מחזירה HTTP 403 Forbidden

אם בקשת API מחזירה HTTP 403 Forbidden עם ההודעה Read access to project PROJECT_NAME was denied, צריך להשתמש בפתרון הבא.

פתרון

  1. בודקים את הרשאות ה-IAM של השולח.
  2. בודקים את המיקום של הבקשה. באזורים שלא נתמכים, יכול להיות שתתקבל שגיאת דחיית הרשאה. מידע נוסף על מיקומים נתמכים זמין במאמר מיקומים.

מחיקת רשות אישורים מחזירה HTTP 412 Failed Precondition

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

  • Cannot perform Certificate Authority deletion, Certificate Authority is in state ENABLED.

פתרון

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

הנפקת האישור נכשלה

שירות ה-CA מספק כמה אמצעי בקרה של מדיניות שבהם אפשר להשתמש כדי לנהל את הנפקת האישורים. מידע נוסף על אמצעי הבקרה של המדיניות זמין במאמר סקירה כללית של תבניות אישורים ומדיניות הנפקה.

יכולות להיות כמה סיבות לכך שהנפקת האישור נכשלה. אלה כמה מהסיבות האפשריות:

  • יש סתירה בין מדיניות הנפקת האישורים של מאגר ה-CA לבין תבנית האישור.

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

    פתרון

    בודקים את מדיניות הנפקת האישורים של מאגר ה-CA מול תבנית האישור, ומזהים את הסתירות ופותרים אותן.

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

  • הנושא או שמות הנושאים החלופיים (SAN) נכשלים בהערכת הביטוי CEL בתבנית האישור או במדיניות הנפקת האישורים של מאגר רשויות האישורים.

    פתרון

    בודקים את מדיניות הנפקת האישורים ואת תבנית האישורים של מאגר ה-CA, ומוודאים שהנושא ו-SAN עומדים בתנאים שמוגדרים על ידי ביטויי Common Expression Language ‏ (CEL). מידע נוסף על ביטויי CEL זמין במאמר שימוש ב-Common Expression Language.

  • הוענק תפקיד IAM שגוי לתרחיש שימוש. לדוגמה, הקצאת התפקיד roles/privateca.certificateRequester לזהות משוקפת או הקצאת התפקיד roles/privateca.workloadCertificateRequester למצב ברירת מחדל של זהות.

    פתרון

    מוודאים שהקציתם את התפקיד roles/privateca.certificateRequester למצב זהות ברירת מחדל ואת התפקיד roles/privateca.workloadCertificateRequester לזהות משוקפת. מידע נוסף על שימוש בהעתקת זהויות זמין במאמר העתקת זהויות לעומסי עבודה מאוחדים.

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

    Could not use the REFLECTED_SPIFFE subject mode because the caller does not have a SPIFFE identity. Please visit the CA Service documentation to ensure that this is a supported use-case.

    פתרון

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

  • ההגבלה על גודל המפתח שמוגדרת כברירת מחדל דוחה מפתחות RSA עם גודל מודולוס של פחות מ-2,048 ביט.

    השיטות המומלצות בתחום הן להשתמש במפתח RSA של לפחות 2048 ביט. כברירת מחדל, CA Service מונע הנפקת אישורים באמצעות מפתח RSA שגודל המודולוס שלו קטן מ-2048 ביט.

    פתרון

    אם רוצים להשתמש במפתח RSA עם גודל מודולוס קטן מ-2048 ביט, צריך לאפשר זאת באופן מפורש באמצעות מדיניות הנפקת האישורים. בדוגמה הבאה של קובץ YAML מוצג איך לאפשר מפתחות RSA כאלה:

    allowedKeyTypes:
- rsa:
    minModulusSize: 1024

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