ניהול תצורה וסודות ב-Kubernetes: ConfigMap ו-Secret

מסד הנתונים שלך שינה את הסיסמה. אתה פותח את המניפסטים, מחפש היכן הערך מקודד ב-env או args, ומבין שזה ייקח חצי יום. נתקלנו במצבים כאלה עשרות פעמים. עם 5 שנות ניסיון ב-DevOps, הצוות שלנו עוזר לחברות לארגן ניהול תצורה ב-Kubernetes כך שסיבוב סודות ייקח דקות, לא ימים. מאמר זה מכסה כיצד להשתמש נכון ב-ConfigMap ו-Secret, אילו מלכודות קיימות, וכיצד לשלב חנויות חיצוניות.

ConfigMap: למה הוא מיועד ולמה הוא לא מיועד

ConfigMap מאחסן נתונים לא מוצפנים: קבצי תצורה, משתני סביבה, סקריפטים. הנתונים מאוחסנים ב-etcd בטקסט פשוט — זה קריטי להבין. לעולם אל תשים סיסמאות, טוקנים או מפתחות API ב-ConfigMap. זו לא רק הפרה של "שיטות עבודה מומלצות" — אם etcd או kubectl get configmap -o yaml נפרצים, הכל נראה בטקסט פשוט.

מועמדים טובים ל-ConfigMap: nginx.conf, prometheus.yml, application.properties עם הגדרות timeout ו-feature flags, DATABASE_HOST, LOG_LEVEL, APP_ENV.

הרכבה כקובץ לעומת משתנה סביבה מתנהגת אחרת בעדכון. כאשר מורכבים כ-volume (volumeMounts + volumes.configMap), kubelet מעדכן את הקובץ ב-pod תוך configMapAndSecretChangeDetectionStrategy (ברירת מחדל ~2 דקות) ללא הפעלה מחדש של הקונטיינר. משתני סביבה מ-envFrom.configMapRef אינם מתעדכנים עד להפעלה מחדש של ה-pod. ב-80% מהמקרים, אנו ממליצים על volumeMounts — זה מפחית זמן השבתה במהלך שינויי תצורה.

---
spec:
  containers:
    - name: app
      envFrom:
        - configMapRef:
            name: app-config
        - secretRef:
            name: app-secrets
      volumeMounts:
        - name: nginx-config
          mountPath: /etc/nginx/conf.d
          readOnly: true
  volumes:
    - name: nginx-config
      configMap:
        name: nginx-config
        items:
          - key: default.conf
            path: default.conf

Secret: אחסון וסיבוב

Secret כברירת מחדל מאוחסן גם ב-etcd ב-base64 — זה לא הצפנה. להצפנה אמיתית, אתה צריך spec: containers: - name: app envFrom: - configMapRef: name: app-config - secretRef: name: app-secrets volumeMounts: - name: nginx-config mountPath: /etc/nginx/conf.d readOnly: true volumes: - name: nginx-config configMap: name: nginx-config items: - key: default.conf path: default.conf ברמת kube-apiserver עם ספק כמו EncryptionConfiguration או aescbc. בלעדיו, base64 ב-etcd הוא אבטחה כוזבת. בפרויקט אחד, גילינו סודות בטקסט פשוט ב-etcd. תיקון זה לקח שעתיים. עכשיו אנו משתמשים בספק KMS שמצפין נתונים תוך כדי תנועה.

חשוב להשתמש בסוג ה-Secret הנכון:

• kms — לסודות משיכת תמונות מ-registry
• kubernetes.io/dockerconfigjson — לתעודות TLS (cert-manager יוצר אלה)
• kubernetes.io/tls — לכל השאר

סיבוב סודות ללא הפעלה מחדש של ה-pod עובד רק כאשר מורכבים כ-volume. אבל רוב היישומים קוראים סודות פעם אחת בעת ההפעלה — כך שסיבוב עדיין דורש עדכון מתגלגל. יש לקחת זאת בחשבון בעת תכנון תהליך הסיבוב. חלופה היא להשתמש ב-External Secrets Operator עם Reloader כדי להפעיל מחדש pods אוטומטית כאשר Secret מתעדכן. יישמנו זאת בפרויקט גדול: זמן התקרית לאחר דליפה ירד משעתיים ל-5 דקות.

כיצד לארגן נכון אחסון סודות?

הנה מדריך שלב אחר שלב:

