מדריך

הערכת תצורת האשכול מול שיטות עבודה מומלצות לאבטחה בתקן התעשייה.

→השתמש ב- `kube-bench` כדי להריץ בדיקות CIS Kubernetes Benchmark מול צמתים של לוח הבקרה (control plane) וצמתים עובדים (worker nodes).

למה: `kube-bench` הוא הכלי הסטנדרטי למשימה ספציפית זו, המבצע אוטומציה של בדיקות מול הנחיות CIS מקיפות.

מקור↗

אכיפת אימות חזק לכל בקשות שרת ה-API.

→הגדר דגלי `kube-apiserver`: `--anonymous-auth=false` כדי לדחות בקשות לא מאומתות, ו- `--client-ca-file` כדי לאכוף אימות תעודת לקוח (mTLS).

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

מקור↗

אבטחת מאגר ה-etcd של האשכול מפני גישה בלתי מורשית וגניבת נתונים.

→הגדר את etcd עם mTLS לכל תקשורת הלקוח והעמיתים (`--cert-file`, `--key-file`, `--peer-cert-file`). הפעל הצפנת secrets-at-rest באמצעות הדגל `--encryption-provider-config` של שרת ה-API.

למה: etcd מכיל את כל סודות האשכול. הצפנת נתונים בתעבורה (mTLS) ובמנוחה היא קריטית להגנה על מידע רגיש גם אם צמתי etcd נפרצו.

מקור↗

סבוב מפתחות הצפנה-במנוחה של etcd עם אפס זמן השבתה.

→1. הוסף את המפתח החדש כרשומה הראשונה בקובץ `EncryptionConfiguration`. 2. הפעל מחדש את כל שרתי ה-API. 3. אכוף הצפנה מחדש של כל הסודות (`kubectl get secrets -A -o json | kubectl replace -f -`). 4. לאחר האימות, הסר את המפתח הישן מהתצורה והפעל מחדש את שרתי ה-API.

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

יישום מודל רשת באפס אמון (zero-trust) בתוך מרחב שמות.

→החל `NetworkPolicy` עם `podSelector: {}` ריק ו- `policyTypes: [Ingress, Egress]` אך ללא כללי `ingress` או `egress`. זה בוחר את כל ה-pods ומונע את כל התעבורה.

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

מקור↗

NetworkPolicies של Egress חוסמות רזולוציית DNS עבור pods.

→הוסף כלל egress ספציפי כדי לאפשר תעבורה לשירות ה-DNS של האשכול. אפשר egress לפורט 53 בפרוטוקולי UDP ו-TCP כאחד. בחר את ה-kube-dns pods באמצעות `namespaceSelector` ו- `podSelector` אם אפשר.

למה: NetworkPolicies הן גרעיניות. כלל egress כללי לבלוק IP עשוי לא לכסות את הפרוטוקול הספציפי (UDP) הנדרש עבור DNS, מה שיוביל לכשלי רזולוציה.

אבטחת גישה חיצונית לשירותים החשופים באמצעות Ingress.

→הגדר את משאב ה-Ingress על ידי הוספת סעיף `tls` המפנה ל-Kubernetes Secret מסוג `kubernetes.io/tls`. הסוד חייב להכיל את תעודת ה-TLS והמפתח הפרטי.

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

הענקת הרשאות מינימליות בלבד למשתמשים או ליישומים.

→השתמש ב- `Roles` ו- `RoleBindings` מוגבלים למרחב שמות היכן שאפשר. הימנע מ- `cluster-admin` ומתווים כלליים (`"*"`) ב- `verbs` או ב- `resources`. הענק הרשאות ספציפיות כמו `["get", "list"]` על `["pods"]`.

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

מקור↗

הקטנת שטח התקיפה עבור pods שאינם צריכים לקיים אינטראקציה עם ה-API של Kubernetes.

→בטל הרכבה אוטומטית של טוקני חשבון שירות על ידי הגדרת `automountServiceAccountToken: false` בחשבון השירות או במפרט ה-Pod.

למה: אם pod נפרץ, תוקף אינו יכול לנצל טוקן מורכב כדי לגשת לשרת ה-API, ובכך למנוע התקפות ברמת האשכול שמקורן ב-pod הפרוץ.

וודא אם למשתמש או לחשבון שירות ספציפי יש הרשאה לבצע פעולה.

→השתמש ב- `kubectl auth can-i <verb> <resource> --as=<user>` או `kubectl auth can-i <verb> <resource> --as=system:serviceaccount:<ns>:<sa-name>`.

למה: פקודה זו מאפשרת התחזות כדי לבדוק במדויק הרשאות יעילות מבלי צורך לנתח ידנית את כל ה-Roles וה-Bindings.

שמירה על אבטחת האשכול על ידי סבוב קבוע של תעודות לוח הבקרה ו-kubelet.

→עבור אשכולות kubeadm, השתמש ב- `kubeadm certs renew all`. עבור אחרים, עקוב אחר הליך הסבוב הידני או האוטומטי המתועד. אפשר סבוב תעודות לקוח/שרת kubelet דרך התצורה שלו.

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

