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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • ‫NET_RAW ל-ping ו-SYS_PTRACE לניפוי באגים: Add to 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, ולכן לא ניתן לתזמן pods עם sysctls לא בטוחים. כדי להגביר את ההגנה, החל מ-11 ביולי 2023, גם לאשכולות חדשים מגרסה ‎1.27+‎ יש כלל מדיניות לאכיפת ההגדרות של securityContext ולדחיית Pods שמשתמשים ב-sysctls לא בטוחים.
סוגי נפח אחסון ב-Autopilot מותרים רק סוגי הנפחים במדיניות המוגבלת, עם התוספות הבאות: נפחי HostPath עם גישת קריאה בלבד אל /var/log לצורך ניפוי באגים, gcePersistentDisk לדיסקים קשיחים קבועים של Compute Engine ו-nfs לנפחים של מערכת קבצים ברשת.
הסלמת הרשאות (privilege escalation) ההגדרה הזו מספקת הגנה רק למאגרי תמונות שלא פועלים כ-root. סקרים בתעשייה מראים ש-76% מהקונטיינרים פועלים כ-root, ולכן Autopilot מאפשר הפעלה כ-root כדי להפעיל את רוב עומסי העבודה. ההגדרה הזו שימושית גם בהסרת הרשאות של עומסי עבודה להרשאות שאינן root, על ידי מתן אפשרות להשתמש ביכולות של מערכת הקבצים כדי לעקוף בעיות בטיפול ביכולות root ב-Kubernetes.
הרצה כמשתמש לא-root סקרים בתעשייה מראים ש-76% מהקונטיינרים פועלים כ-root, ולכן ב-Autopilot אפשר להריץ כ-root כדי להפעיל את רוב עומסי העבודה.
הרצה כמשתמש לא-root קונטיינרים יכולים להגדיר את runAsUser ל-0. סקרים בתעשייה מראים ש-76% מהקונטיינרים פועלים כבסיס, ולכן ב-Autopilot אפשר להפעיל כבסיס כדי להפעיל את רוב עומסי העבודה

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

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

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

בטבלה הבאה מתוארות חלק מהגדרות האבטחה שמוגדרות אוטומטית על ידי 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.
מאגרי תגים עם הרשאות מיוחדות אי אפשר להריץ מאגרי תגים במצב הרשאה, אלא אם הפריסה של מאגר התגים מתבצעת על ידי Cloud de Confiance שותף. קונטיינרים עם הרשאות מיוחדות יכולים לבצע שינויים בצומת הבסיסי, כמו שינוי של 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 משנה ווּבּוּקים לשינוי כדי להחריג משאבים במרחבי שמות מנוהלים, כמו 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

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

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

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

- 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, ההגבלות האלה מיושמות כדי למנוע מעומסי עבודה גישה ברמה נמוכה למכונה הווירטואלית של הצומת, וכךCloud de Confiance יכול להציע ניהול מלא של הצמתים וSLA ברמת ה-Pod.

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

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

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

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

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

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

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

אימות והרשאה

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

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

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

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

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

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

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

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