אמצעי אבטחה ב-GKE Autopilot

בדף הזה מתוארות תכונות האבטחה, ההגדרות וההגדרות הקבועות במצב Autopilot של Google Kubernetes Engine ‏ (GKE). המידע הזה מיועד למומחי אבטחה שרוצים להבין את מגבלות האבטחה ש-Google מטילה במצב Autopilot, ואת תכונות האבטחה שזמינות לשימוש ב-Autopilot. מידע נוסף על תפקידים נפוצים ועל משימות לדוגמה שאנחנו מתייחסים אליהן בתוכן זמין במאמר תפקידים נפוצים של משתמשים ב-GKE ומשימות. Google Cloud

לפני שקוראים את הדף הזה, כדאי להכיר את המושגים הבאים:

הסברים על המונחים

ב-GKE, אפשר להשתמש ב-Autopilot על ידי יצירת אשכול Autopilot או על ידי הפעלת עומס עבודה ב-ComputeClass של Autopilot בכל אשכול Standard. בדף הזה מתוארים אמצעי האבטחה של Autopilot בשני המצבים האלה, באמצעות המינוח הבא:

אשכול טייס אוטומטי
כל האשכול משתמש במצב Autopilot.
עומסי עבודה ב-Autopilot באשכולות רגילים
האשכול משתמש במצב Standard, ואתם מריצים עומסי עבודה ספציפיים במצב Autopilot באמצעות ComputeClasses.

אמצעי אבטחה ב-Autopilot

במצב Autopilot,‏ GKE מחיל כברירת מחדל שיטות מומלצות והגדרות שונות לאבטחה, כולל רבות מההמלצות שבסקירה הכללית בנושא אבטחה ובמאמר שיפור האבטחה של האשכול.

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

אכיפה של תקני אבטחה של Kubernetes Pod

בפרויקט Kubernetes יש קבוצה של הנחיות אבטחה שנקראות Pod Security Standards (תקני אבטחה של Pod). ההנחיות האלה מגדירות את המדיניות הבאה:

  • פריבילגיה: אין הגבלות על הגישה. לא נעשה בו שימוש ב-Autopilot.
  • Baseline: מונע נתיבים ידועים להסלמת הרשאות. מאפשר להריץ את רוב עומסי העבודה בלי שינויים משמעותיים.
  • מוגבל: רמת האבטחה הגבוהה ביותר. נדרשים שינויים משמעותיים ברוב עומסי העבודה.

במצב Autopilot, ‏ GKE אוכף את ההגבלות על אבטחת ה-Pod באמצעות בקרי הגישה של Kubernetes. מדיניות ברירת המחדל של Autopilot Pod כוללת את כל ההמלצות ברמת הבסיס של התקנים לאבטחת Pod, עם כמה שינויים לשיפור השימושיות. בנוסף, מדיניות ברירת המחדל של הגישה כוללת אילוצים רבים מהרמה המוגבלת של תקני האבטחה של Pod, אבל היא לא כוללת הגבלות שימנעו מרוב עומסי העבודה שלכם לפעול.

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

בטבלה הבאה מוסבר איך אמצעי הבקרה במדיניות ברירת המחדל של Autopilot Admission משתווים לאמצעי הבקרה ברמות Baseline ו-Restricted של תקני אבטחת ה-Pod. מידע נוסף על כל אמצעי בקרה בטבלה הזו זמין בערך המתאים בתקני אבטחת הפודים.

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

שליטה עמידה בדרישות המדיניות של קבוצת הבסיס עמידה בדרישות המדיניות המוגבלת מידע נוסף
HostProcess טייס אוטומטי חוסם את HostProcess.
מרחבי שמות של מארחים התכונה Autopilot חוסמת מרחבי שמות של מארחים. חלק ממסגרות התגים של שותפים מאומתים מורשות להשתמש במרחבי שמות של מארחים.
מאגרי תגים עם הרשאות מיוחדות כברירת מחדל, Autopilot חוסם קונטיינרים עם הרשאות. ‫Autopilot מאפשר שימוש בקונטיינרים עם הרשאות מספקים מאומתים למטרות כמו הפעלת כלים לניטור ואבטחה.
יכולות של Linux

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