מקור↗

צומת עובד חשוד שנפרץ וחייב להיות מבודד באופן מיידי.

→ראשית, השתמש ב- `kubectl cordon <node-name>` כדי למנוע את תזמוןם של pods חדשים. לאחר מכן, השתמש ב- `kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data` כדי לפנות בבטחה עומסי עבודה רצים.

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

הגבלת קריאות המערכת שקונטיינר יכול לבצע לליבת המארח.

→ב- `securityContext` של ה-Pod או הקונטיינר, הגדר את `seccompProfile.type` ל- `RuntimeDefault` לבסיס בטוח, או `Localhost` עם נתיב לפרופיל JSON מותאם אישית לשליטה קפדנית יותר.

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

מקור↗

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

→החל פרופיל AppArmor על קונטיינר באמצעות ההערה: `container.apparmor.security.beta.kubernetes.io/<container_name>: localhost/<profile_name>`. הפרופיל חייב להיות טעון מראש על הצומת.

למה: AppArmor מספק בקרת גישה חובה (MAC - Mandatory Access Control), ומוסיף שכבת הגנה מעמיקה קריטית כדי להכיל יישום שנפרץ ולמנוע ממנו גישה למשאבים בלתי מורשים.

מקור↗

קונטיינר זקוק לפעולה מיוחסת ספציפית (לדוגמה, קישור לפורט 80) מבלי לרוץ כשורש.

→ב- `securityContext.capabilities`, `drop: ["ALL"]` ולאחר מכן `add: ["NET_BIND_SERVICE"]`.

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

מניעת קונטיינר מלקבל גישה מלאה למערכת המארחת.

→הגדר `securityContext.privileged: false` (זוהי ברירת המחדל). השתמש ב-Pod Security Standards או OPA/Kyverno כדי לאכוף זאת ברחבי האשכול.

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

אכיפת תצורות אבטחה בסיסיות או מחמירות עבור pods ברמת מרחב שמות.

→החל תוויות על מרחב השמות, לדוגמה, `pod-security.kubernetes.io/enforce: restricted`. המצבים הם `enforce`, `audit`, ו- `warn`.

למה: Pod Security Standards (PSS) מספקים מדיניות אבטחה מובנית ורב-שכבתית המחליפה את ה-PodSecurityPolicy המיושן, מה שמקל על אכיפת שיטות עבודה מומלצות לאבטחה.

מקור↗

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

→הגדר `securityContext` המשלב `runAsNonRoot: true`, `allowPrivilegeEscalation: false`, ו- `readOnlyRootFilesystem: true`.

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

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

→הגדר משאב `RuntimeClass` המצביע על מטפל זמן ריצה בסביבה מבודדת (sandboxed runtime handler) (לדוגמה, gVisor, Kata Containers). הקצה לו pods באמצעות `spec.runtimeClassName`.

למה: זמני ריצה מבודדים (sandboxed runtimes) משתמשים בליבת מרחב משתמש (user-space kernel) או מכונות וירטואליות קלות משקל כדי ליירט קריאות מערכת, ומספקים שכבת בידוד נוספת בין הקונטיינר לבין ליבת המארח.

מקור↗

אכיפת מדיניות אבטחה מורכבת ומותאמת אישית שאינה מכוסה על ידי בקרות Kubernetes סטנדרטיות.

→פרוס את OPA Gatekeeper. הגדר מדיניות באמצעות `ConstraintTemplate` (הלוגיקה של Rego) ויישם אותן עם משאבי `Constraint`.

למה: Gatekeeper פועל כ-validating admission webhook, ומאפשר לאכוף כללים שרירותיים, כגון דרישה לתוויות ספציפיות, מניעת נתיבי מארח, או אכיפת מגבלות משאבים.

מקור↗

אספקת סודות ל-pods באופן המאובטח ביותר.

→הרכב סודות כקבצים לנפח אחסון. לאבטחה גבוהה עוד יותר, השתמש במנהל התקן CSI של מאגר סודות כדי להרכיב סודות מכספת חיצונית (לדוגמה, HashiCorp Vault, AWS Secrets Manager) ישירות ל-pod.

למה: הרכבה כקבצים מאובטחת יותר ממשתני סביבה (שניתן לרשום או לחשוף). מנהל התקן CSI מונע אחסון הסוד ב-etcd כלל.

הצפנה ואימות אוטומטי של כל תעבורת הרשת בין pods.

→פרוס service mesh כגון Istio או Linkerd. ה-mesh מזריק sidecar proxy לכל pod כדי לטפל בהצפנת mTLS, אימות ואכיפת מדיניות.

למה: Service mesh מספק רשת שקופה, באפס אמון, מבלי לדרוש שינויים כלשהם בקוד היישום, ובכך מאבטח את כל תקשורת השירות הפנימית.

מניעת פריסת תמונות קונטיינר עם פגיעויות ידועות (CVEs).

→שלב סורק כמו Trivy או Grype לתוך צינור ה-CI/CD. כשל את הבנייה אם הפגיעויות חורגות מסף חומרה מוגדר (לדוגמה, HIGH או CRITICAL).

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

