אבטחה

בדף הזה מוסבר על תכונות האבטחה שכלולות ב-Google Distributed Cloud (תוכנה בלבד) ל-VMware, כולל כל שכבה בתשתית, ואיך אפשר להגדיר את תכונות האבטחה האלה בהתאם לצרכים שלכם.

סקירה כללית

‫Google Distributed Cloud (תוכנה בלבד) ל-VMware מציע כמה תכונות שיעזרו לכם לאבטח את עומסי העבודה, כולל התוכן של קובץ אימג' של קונטיינר, זמן הריצה של הקונטיינר, רשת האשכול וגישה לשרת ה-API של האשכול.

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

אימות והרשאה

אתם מבצעים אימות לאשכולות באמצעות OpenID Connect ‏(OIDC) או אסימון של חשבון שירות ב-Kubernetes דרך מסוף Cloud.

כדי להגדיר גישה גרנולרית יותר למשאבי Kubernetes ברמת האשכול או במרחבי שמות של Kubernetes, משתמשים בבקרת גישה מבוססת-תפקידים (RBAC) ב-Kubernetes. RBAC מאפשר ליצור מדיניות מפורטת שמגדירה לאילו פעולות ומשאבים אתם רוצים לאפשר למשתמשים ולחשבונות שירות לגשת. באמצעות RBAC, אתם יכולים לשלוט בגישה לכל זהות מאומתת שסופקה.

כדי לפשט ולייעל עוד יותר את אסטרטגיית האימות וההרשאה שלכם ב-Kubernetes Engine, ב-Google Distributed Cloud מושבתת בקרת גישה מבוססת-מאפיינים (ABAC) מדור קודם.

אבטחה של מישור הבקרה

הרכיבים ברמת הבקרה כוללים את שרת ה-API של Kubernetes, מתזמן, בקרי Kubernetes ומסד נתוני etcd שבו נשמרת ההגדרה של Kubernetes. ב-GKE, רכיבי מישור הבקרה של Kubernetes מנוהלים ומתוחזקים על ידי Google, אבל אדמינים מקומיים מנהלים את רכיבי מישור הבקרה ב-Google Distributed Cloud.

ב-Google Distributed Cloud, רכיבי מישור הבקרה פועלים בתוך הרשת הארגונית שלכם. אפשר להגן על שרת Kubernetes API באמצעות חומות האש ומדיניות הרשת הארגונית הקיימות. אפשר גם להקצות כתובת IP פנימית לשרת ה-API ולהגביל את הגישה לכתובת.

כל התקשורת ב-Google Distributed Cloud מתבצעת בערוצי TLS, שמנוהלים על ידי שלוש רשויות אישורים (CA): ‏ etcd,‏ cluster ו-org:

  • ה-CA של etcd מאבטח את התקשורת משרת ה-API אל העותקים המשוכפלים של etcd, וגם את התעבורה בין העותקים המשוכפלים של etcd. ה-CA הזה הוא בחתימה עצמית.
  • רשות ה-CA של האשכול מאבטחת את התקשורת בין שרת ה-API לבין כל לקוחות ה-API הפנימיים של Kubernetes (kubelet, בקרי שליטה, מתזמנים). ה-CA הזה הוא בחתימה עצמית.
  • רשות ה-CA של הארגון היא רשות CA חיצונית שמשמשת להצגת Kubernetes API למשתמשים חיצוניים. ה-CA הזה נמצא בניהולכם.

במישורי בקרה של אדמינים, המפתחות מאוחסנים בצומת של מישור הבקרה. באשכולות משתמשים, המפתחות מאוחסנים כסודות של Kubernetes במישור הבקרה של האדמין. שרת ה-API מוגדר עם אישור שסופק על ידי המשתמש ונחתם על ידי רשות האישורים של הארגון. שרת ה-API משתמש ב-Server Name Indication‏ (SNI) כדי לקבוע אם להשתמש במפתח שנחתם על ידי רשות האישורים של האשכול או במפתח שנחתם על ידי רשות האישורים של הארגון.

האימות של האשכול מתבצע באמצעות אישורים וטוקנים מסוג bearer של חשבונות שירות. האדמין מבצע אימות למישור הבקרה באמצעות OIDC, או באמצעות אישור האדמין (שמשמש ליצירת שיוך תפקידים ראשוני או למטרות חירום).

