CKS (מומחה אבטחת Kubernetes): דרישות קדם ותוכנית לימודים בת 6 שבועות

CKS – מומחה אבטחת Kubernetes מוסמך (Certified Kubernetes Security Specialist) – היא הבחינה הקשה ביותר מבין שלוש בחינות ה-Kubernetes ברמת פרו, לדעתי, צרה יותר מ-CKA ואכזרית יותר תחת לחץ זמן. שעתיים, hands-on, $445, כולל ניסיון חוזר חינם. PSI Bridge, מקוון בלבד, ללא מרכזי בחינה. ציון המעבר הוא 67%. CNCF אינה מפרסמת שיעורי מעבר רשמיים, אך שיעור הניסיונות הראשונים שנאסף מהקהילה מרחף סביב 40–50%, נמוך מ-CKA, וזה תואם את הניסיון שלי בצפייה בעמיתים ניגשים לבחינה.

הדבר שרוב האנשים מפספסים: אי אפשר פשוט להירשם. CNCF דורש CKA פעיל בחשבונכם בזמן ההרשמה. לא "לקחתם את ה-CKA מתישהו." פעיל. אם ה-CKA שלכם פג (מה שקורה כעת לאחר שנתיים במקום שלוש מאז שינוי המדיניות ב-1 באפריל 2024), עליכם לחדש אותו לפני שתוכלו להירשם ל-CKS. זו דרישה מחייבת, לא המלצה בלבד, והיא מפתיעה אנשים בכל רבעון.

דרישות הקדם האמיתיות

הרשמי: CKA פעיל. זהו.

הלא רשמי:

• נוחות עם kubectl עד כדי כך שאינכם חושבים על תחביר. אם אתם עדיין מחפשים בגוגל "kubectl create deployment", אינכם מוכנים.
• יסודות לינוקס — תתחברו ב-SSH ל-nodes, תקראו יומני systemd, תערכו kubelet flags, ותתקנו כשלים בפרופילי seccomp / AppArmor. אם journalctl -u kubelet אינו מוכר, תקנו זאת תחילה.
• מיומנות ב-vim. לא קוסמות ב-Vim. אבל עריכת YAML ב-vim תחת שעון של שעתיים מבלי לאבד 30 שניות ב"רגע, איך אני שומר שוב" היא חובה.
• מודל מנטלי עובד של NetworkPolicy. זוהי נקודת המכשול הגדולה ביותר בבחינה. עוד על כך בהמשך.
• מגע קודם עם Falco, Trivy, AppArmor, seccomp, mTLS דרך service mesh, ו-Pod Security Standards. אינכם צריכים להיות מומחים באף אחד מהם; אתם צריכים לזהות אותם.

אם חסרים לכם יותר משניים מאלה, עשו חודש נוסף של תרגילי הפעלה בסגנון CKA לפני שתתמודדו עם CKS. ניסיון ללמוד פעולות אבטחת Kubernetes וביטחון בו-זמנית תחת לחץ זמן היא דרך לשרוף את הניסיון החוזר החינמי.

מה נבדק בפועל

תכנית הלימודים של CNCF מחלקת זאת כך (האחוזים משתנים עם כל תיקון בתכנית; עדכני לתחילת 2026):

• הגדרת ואבטחת אשכול (~15%): CIS benchmarks, kube-bench, הגבלת גישה חיצונית, השבתת אימות אנונימי, kubelet hardening flags.
• אבטחת מערכת (~15%): אבטחת ליבה (seccomp, AppArmor), הפחתת שטח תקיפה, מזעור IAM בצד הענן.
• מזעור פגיעויות מיקרו-שירותים (~20%): Pod Security Standards (שהחליפו את PSPs בגרסה 1.25), ServiceAccount tokens, OPA / Gatekeeper או Kyverno, mTLS.
• אבטחת שרשרת האספקה (~20%): סריקת תמונות עם Trivy, חתימה עם cosign, בקרי קבלה החוסמים תמונות לא חתומות, יסודות SBOM, מזעור תמונות בסיס.
• ניטור, רישום ואבטחת זמן ריצה (~20%): כללי Falco, ניתוח התנהגותי, אי-שינוי (immutability), רישום ביקורת ברמת ה-API server.
• מדיניות רשת (Network policy) (~10%): default-deny, בידוד מרחבי שמות, כללי יציאה (egress rules). מופיע כאחוז קטן אך בפועל כל קטגוריה אחרת נוגעת גם ב-NetworkPolicy.

הבחינה לא בודקת איך Falco עובד פנימית. היא בודקת אם אתם יכולים לכתוב כלל Falco שיורה כאשר מעטפת (shell) מתחילה בתוך קונטיינר. הבחינה לא בודקת קריפטוגרפיה של cosign. היא בודקת אם אתם יכולים להגדיר בקר קבלה (admission controller) שידחה תמונות לא חתומות. העבודה היא תפעולית, לא אקדמית.

תוכנית הלימודים בת 6 שבועות

זה מניח כ-10 שעות בשבוע עם CKA פעיל כבר בכיס. התאימו אם יש לכם יותר או פחות זמן.

שבוע 1: NetworkPolicy עד שתדממו.

הקימו kind cluster באופן מקומי עם Calico או Cilium (ה-kindnet ברירת המחדל אינו אוכף NetworkPolicy, מה שמכשיל אנשים). כתבו מדיניות default-deny עבור namespace. כתבו מדיניות allow-from-namespace. כתבו מדיניות egress המאפשרת DNS בלבד. כתבו אחת המאפשרת תעבורה מתגית pod ספציפית על פני namespaces. עשו מחדש את כל אלה מהזיכרון עד שתוכלו לכתוב אותם ב-vim מבלי להתייעץ ב-kubernetes.io. קובץ ה-YAML של NetworkPolicy הוא תחום התוכן בעל הנפח הגבוה ביותר בבחינה והאחד שבו רוב האנשים נכשלים. הקדישו לכך יותר זמן ממה שאתם חושבים שצריך.

