מערכת מאובטחת: מה חשוב כשהמערכת רצה, גם אם שם הכלי הוא Kubernetes

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

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

Pod מקשר קונטיינרים צמודים שחולקים רשת ולעיתים volumes. עדיפו קונטיין ראשי אחד ל-pod למעט sidecar ללוגים, mTLS או proxy. Pod הוא חד-פעמי; בקרים יוצרים מחדש - עיצבו stateless בשכבת האפליקציה.

Deployments מנהלים ReplicaSets ומגלגלים תבניות pod בהדרגה. הגדירו maxUnavailable ו-maxSurge לאיזון זמינות ומהירות. פריסות מושהות עוזרות כשמאבחנים שחרור רע בלי לקרוס לגמרי.

בדיקות חיוניות (liveness/readiness) מבדילות בין "רץ" לבין "מוכן". קונפיגורציה שגויה יוצרת לולאות restart או ירידה שקטה של תעבורה - וודאו מול עקומות עליה אמיתיות.

Services נותנים נקודות קצה יציבות ו-DNS בתוך האשכול. ClusterIP לתעבורה פנימית; NodePort ו-LoadBalancer צפונית-דרומית; headless לתבניות גילוי שירותים עם StatefulSets.

Ingress או Gateway API מרכזים ניתוב HTTP/S וסיום TLS. בחרו בקר מתוחזק והבינו headers גדולים, WebSocket ומגבלות קצב נפוצות לאפליקציה.

ConfigMaps ו-Secrets מפרידים קונפיג לא רגיש מסודות, אך זכרו ש-Secret אינו הצפנה קסומה - הגנו על etcd במנוחה, רוטציה שוטפת ואינטגרציה ל-KMS או External Secrets. Git מחזיק הפניות, לא ערכים.

בקשות ומגבלות משאבים משפיעות על תזמון והוגנות. קיצור יתר ב-CPU גורם ל-throttling; היעדר מגבלות זיכרון מזמין evictions. מדדו שימוש אמיתי לפני העתקת דוגמאות מבלוגים.

HPA מבצע סקייל אופקי לפי CPU, זיכרון או מדדים מותאמים - לעיתים עומק תור כמבשר עומס. צמדו עם cluster autoscaler בזהירות; רפליקות בלי Nodes לא עוזרות.

Namespaces ו-RBAC מבודדים צוותים. default deny עם RoleBinding מפורש עדיף על cluster-admin משותף. ביקורת מי יכול exec ולקרוא Secrets - אלה נתיבי גישה לפרודקשן.

NetworkPolicies מוסיפות סמנטיקת חומת אש בין pod-ים. בלי כך, כל pod פרוץ סורק שכנים. התחילו ב-deny ברירת מחדל לnamespaces רגישים ואז אפשרו קצוות מינימליים.

StatefulSets, Operators ו-CRD מופיעים כשמריצים DB או בקרי תור על Kubernetes - אך שקלו האם שירות מנוהל מחוץ לאשכול מצמצם עומס.

לסיכום: שלטו ב-Deployments, Services, probes, ingress ומשמעת סודות לפני רדיפת פיצ׳רים אקזוטיים. אשכולות יציבים מגיעים ממניפסטים צנועים שמופעלים בעקביות, לא מאוסף Helm ענק.

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