החלפת האישורים מתבצעת באחת מהדרכים הבאות:

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

אבטחת הצומת

‫Google Distributed Cloud פורס את עומסי העבודה (workloads) שלכם במופעי VMware שמצורפים לאשכולות כצמתים. בקטעים הבאים מוסבר איך להשתמש בתכונות האבטחה ברמת הצומת שזמינות לכם.

Ubuntu

‫Google Distributed Cloud משתמש בגרסה מותאמת של Ubuntu כמערכת ההפעלה שעליה מריצים את רמת הבקרה והצמתים של Kubernetes. ‫Ubuntu כולל מגוון רחב של תכונות אבטחה מודרניות, וב-Google Distributed Cloud מיושמות כמה תכונות לשיפור האבטחה של אשכולות, כולל:

יש מדריכי אבטחה נוספים ל-Ubuntu, למשל:

שדרוגים של צמתים

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

אבטחת עומסי העבודה

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

הגבלת הרשאות של תהליכים במאגר Pod

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

  • משתמש או קבוצה להרצה בתורם.
  • היכולות הזמינות של Linux.
  • הסלמת הרשאות (privilege escalation).

מערכת ההפעלה של הצומת, Ubuntu, מחילה את מדיניות האבטחה של Docker AppArmor על כל הקונטיינרים שמופעלים על ידי Kubernetes. אפשר לראות את תבנית הפרופיל ב-GitHub. בין היתר, הפרופיל שולל מהקונטיינרים את היכולות הבאות:

  • כתיבה לקבצים ישירות בספרייה של מזהה תהליך (/proc/).
  • כתיבה לקבצים שלא נמצאים ב-‎ /proc/‎.
  • כתיבה לקבצים ב-‎ /proc/sys מלבד ‎ /proc/sys/kernel/shm*.
  • טעינת מערכות קבצים.

רישום ביומן ביקורת

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

כברירת מחדל, Google Distributed Cloud מתעדת פעילות אדמין. אפשר גם לרשום ביומן אירועי גישה לנתונים, בהתאם לסוגי הפעולות שאתם רוצים לבדוק.

סוכן Connect מתקשר רק עם שרת ה-API המקומי שפועל במקום, ולכל אשכול צריך להיות סט משלו של יומני ביקורת. כל הפעולות שהמשתמשים מבצעים מממשק המשתמש דרך Connect נרשמות ביומן על ידי האשכול הזה.

הצפנה

אם האשכולות ועומסי העבודה שלכם מתחברים באופן מאובטח לשירותיGoogle Cloud באמצעות Cloud VPN, אתם יכולים להשתמש ב-Cloud Key Management Service ‏(Cloud KMS) לניהול מפתחות. ‫Cloud KMS הוא שירות לניהול מפתחות שמתארח בענן ומאפשר לכם לנהל מפתחות קריפטוגרפיים לשירותים שלכם. אתם יכולים ליצור מפתחות קריפטוגרפיים מסוג AES256,‏ RSA 2048,‏ RSA 3072,‏ RSA 4096,‏ EC P256 ו-EC P384, להשתמש בהם, להחליף אותם ולהשמיד אותם. ‫Cloud KMS משולב עם ניהול זהויות והרשאות גישה (IAM) ועם יומני ביקורת של Cloud, כדי שתוכלו לנהל את ההרשאות במפתחות נפרדים ולעקוב אחרי השימוש בהם. שימוש ב-Cloud KMS כדי להגן על סודות ועל מידע רגיש אחר שאתם צריכים לאחסן. אחרת, אפשר לבחור באחת מהאפשרויות הבאות:

  • סודות של Kubernetes
  • Hashicorp Vault
  • Thales Luna network HSM
  • Google Cloud מודול אבטחה לחומרה (HSM)

סודות של Kubernetes

משאבי Secrets של Kubernetes מאחסנים נתונים רגישים, כמו סיסמאות, טוקנים של OAuth ומפתחות SSH, באשכולות שלכם. אחסון של מידע אישי רגיש ב-Secrets מאובטח יותר מאשר אחסון שלהם ב-ConfigMaps בטקסט לא מוצפן או במפרטים של Pod. השימוש ב-Secrets מאפשר לכם לשלוט באופן השימוש בנתונים רגישים, ומצמצם את הסיכון לחשיפת הנתונים למשתמשים לא מורשים.