אתם יכולים להפעיל באופן ידני את היכולות הבאות:

  • ‫NET_RAW ל-ping ו-SYS_PTRACE לניפוי באגים: מוסיפים ל-Pod SecurityContext
  • ‫NET_ADMIN ל-Service mesh כמו Istio: מציינים --workload-policies=allow-net-admin בפקודה ליצירת האשכול.

בנוסף, טייס אוטומטי מאפשר לחלק מעומסי העבודה של שותפים מאומתים להגדיר יכולות שהוסרו.
נפחי אחסון מסוג HostPath עומד בדרישות באופן חלקי עומד בדרישות באופן חלקי ‫Autopilot מאפשר למאגרי תגים לבקש גישה לקריאה בלבד אל /var/log לצורך ניפוי באגים, אבל הוא דוחה כל גישה אחרת לקריאה או לכתיבה.
HostPorts אסור להגדיר יציאות ספציפיות למארח, מה שמצמצם חלק מבעיות התזמון ומונע חשיפה ישירה של שירותים לרשת בטעות או בכוונה. אתם יכולים להגדיר ידנית הקצאה אקראית של יציאות מארח מתוך טווח ידוע כדי לתמוך באפליקציות רשת עם חיבור ישיר, כמו שרתי משחקים.
AppArmor פרופיל האבטחה של Docker שמוגדר כברירת מחדל ב-AppArmor מוחל באופן אוטומטי על מערכת הפעלה שמותאמת לקונטיינרים.
SELinux ה-SELinux לא מוחל כי AppArmor כבר מוחל. בנוסף, השימוש ב-SELinux לא חובה בתקני אבטחת ה-Pod.
סוג התושבת /proc ב-GKE מגרסה 1.33 ואילך, אם ב-securityContext של ה-Pod מוגדר procMount כ-Unmasked, מצב Autopilot דוחה את ה-Pod. בגרסאות מוקדמות יותר מגרסה 1.33, הטייס האוטומטי מחליף אוטומטית את הערך בשדה procMount בערך Default.
פרופיל seccomp ב-Autopilot, פרופיל RuntimeDefault seccomp מוחל על כל עומסי העבודה. אפשר לשנות את ההגדרה הזו באופן ידני עבור עומסי עבודה ספציפיים על ידי הגדרת הפרופיל ל-Unconfined במפרט של ה-Pod.
sysctls ‫GKE לא מגדיר את הדגל ‎--allowed-unsafe-sysctls kubelet, ולכן לא ניתן לתזמן פודים עם sysctl לא בטוחים. כדי להגביר את ההגנה, החל מ-11 ביולי 2023, גם לאשכולות חדשים מגרסה 1.27 ואילך יש כלל מדיניות לאכיפת ההגדרות של securityContext ולדחיית Pods שמשתמשים ב-sysctls לא בטוחים.
סוגי נפח אחסון ב-Autopilot מותרים רק סוגי הנפחים במדיניות המוגבלת, עם התוספות הבאות: נפחי HostPath עם גישת קריאה בלבד אל /var/log לצורך ניפוי באגים, gcePersistentDisk לדיסקים קשיחים קבועים של Compute Engine ו-nfs לנפחים של מערכת קבצים ברשת.
הסלמת הרשאות (privilege escalation) ההגדרה הזו מספקת הגנה רק למאגרי תמונות שלא פועלים כ-root. סקרים בתעשייה מראים ש-76% מהקונטיינרים פועלים כבסיס, ולכן Autopilot מאפשר הפעלה כבסיס כדי להפעיל את רוב עומסי העבודה. ההגדרה הזו שימושית גם כרגע בהסרת הרשאות של עומסי עבודה ללא הרשאות root, כי היא מאפשרת להשתמש ביכולות של מערכת הקבצים כדי לעקוף בעיות בטיפול בהרשאות root ב-Kubernetes.
הפעלה כמשתמש לא-ראשי סקרים בתעשייה מראים ש-76% מהקונטיינרים פועלים כ-root, ולכן ב-Autopilot אפשר להפעיל אותם כ-root כדי להפעיל את רוב עומסי העבודה.
הפעלה כמשתמש לא-root קונטיינרים יכולים להגדיר את runAsUser ל-0. סקרים בתעשייה מראים ש-76% מהקונטיינרים פועלים כבסיס, ולכן ב-Autopilot אפשר להפעיל כבסיס כדי להפעיל את רוב עומסי העבודה