1. ביקורת — בדוק את כל ה-Deployments עבור ערכים מקודדים ב-Opaque ו-env. בחודש אחד, זיהינו מעל 200 הפרות ברחבי קלאסטר.
2. חילוץ תצורה — נתונים לא רגישים ל-ConfigMap, רגישים ל-Secret.
3. הגדרת הצפנת etcd — הפעל EncryptionConfiguration. זה מפחית את סיכון הדליפה פי 10.
4. שילוב עם חנות חיצונית — אם נדרש, התקן External Secrets Operator או Sealed Secrets.
5. RBAC — ה-ServiceAccount של היישום צריך גישה רק לאובייקטים שלו.
6. תיעוד — תאר את תהליך הסיבוב עבור כל סוד.
7. הדרכת צוות — סדנה של 1-2 שעות.

ציר זמן: יום אחד ליישום סטנדרטי עם 5-10 תצורות. לשילוב External Secrets Operator — 2-3 ימים. במשך 5 שנים, השלמנו יותר מ-30 פרויקטים כאלה.

למה לא להשתמש ב-ConfigMap לסודות

ConfigMap מאחסן נתונים בטקסט פשוט. אם תוקף מקבל גישה לקלאסטר (דרך pod, שרת API, או etcd), הוא יכול לקרוא את כל הסיסמאות. זה מפר לא רק שיטות עבודה מומלצות אלא גם תקני אבטחה (PCI DSS, SOC2). השתמש ב-Secret עם הצפנת etcd מופעלת. כברירת מחדל, Secret אינו מוצפן, אבל לאחר הגדרת EncryptionConfiguration, הנתונים הופכים לבלתי נגישים ללא המפתח. יישום הצפנת etcd מפחית את זמן התגובה לתקרית ב-80%.

מה זה External Secrets Operator ומתי הוא נדרש?

External Secrets Operator (ESO) מסנכרן סודות מחנויות חיצוניות (HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager) לתוך Kubernetes Secret. היישום קורא Kubernetes Secret רגיל מבלי לדעת את המקור. ESO שימושי במיוחד בסביבות ארגוניות עם קלאסטרים מרובי צוותים ו-GitOps. השווה: עדכון מניפסט ידני במהלך סיבוב לוקח שעות; עם ESO, זה לוקח דקות. בפרויקט אחד, הפחתנו את זמן הסיבוב מ-4 שעות ל-5 דקות ללא התערבות אנושית. ESO גם משתלב עם Reloader, שמפעיל מחדש pods אוטומטית כאשר Secret משתנה.

שילוב עם חנויות חיצוניות

אחסון סודות ישירות ב-Kubernetes Secret מקובל לפרויקטים קטנים, אבל לא לסביבות ארגוניות או מרובות צוותים. לעבודה רצינית, השתמש ב-External Secrets Operator, שמסנכרן סודות מ-HashiCorp Vault, AWS Secrets Manager, או GCP Secret Manager לתוך Kubernetes Secret. חלופה היא Sealed Secrets ל-GitOps: SealedSecret יכול להיות מאוחסן בבטחה במאגר Git, וה-operator מפענח אותו בקלאסטר.

מה כלול בעבודה שלנו

• ביקורת על התצורה הנוכחית ואבטחת הקלאסטר
• עיצוב ארכיטקטורת אחסון תצורה וסודות
• הגדרת EncryptionConfiguration להצפנת etcd
• יישום לפי שיטות עבודה מומלצות (RBAC, NetworkPolicy, תבנית sidecar)
• שילוב עם External Secrets Operator או Sealed Secrets
• אוטומציה של סיבוב סודות (דרך Reloader או סקריפטים מותאמים)
• תיעוד לתהליכי סיבוב ושחזור
• הדרכת צוות (1-2 שעות)

היכולות שלנו

• 5 שנות ניסיון בניהול DevOps ו-Kubernetes
• יותר מ-30 פרויקטים מוצלחים של הגירה ואופטימיזציה של תצורה
• מנהלי Kubernetes מוסמכים (CKA)
• עבודה עם AWS EKS, GKE, Yandex Cloud, Selectel
• runbooks מותאמים לתקריות אופייניות, הפחתת MTTR פי 3

קרא עוד על Kubernetes Secret בתיעוד הרשמי. עבור External Secrets Operator, ראה GitHub.

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