שבוע 2: Pod Security Standards, ServiceAccounts, הידוק RBAC.

יישמו פרופילים restricted, baseline, ו-privileged על namespaces. הגדירו ServiceAccounts עם automountServiceAccountToken: false. בנו RBAC העוקב אחר עקרון ההרשאה המינימלית (least-privilege) עבור פריסה שצריכה לקרוא ConfigMaps ב-namespace שלה בלבד. תרגלו אבחון "ה-pod הזה לא יכול לעשות X בגלל RBAC" עד שזרימת kubectl auth can-i תהיה אוטומטית.

שבוע 3: שרשרת אספקה — Trivy, cosign, בקרת קבלה (admission control).

סרקו תמונה עם Trivy ופרשו את פלט ה-CVE. חתמו תמונה עם cosign. הגדירו ImagePolicyWebhook או מדיניות Kyverno שתדחה תמונות שאינן חתומות על ידי המפתח שלכם. הקימו OCI registry באופן מקומי אם אתם רוצים תרגול מלא. הבחינה ככל הנראה תספק לכם את Trivy מותקן; עליכם לדעת את הדגלים החשובים שלו בעל פה (--severity HIGH,CRITICAL, --ignore-unfixed).

שבוע 4: זמן ריצה — Falco, AppArmor, seccomp.

התקינו Falco על kind cluster. קראו את כללי ברירת המחדל. כתבו כלל מותאם אישית. יישמו פרופיל AppArmor על pod (הבחינה בדרך כלל מספקת לכם פרופיל שכבר נמצא על ה-node ומבקשת לחבר אותו באמצעות annotation — מה שאומר לדעת את התחביר container.apparmor.security.beta.kubernetes.io/<container>: localhost/<profile>). יישמו פרופיל seccomp באמצעות securityContext.seccompProfile. לשניהם יש תחביר ישן מבוסס annotation ותחביר נוכחי מבוסס שדות; הבחינה נוטה לבדוק את התחביר הנוכחי אך עליכם לזהות את שניהם.

שבוע 5: אבטחת אשכול ומארח.

הריצו kube-bench, פרשו את הכשלים, תקנו את הקלים (אימות אנונימי, רישום ביקורת, kubelet flags). הגדירו מדיניות ביקורת ב-API server. הגבילו גישת etcd. השביתו יציאות kubelet מיותרות. זוהי בעיקר עבודת לינוקס ברמת ה-node וזה המקום שבו מהנדסים ללא רקע חזק בניהול מערכות (sysadmin) מאטים.

שבוע 6: Killer Shell, סימולציות מלאות, ומנוחה.

השתמשו בשתי הפעלות Killer Shell הכלולות השבוע. הן קשות יותר בכוונה מהבחינה האמיתית; צפו לציונים גרועים ממה שקיוויתם. השתמשו בפערים כדי ללמוד. גשו לבחינה בפועל ביומיים-שלושה האחרונים של שבוע 6 בזמן שזיכרון השרירים טרי. אל תדחו אותה עוד — כל שבוע שאתם מתעכבים, אתם מאבדים רפלקסים.

ישנו בלילה שלפני. אל תעשו ליל לימודים לבן. אל תשנו את כינויי ה-kubectl שלכם ביום הבחינה.

המכשולים שטורפים אנשים

NetworkPolicy תחת לחץ זמן. כבר הוזכר ושווה לומר פעמיים. מבנה ה-YAML אינו סלחני — הזחה שגויה הורגת את המדיניות בשקט וה-pod עדיין מנתב. תרגלו ב-vim עד שתוכלו לכתוב default-deny + selective allow מזיכרון שרירים.

שכחתם ש-NetworkPolicy דורש CNI שאוכף אותו. kindnet לא. flannel (ברירת מחדל בהגדרות מסוימות) לא. Calico, Cilium, Weave כן. וודאו שאשכול התרגול שלכם מריץ CNI אוכף אחרת תלמדו את הלקחים הלא נכונים.

בלבול בין PSP ו-Pod Security Standards. PSPs הוסרו בגרסה 1.25 (לפני שנים, אך חומרי הדרכה ישנים עדיין מתייחסים אליהם). המנגנון הנוכחי הוא Pod Security Admission עם הפרופילים restricted, baseline, privileged המיושמים באמצעות תוויות namespace. אל תלמדו PSPs.

תצורת הצפנה-במנוחה של etcd. נבדק לעיתים קרובות. באופן ספציפי: עריכת EncryptionConfiguration, הפעלת מחדש של ה-API server עם הדגל הנכון, ואימות באמצעות etcdctl get שהערך מוצפן. תרגלו זאת.

מלכודת לשונית הדפדפן. מותר לכם להשתמש ב-kubernetes.io, falco.org, app-armor.net, ועוד כמה. אינכם יכולים להסתמך על חיפוש בהם תחת לחץ זמן. שמרו את המבנה בזיכרון. השתמשו בלשונית כדי להעתיק ולהדביק קטעים ספציפיים, לא כדי ללמוד תחביר.

האם כדאי לגשת לבחינה?

גשו ל-CKS אם עבודתכם היא או תהיה אבטחת פלטפורמה, הנדסת אבטחה בחברת Kubernetes, או עבודת תאימות בתעשיות מפוקחות. דלגו עליו אם אתם מהנדסי פלטפורמה כלליים — CKA מכסה את מה שרוב התפקידים הכלליים צריכים, ו-CKS הוא מוגזם שפג תוקפו תוך שנתיים.

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