הגדרות אבטחה מובנות

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

בטבלה הבאה מתוארות חלק מהגדרות האבטחה שמוגדרות אוטומטית על ידי Autopilot:

הגדרות אישיות תיאור
אפשרויות למארחים
יכולות של Linux

אפשר להשתמש ביכולות הבאות של Linux:

"SETPCAP", "MKNOD", "AUDIT_WRITE", "CHOWN", "DAC_OVERRIDE", "FOWNER", "FSETID", "KILL", "SETGID", "SETUID", "NET_BIND_SERVICE", "SYS_CHROOT", "SETFCAP", "SYS_PTRACE"

אפשר גם להפעיל באופן ידני את היכולות הבאות:

  • NET_RAW כדי לשלוח פינג: מוסיפים את המשתמש ל-Pod SecurityContext.
  • SYS_PTRACE לניפוי באגים: הוספה ל-Pod SecurityContext.
  • ‫NET_ADMIN ל-Service mesh כמו Istio: משתמשים ב---workload-policies=allow-net-admin כשיוצרים אשכול או מעדכנים אשכול קיים. לאחר מכן, מוסיפים את היכולת ל-Pod‏ SecurityContext.
מאגרי תגים עם הרשאות מיוחדות אי אפשר להריץ מאגרי תגים במצב הרשאה אלא אם הפריסה של מאגר התגים מתבצעת על ידי Google Cloud שותף. קונטיינרים עם הרשאות יכולים לבצע שינויים בצומת הבסיסי, כמו שינוי של kubelet. הגישה הזו יכולה להגדיל את ההשפעה של פריצה ל-Pod.
מרחבי שמות בניהול GKE כאמצעי אבטחה, ב-Autopilot אי אפשר לפרוס עומסי עבודה במרחבי שמות שמנוהלים על ידי GKE, כמו kube-system.
בידוד קונטיינרים

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

יכולות של Linux ואבטחת ליבה

  • ב-Autopilot, הפרופיל RuntimeDefault seccomp מוחל על כל ה-Pods באשכול, אלא אם ה-Pods משתמשים ב-GKE Sandbox. ‫GKE Sandbox אוכף בידוד של המארח ומתעלם מכללי seccomp שצוינו במניפסט של ה-Pod. ארגז החול נחשב לגבול האבטחה של GKE Sandbox Pods.
  • התכונה Autopilot משמיטה את היכולת CAP_NET_RAW Linux לכל המאגרים. מעטים משתמשים בהרשאה הזו, והיא הייתה נושא לכמה פגיעויות שמאפשרות יציאה מבידוד. יכול להיות שהפקודה ping תיכשל בתוך הקונטיינרים כי היכולת הזו הוסרה. אפשר להפעיל מחדש את היכולת הזו באופן ידני על ידי הגדרה שלה ב-Pod SecurityContext.
  • התכונה Autopilot משמיטה את היכולת CAP_NET_ADMIN Linux לכל המאגרים. כדי להפעיל מחדש את היכולת הזו, צריך לציין את הדגל --workload-policies=allow-net-admin בפקודה ליצירה או לעדכון של האשכול. ‫NET_ADMIN נדרש על ידי עומסי עבודה מסוימים, כמו Istio.
  • אשכולות Autopilot מאפשרים להשתמש באיחוד זהויות של עומסי עבודה ל-GKE, שמונע גישת Pod למטא-נתונים רגישים בצומת.
  • ‫Autopilot חוסם שירותי Kubernetes שמגדירים את השדה spec.externalIPs כדי להגן מפני CVE-2020-8554.

  • אפשר להשתמש ב-Autopilot רק עם סוגי הכרכים הבאים:

    "configMap", "csi", "downwardAPI", "emptyDir", "gcePersistentDisk", "nfs", "persistentVolumeClaim", "projected", "secret"

    סוגים אחרים של אמצעי אחסון חסומים כי הם דורשים הרשאות צומת. כרכים של HostPath חסומים כברירת מחדל, אבל קונטיינרים יכולים לבקש גישת קריאה בלבד לנתיבי /var/log לצורך ניפוי באגים.
