אבטחה

בדף הזה מוסבר על תכונות האבטחה שכלולות ב-GKE ב-AWS, כולל כל שכבה בתשתית שלו, ואיך אפשר להגדיר את תכונות האבטחה בהתאם לצרכים שלכם.

סקירה כללית

‫GKE ב-AWS מציע כמה תכונות שיעזרו לכם לאבטח את עומסי העבודה, כולל התוכן של קובץ אימג' של קונטיינר, זמן הריצה של הקונטיינר, רשת האשכול והגישה לשרת ה-API של האשכול.

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

אחריות משותפת

כשמשתמשים ב-GKE ב-AWS, מסכימים לקחת על עצמכם אחריות מסוימת על האשכולות. מידע נוסף זמין במאמר חלוקת אחריות באשכולות GKE.

אימות והרשאה

אפשר לבצע אימות מול אשכול משתמשים של GKE ב-AWS באחת מהשיטות הבאות:

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

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

הצפנה

כברירת מחדל, ב-GKE on AWS מתבצעת הצפנה של נתונים ב-etcd במנוחה, נפחי EBS, סודות של Kubernetes ורכיבי מישור הבקרה באמצעות AWS Key Management Service‏ (KMS).

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

סודות של Kubernetes

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

Hashicorp Vault

‫GKE ב-AWS יכול להשתמש ב-Hashicorp Vault כדי לאבטח סודות באשכולות המשתמשים. מידע נוסף זמין במאמר שימוש ב-HashiCorp Vault ב-GKE ב-AWS.

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

רכיבי מישור הבקרה כוללים את שירות הניהול, את שרת ה-API של Kubernetes, את המתזמן, את הבקרים ואת מסד הנתונים etcd של אשכול המשתמשים. ב-GKE ב-AWS, אדמינים מקומיים מנהלים את הרכיבים של מישור הבקרה.

ב-GKE ב-AWS, רכיבי מישור הבקרה פועלים ב-AWS. אתם יכולים להגן על שרת ה-API של GKE ב-AWS באמצעות קבוצות אבטחה של AWS ורשימות ACL של רשת.

כל התקשורת ב-GKE ב-AWS מתבצעת דרך ערוצי Transport Layer Security‏ (TLS) הכפופים לרשויות האישורים (CA) הבאות:

  • ה-CA של etcd מאבטח את התקשורת משרת ה-API אל העותקים המשוכפלים של etcd, וגם את התעבורה בין העותקים המשוכפלים של etcd. ה-CA הזה הוא בחתימה עצמית.
  • רשות ה-CA של אשכול המשתמשים מאבטחת את התקשורת בין שרת ה-API לבין כל לקוחות ה-API הפנימיים של Kubernetes (kubelets, controllers, schedulers). רשות האישורים הזו מוצפנת באמצעות KMS.
  • רשות האישורים של שירות הניהול מוצפנת באמצעות AWS KMS. הוא נוצר כשמריצים את הפקודה anthos-gke init ונשמר בסביבת העבודה של Terraform. כשמשתמשים ב-terraform apply כדי ליצור את שירות הניהול, מפתח ה-CA מועבר כנתוני משתמש ב-AWS EC2 ומפוענח על ידי AWS KMS כשהאשכול מופעל.

מפתחות של רמת הבקרה של שירות הניהול מאוחסנים בצמתים של רמת הבקרה. במקרה של אשכולות משתמשים, המפתחות נשמרים כסודות של Kubernetes במישור הבקרה של שירות הניהול.

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

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

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

אבטחת הצומת

‫GKE ב-AWS פורס את עומסי העבודה במאגרי צמתים של מופעי AWS EC2. בקטעים הבאים מוסבר איך להשתמש בתכונות האבטחה ברמת הצומת ב-GKE ב-AWS.

Ubuntu

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

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

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

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

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

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

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

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

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

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

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

המאמרים הבאים