מקור↗

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

→חתום על תמונות באמצעות `cosign` במהלך תהליך בניית ה-CI. השתמש במנוע מדיניות (Kyverno, OPA Gatekeeper) כבקר קבלה (admission controller) כדי לאמת את החתימה מול מפתח ציבורי לפני שמאפשר יצירת pod.

למה: חתימה קריפטוגרפית מספקת ערובות חזקות לשלמות התמונה (שלא שונתה) ולאותנטיות (שהגיעה ממקור מהימן).

מקור↗

מזעור שטח התקיפה בתוך תמונת קונטיינר עצמה.

→השתמש בתמונות בסיס מינימליות (לדוגמה, distroless, Alpine). השתמש ב-Dockerfile רב-שלבי כדי לזרוק כלי בנייה. הגדר משתמש שאינו root עם הוראת ה- `USER`. השתמש ב- `.dockerignore` כדי להוציא קבצים רגישים.

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

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

→השתמש בבקר קבלה (כמו OPA Gatekeeper או Kyverno) כדי ליצור מדיניות המאמתת את שדה ה- `image` של כל מפרטי הקונטיינרים מול רשימת היתרים של שמות מארחים של רשמים.

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

שמירה על מלאי של כל רכיבי התוכנה והתלויות בתוך תמונת קונטיינר.

→שלב כלי כמו `Syft` לתוך צינור ה-CI/CD כדי לייצר Software Bill of Materials (SBOM) בפורמט סטנדרטי כמו SPDX או CycloneDX.

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

זיהוי תצורות אבטחה שגויות בקובצי YAML של Kubernetes לפני יישומן.

→בצינור ה-CI, השתמש בכלי כמו `trivy config` או `kubesec` כדי לסרוק קובצי manifest של Kubernetes עבור תצורות מסוכנות, כגון ריצה כשורש, מתן אפשרות להגברת הרשאות, או הרכבת נתיבי מארח רגישים.

למה: בדיקה פרואקטיבית זו מזהה בעיות אבטחה בתשתית כקוד (infrastructure-as-code) לפני שהן יוצרות פגיעויות באשכול הרץ.

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

→פרוס את Falco כ-DaemonSet. Falco משתמש ב-eBPF או במודול ליבה כדי לנטר קריאות מערכת ומתריע על התנהגות חריגה בהתבסס על מערך הכללים שלו (לדוגמה, shell בקונטיינר, חיבורי רשת בלתי צפויים).

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

מקור↗

כלל Falco ברירת מחדל מייצר יותר מדי התרעות שווא.

→צור קובץ כללי Falco מותאם אישית כדי לדרוס את כלל ברירת המחדל. הוסף חריגים ל- `condition` של הכלל כדי לא לכלול התנהגות ידועה כטובה, כגון תהליכים ספציפיים או תמונות קונטיינר (לדוגמה, `and not container.image.repository contains "debug"`).

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

תיעוד יומן כרונולוגי ובלתי ניתן לשינוי של כל הפעולות שבוצעו מול ה-API של Kubernetes.

→אפשר רישום ביקורת ב- `kube-apiserver` על ידי אספקת הדגלים `--audit-policy-file` ו- `--audit-log-path`. הגדר את המדיניות כדי להגדיר מה נרשם ובאיזו רמה.

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

מקור↗

ביקורת גישה למשאבים רגישים כמו Secrets מבלי לרשום את תוכן הסוד עצמו.

→הגדר את כלל מדיניות הביקורת עבור Secrets להשתמש ב- `level: Metadata`. זה רושם את המשתמש, חותמת זמן, משאב ופועל, אך משמיט את גופי הבקשה והתגובה.

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

צבירת יומנים מכל רכיבי האשכול והיישומים לצורך ניתוח מרכזי.

→פרוס סוכן איסוף יומנים (לדוגמה, Fluentd, Vector) כ-DaemonSet כדי לאסוף יומנים מצמתים ולהעביר אותם למערכת SIEM או ניהול יומנים מרכזית (לדוגמה, Elasticsearch, Splunk).

למה: רישום יומנים מרכזי חיוני לתיאום אירועים ברחבי האשכול במהלך חקירת אירוע ולשמירה על רשומות לטווח ארוך לצורך עמידה בתקנים.

העברת התרעות אבטחה של Falco למערכת חיצונית לצורך התראה ותגובה.

→פרוס את `Falcosidekick` לצד Falco. הגדר אותו לקבל התרעות מ-Falco ולהעביר אותן לפלטים כמו Slack, PagerDuty, או SIEM.

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

זיהוי אם קונטיינר רץ שונה, דבר שיכול להעיד על פשרה.

→אכיפת קונטיינרים בלתי ניתנים לשינוי (immutable) באמצעות `readOnlyRootFilesystem: true`. השתמש בכלי אבטחת זמן ריצה כמו Falco כדי לנטר ולהתריע על כל כתיבת קבצים למיקומים בלתי צפויים.

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