אכיפת מדיניות אבטחה ברמת ה-Pod ‫Autopilot תומך במנגנוני אכיפה של מדיניות אבטחה ברמת ה-Pod, כמו PodSecurity admission controller,‏ Gatekeeper או Policy Controller. עם זאת, יכול להיות שלא תצטרכו להשתמש באף אחת מהאפשרויות האלה אם הגדרות האבטחה המובנות שמתוארות בדף הזה כבר עונות על הדרישות שלכם.
חיבור SSH לצמתים

‫Autopilot חוסם גישת SSH לצמתים. ‫GKE מטפל בכל ההיבטים התפעוליים של הצמתים, כולל תקינות הצמתים וכל רכיבי Kubernetes שפועלים בצמתים.

עדיין אפשר להתחבר מרחוק למאגרי הנתונים הפעילים באמצעות הפונקציונליות של Kubernetes exec כדי להריץ פקודות במאגרי הנתונים לצורך ניפוי באגים, כולל התחברות למעטפת אינטראקטיבית, למשל באמצעות kubectl exec -it deploy/YOUR_DEPLOYMENT -- sh.
התחברות זמנית כמשתמש אחר

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

בקטרי Autopilot בלבד, אי אפשר להתחזות למשתמשי מערכת ולקבוצות (כמו המשתמש kube-apiserver והקבוצה system:masters). מכיוון שההגבלות על התחזות למשתמש מתרחשות במישור הבקרה, האילוץ הזה לא נאכף באשכולות Standard, גם כשעומסי העבודה משתמשים ב-ComputeClass של Autopilot. אנחנו ממליצים מאוד לא להתחזות למשתמשי מערכת ולקבוצות ב-GKE.
שינוי של webhooks דינמיים של בקרת כניסה

באשכולות Autopilot בלבד, ‏ GKE משנה את ה-webhooks לשינוי כדי להחריג משאבים במרחבי שמות מנוהלים, כמו kube-system, מיירוט. מכיוון שבקרת הכניסה מתבצעת ברמת הבקרה של האשכול, האילוץ הזה לא נאכף באשכולות Standard, גם כשעומסי העבודה משתמשים ב-ComputeClass של Autopilot.

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

- group: ""
  resource: nodes
- group: ""
  resource: persistentVolumes
- group: certificates.k8s.io
  resource: certificatesigningrequests
- group: authentication.k8s.io
  resource: tokenreviews

אי אפשר להשתמש בתו הכללי * למשאבים או לקבוצות כדי לעקוף את ההגבלה הזו.
ValidatingAdmissionPolicies

באשכולות Autopilot בלבד, ‏ GKE משנה אובייקטים של ValidatingAdmissionPolicy כדי להחריג משאבים במרחבי שמות מנוהלים, כמו kube-system, מיירוט. מכיוון שבקרת הכניסה מתבצעת במישור הבקרה של האשכול, האילוץ הזה לא נאכף באשכולות Standard, גם כשעומסי עבודה משתמשים ב-ComputeClass של Autopilot.

בנוסף, Autopilot דוחה אובייקטים של ValidatingAdmissionPolicy שמציינים אחד או יותר מהמשאבים הבאים, וכל משאב משני של המשאבים האלה.

- group: ""
  resource: nodes
- group: ""
  resource: persistentVolumes
- group: certificates.k8s.io
  resource: certificatesigningrequests
