יד חותמת על מסמך תעודה – המחשה לאימות והרשאות הנפקת תעודות
צילום: olia danilevich / Pexels

חולשה ב-AWS Private CA ל-Kubernetes: מה לעדכן לפני שהתעודות ייפגעו

AWS פרסמה התראת אבטחה חשובה על CVE-2026-119115 במחבר AWS Private CA עבור Kubernetes. הכשל אפשר, בתנאים מסוימים, למשתמש מאומת שמורשה לעבוד רק עם מנפיק תעודות ברמת namespace לקבל תעודות — ואף תעודות CA כפופות — ממנפיק ברמת cluster שלא הותר לו להשתמש בו.

מה בדיוק נפגע?

aws-privateca-issuer הוא מנפיק חיצוני ל-cert-manager, שמקבל בקשות תעודה מ-Kubernetes וחותם עליהן באמצעות AWS Private Certificate Authority. לפי AWS, הכשל נמצא בלוגיקת פתרון זהות המנפיק: גרסאות פגיעות לא אכפו נכון את ההפרדה בין AWSPCAIssuer המוגבל ל-namespace לבין AWSPCAClusterIssuer הזמין ברמת האשכול.

הגרסאות המושפעות הן aws-privateca-issuer לפני 1.10.1, וכן תוסף EKS של AWS Private CA Connector for Kubernetes לפני 1.10.1-eksbuild.1.

למה זה משמעותי?

תעודה דיגיטלית היא לא רק קובץ הצפנה. בסביבת Kubernetes היא יכולה לקבוע מי מזוהה כשירות מהימן, מי רשאי להקים חיבור TLS, ולעיתים מי יכול להנפיק תעודות נוספות. האפשרות לקבל תעודה ממנפיק ברמת cluster חורגת מגבול ההרשאה שהוגדר למשתמש ועלולה לערער את מודל ההפרדה בין צוותים ו-namespaces.

מה צריך לעשות עכשיו?

  • לשדרג את המחבר לגרסה 1.10.1 או את תוסף EKS לגרסה 1.10.1-eksbuild.1 ומעלה.
  • לבצע ביקורת לפני השדרוג על משאבי CertificateRequest, Certificate ו-Ingress.
  • להגדיר במפורש את issuerRef.kind: ‏AWSPCAIssuer למנפיק ברמת namespace או AWSPCAClusterIssuer למנפיק ברמת cluster.
  • לבדוק חידושי תעודות לאחר השדרוג, משום שבקשות שהסתמכו על ההתנהגות המקלה הישנה עלולות להיכשל או להישאר במצב Pending.

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

אם אי אפשר לשדרג מיד

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

השורה התחתונה

ארגונים שמפעילים cert-manager מול AWS Private CA צריכים להתייחס לעדכון כאל שינוי אבטחה וגם כאל שינוי תאימות. הפעולה הבטוחה היא למפות תחילה את כל ההפניות למנפיקים, לתקן issuerRef.kind, לשדרג בסביבה מבוקרת ולוודא בפועל שתעודות חדשות וחידושים ממשיכים להצליח.

מקור: AWS Security Bulletin 2026-156-AWS, ‏29 באוקטובר 2026.

צילום: olia danilevich / Pexels — דף המקור. רישיון Pexels Free מתיר שימוש באתר, בסושיאל ובשיווק.

דילוג לתוכן