- group: authentication.k8s.io
  resource: tokenreviews

אי אפשר להשתמש בתו הכללי * למשאבים או לקבוצות כדי לעקוף את ההגבלה הזו.
בקשות לחתימה על אישורים אתם יכולים ליצור בקשות לחתימת אישורים ב-Autopilot כדי ליצור אישורים שנחתמים על ידי רשות האישורים של האשכול. כדי למנוע הפרעה לרכיבי המערכת, אשכולות Autopilot דוחים בקשות לחתימת אישורים (CertificateSigningRequests) עבור זהויות מוכרות עם הרשאות מיוחדות, כמו קבוצות מערכת, סוכני מערכת או סוכני שירות IAM בניהול Google. המגבלה הזו לא חלה על אשכולות רגילים, שמאפשרים ליצור בקשות לחתימת אישורים (CertificateSigningRequests) עבור זהויות מוכרות עם הרשאות.
תכונות האבטחה של GKE באשכולות Autopilot מופעלות בשבילכם תכונות האבטחה המומלצות של GKE. רשימה של תכונות אבטחה מופעלות ואופציונליות זמינה במאמר תכונות אבטחה ב-Autopilot.
מערכת ההפעלה של הצומת ב-Autopilot נעשה שימוש במערכת הפעלה שמותאמת לקונטיינרים עם containerd כמערכת ההפעלה של הצומת. מערכת ההפעלה שמותאמת לקונטיינרים נוצרת ומנוהלת על ידי Google.
שדרוגים של גרסאות GKE אשכולות Autopilot נרשמים לערוץ הפצה של GKE כשהם נוצרים, והשדרוגים האוטומטיים תמיד מופעלים. מערכת Google משדרגת באופן אוטומטי את רמת הבקרה והצמתים לגרסה המוסמכת העדכנית בערוץ ההפצה לאורך זמן.

גבולות אבטחה בטייס אוטומטי

מצב Autopilot מספק גישה ל-Kubernetes API, אבל מסיר הרשאות לשימוש בתכונות מסוימות של Kubernetes עם הרשאות גבוהות, כמו Pods עם הרשאות. המטרה היא להגביל את היכולת לגשת למכונה הווירטואלית (VM) של הצומת, לשנות אותה או לשלוט בה ישירות. ב-Autopilot, ההגבלות האלה מיושמות כדי למנוע מעומסי עבודה גישה ברמה נמוכה למכונה הווירטואלית של הצומת, וכךGoogle Cloud יכול להציע ניהול מלא של הצמתים והסכם רמת שירות (SLA) ברמת ה-Pod.

המטרה שלנו היא למנוע גישה לא מכוונת למכונת ה-VM של הצומת. אנחנו מקבלים דיווחים על כך דרך תוכנית Google לתגמול על גילוי פגיעויות (VRP), וצוות התגמול של Google VRP יחליט אם לתגמל על הדיווחים.

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

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

המלצות אבטחה על סמך תרחיש לדוגמה

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

תכנון אבטחת האשכול

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

אימות והרשאה

אחרי שמגדירים את אשכולות Autopilot, יכול להיות שיהיה צורך לאמת את המשתמשים והאפליקציות כדי להשתמש במשאבים כמו Kubernetes API או Google Cloud APIs.

תרחיש לדוגמה משאבים
אימות משתמשים או אפליקציות לשרת API של אשכול
  • מידע על אימות משתמשים זמין במאמר אימות משתמשים.
  • כדי לאמת אפליקציות, אפשר לקרוא את המאמר אימות אפליקציות, שכולל שלבים לאימות מאפליקציות באותו אשכול, בסביבות אחרות של Google Cloud או בסביבות חיצוניות.
אימות אפליקציות ל-APIs ולשירותים של Google Cloud באשכולות Autopilot אפשר להשתמש באיחוד שירותי אימות הזהות של עומסי עבודה ב-GKE כדי לאמת את עומסי העבודה בצורה מאובטחת ל- Google Cloud APIs. לשם כך, צריך להגדיר חשבונות שירות של Kubernetes כך שיפעלו כחשבונות שירות של IAM. הוראות זמינות במאמר הגדרת אפליקציות לשימוש באיחוד שירותי אימות הזהות של עומסי עבודה ב-GKE.
אישור פעולות ברמת הפרויקט כדי לאשר פעולות בכל האשכולות ברמת הפרויקט, משתמשים ב-IAM. אתם יכולים להעניק או לדחות גישה למשאבי API ספציפיים של GKE ו-Kubernetes באמצעות תפקידים והרשאות ב-IAM. הוראות מפורטות זמינות במאמר יצירת מדיניות IAM.
אישור פעולות ברמת האשכול כדי לאשר פעולות במשאבי Kubernetes API באשכולות ספציפיים, צריך להשתמש במנגנון המובנה של בקרת גישה מבוססת-תפקידים (RBAC) ב-Kubernetes. הוראות מפורטות במאמר בנושא הרשאת פעולות באשכולות באמצעות RBAC.
אישור פעולות ברמת הארגון אתם יכולים להשתמש ב Google Cloud Organization Policy Service כדי לאכוף אילוצים על פעולות ספציפיות במשאבי GKE בארגון Google Cloud. הוראות מפורטות זמינות במאמר הגבלת פעולות במשאבי GKE באמצעות כללי מדיניות ארגוניים בהתאמה אישית.

הקשחת אשכולות ועומסי עבודה

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

תרחיש לדוגמה משאבים
הגבלת הגישה הציבורית לנקודת הקצה של האשכול מגדירים את בידוד הרשת של אשכולות Autopilot ומשביתים את נקודת הקצה החיצונית של מישור הבקרה של האשכול. הוראות מפורטות מופיעות במאמר הגדרת הגישה למישור הבקרה.
הגבלת הגישה לאשכול לרשתות ספציפיות אפשר להשתמש ברשתות מורשות של מישור הבקרה כדי לציין טווחי כתובות IP שיכולים לגשת לאשכול.
שמירת מידע רגיש מחוץ לאשכול אחסון מידע אישי רגיש אצל ספק שירותי אחסון חיצוני מוצפן עם ניהול גרסאות הוא דרישת תאימות נפוצה ושיטה מומלצת. אפשר להשתמש ב-Secret Manager כדי לאחסן את הנתונים ולגשת אליהם מאשכולות Autopilot באמצעות איחוד שירותי אימות הזהות של עומסי עבודה ב-GKE. הוראות מפורטות זמינות במאמר גישה לסודות שמאוחסנים מחוץ לאשכולות GKE באמצעות איחוד שירותי אימות הזהות של עומסי עבודה ל-GKE.
אימות של קובצי אימג' של קונטיינרים לפני פריסה באשכול אתם יכולים להשתמש ב-Binary Authorization כדי לבדוק את השלמות של קובצי האימג' של הקונטיינרים שאליהם יש הפניה במניפסטים של ה-Pod בזמן הפריסה. הוראות מפורטות במאמר בנושא אימות קובצי אימג' של קונטיינרים בזמן הפריסה באמצעות Binary Authorization.

מעקב אחרי מצב האבטחה

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

  • כדי לבדוק את עומסי העבודה ולזהות בעיות כמו תצורות אבטחה בעייתיות או נקודות חולשה בחבילות של מערכת ההפעלה של הקונטיינרים, ולקבל מידע שימושי על צעדים לצמצום הסיכונים, אפשר לרשום את האשכולות בלוח הבקרה של GKE Security Posture.
  • קבלת התראות על עלוני אבטחה חדשים ועל אירועי שדרוג באמצעות התראות על אשכולות.
  • אפשר לעקוב אחרי האשכולות באמצעות לוח הבקרה של GKE ב-Cloud Monitoring או באמצעות הכרטיסייה Observability ב-GKE.
  • במאמר הזה מוסבר איך לצפות ביומני הביקורת של GKE ב-Cloud Logging ואיך לנהל אותם.

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