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

Autopilot

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

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

• סקירה כללית על האבטחה ב-GKE
• סקירה כללית על מצב אוטומטי ומצב רגיל

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

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

אשכול Autopilot

כל האשכול משתמש במצב Autopilot.

עומסי עבודה (workloads) של Autopilot באשכולות רגילים

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

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

שיטה מומלצת: השתמשו באשכולות Autopilot כדי לאכוף באופן מקיף את אמצעי האבטחה של Autopilot.

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

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

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

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

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

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

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

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

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

שליטה	עמידה בדרישות המדיניות הבסיסיות	עמידה בדרישות המדיניות בנושא תוכן מוגבל	מידע נוסף
HostProcess			‫Autopilot חוסם את HostProcess.
מרחבי שמות של מארחים			מצב Autopilot חוסם מרחבי שמות של מארחים. לחלק מהקונטיינרים של שותפים מאומתים מותר להשתמש במרחבי שמות של מארחים.
קונטיינרים עם הרשאות ניהול			כברירת מחדל, Autopilot חוסם קונטיינרים עם הרשאות. ב-Autopilot אפשר להשתמש בקונטיינרים בעלי הרשאות משותפים מאומתים, למטרות כמו הפעלת כלי אבטחה ומעקב.
יכולות של Linux			כברירת מחדל, עומסי עבודה ב-Autopilot יכולים לגשת רק ליכולות שצוינו בתקן Baseline Pod Security Standard. אתם יכולים להפעיל באופן ידני את היכולות הבאות: ‫NET_RAW לפינג ו-SYS_PTRACE לניפוי באגים: הוספה ל-Pod SecurityContext NET_ADMIN לרשתות שירות כמו Istio: מציינים את --workload-policies=allow-net-admin בפקודה ליצירת האשכול. בנוסף, ב-Autopilot אפשר להגדיר יכולות שהוסרו בחלק מעומסי העבודה של שותפים מאומתים.
אמצעי אחסון מסוג HostPath	תאימות חלקית	תאימות חלקית	ב-Autopilot, קונטיינרים יכולים לבקש הרשאת קריאה בלבד אל /var/log לצורך ניפוי באגים, אבל כל גישה אחרת לקריאה או לכתיבה נדחית.
HostPorts			אי אפשר להגדיר יציאות ספציפיות למארח, מה שמפחית חלק מבעיות התזמון ומונע חשיפה ישירה של שירותים לרשת, בין אם בטעות ובין אם בכוונה. אתם יכולים להגדיר ידנית הקצאה אקראית של יציאות מארח מטווח ידוע, כדי לתמוך באפליקציות רשת עם חיבור ישיר, כמו שרתי גיימינג.
AppArmor			פרופיל האבטחה docker-default של AppArmor מוחל באופן אוטומטי על מערכת הפעלה שמותאמת לקונטיינרים.
SELinux			‫SELinux לא מופעל כי AppArmor כבר מופעל. בנוסף, SELinux לא נדרש בתקני האבטחה של Pod.
סוג תושבת אחד (/proc)			ב-GKE מגרסה 1.33 ואילך, אם הערך של procMount ב-securityContext של ה-Pod מוגדר כ-Unmasked, ‏Autopilot דוחה את ה-Pod. בגרסאות שקודמות ל-1.33, ‏Autopilot מחליף באופן אוטומטי את הערך בשדה procMount ל-Default.
פרופיל seccomp			ב-Autopilot, פרופיל seccomp RuntimeDefault חל על כל עומסי העבודה. אפשר לשנות את ההגדרה הזו באופן ידני לעומסי עבודה ספציפיים, על ידי הגדרת הפרופיל ל-Unconfined במפרט של ה-Pod.
sysctls			‫GKE לא מגדיר את הדגל --allowed-unsafe-sysctls kubelet, ולכן לא ניתן לתזמן pod עם sysctl לא בטוח. כדי להוסיף שכבת הגנה, החל מ-11 ביולי 2023, לאשכולות חדשים בגרסה 1.27 ואילך יש גם כלל מדיניות לאכיפת ההגדרות של securityContext ולדחיית פודים שמשתמשים ב-sysctls לא בטוחים.
סוגי נפח אחסון			ב-Autopilot אפשר להשתמש רק בסוגי אמצעי האחסון שבמדיניות Restricted, עם התוספות הבאות: אמצעי אחסון מסוג HostPath עם גישה לקריאה בלבד אל /var/log לניפוי באגים, Persistent Disk לדיסקים קבועים של Compute Engine ו-nfs לאמצעי אחסון של מערכת קובצי רשת.
הסלמת הרשאות (privilege escalation)			ההגדרה הזו מספקת הגנה רק למאגרים שלא פועלים כ-root. מסקרים בתחום עולה ש-76% מהקונטיינרים פועלים כמשתמשי root, ולכן Autopilot מאפשר לפעול כמשתמש root כדי להפעיל את רוב עומסי העבודה. ההגדרה הזו שימושית גם כדי להסיר הרשאות מעומסי עבודה שאינם ברמה הבסיסית (root), על ידי שימוש ביכולות של מערכת הקבצים כדי לעקוף ליקויים בטיפול של Kubernetes ביכולות ברמה הבסיסית (root).
הפעלה כמשתמש שאינו משתמש בסיסי (root)			סקרים בתחום מראים ש-76% מהקונטיינרים פועלים כמשתמשי root, ולכן Autopilot מאפשר להריץ כמשתמשי root כדי להפעיל את רוב עומסי העבודה.
הפעלה כמשתמש שאינו משתמש Root			אפשר להגדיר את runAsUser ל-0 בקונטיינרים. סקרים בתחום מראים ש-76% מהקונטיינרים פועלים כמשתמשי root, ולכן Autopilot מאפשרת הרצה כמשתמשי root כדי לאפשר את רוב עומסי העבודה.

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

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

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

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

הגדרות אישיות	תיאור
אפשרויות למארחים	לא hostNetwork, כי GKE מנהל את הצמתים. הקצאה אקראית של hostPort. אין אמצעי אחסון של hostPath במצב כתיבה. אפשר להשתמש בנפחי hostPath במצב קריאה בשביל קידומות של נתיבי /var/log/. אין מרחבי שמות של מארחים.
יכולות של Linux	אפשר להשתמש ביכולות הבאות של Linux: "SETPCAP", "MKNOD", "AUDIT_WRITE", "CHOWN", "DAC_OVERRIDE", "FOWNER", "FSETID", "KILL", "SETGID", "SETUID", "NET_BIND_SERVICE", "SYS_CHROOT", "SETFCAP", "SYS_PTRACE" אתם יכולים גם להפעיל ידנית את היכולות הבאות: NET_RAW כדי לשלוח פינג: הוספה אל SecurityContext. SYS_PTRACE לניפוי באגים: הוספה ל-Pod SecurityContext. ‫NET_ADMIN עבור Service mesh כמו Istio: השתמשו ב---workload-policies=allow-net-admin כשיוצרים אשכול או מעדכנים אשכול קיים. אחרי זה, מוסיפים את היכולת ל-Pod SecurityContext. היכולת הזו מעניקה גישה רחבה לפעולות ברשת, כמו גישת כתיבה לטבלאות ניתוב ולחומות אש. תוקף יכול להשתמש בגישה הזו כדי לבצע התקפות של העברת הרשאות ברמות גבוהות יותר באשכול. לפרטים נוספים, אפשר לעיין בדף המדריך של CAP_NET_ADMIN.
קונטיינרים עם הרשאות ניהול	אי אפשר להריץ קונטיינרים במצב הרשאות ניהול, אלא אם הקונטיינר נפרס על ידי Google Cloud שותף. קונטיינרים עם הרשאות יכולים לבצע שינויים בצומת הבסיסי, כמו שינוי ה-kubelet. הגישה הזו עלולה להגביר את ההשפעה של Pod שנפגע.
מרחבי שמות שמנוהלים על ידי GKE	כאמצעי אבטחה, Autopilot לא מאפשר לפרוס עומסי עבודה במרחבי שמות שמנוהלים על ידי GKE, כמו kube-system.
בידוד קונטיינרים	ב-Autopilot נאכפות ההגבלות הבאות על קונטיינרים כדי לצמצם את ההשפעה של נקודות חולשה שמאפשרות פריצה בקונטיינר. יכולות Linux ואבטחת ליבה מצב Autopilot מחיל את RuntimeDefault פרופיל seccomp על כל ה-Pods באשכול, אלא אם ה-Pods משתמשים ב-GKE Sandbox. ‫GKE Sandbox אוכף בידוד של המארח ומתעלם מכללי seccomp שצוינו במניפסט של ה-Pod. ארגז החול נחשב לגבול האבטחה של Pods ב-GKE Sandbox. ב-Autopilot, היכולת CAP_NET_RAW של Linux מושמטת מכל הקונטיינרים. ההרשאה הזו לא נמצאת בשימוש לעיתים קרובות, והיא הייתה הנושא של כמה נקודות חולשה שמאפשרות בריחה. יכול להיות שהפקודה ping תיכשל בתוך הקונטיינרים כי היכולת הזו הוסרה. כדי להפעיל מחדש את היכולת הזו באופן ידני, צריך להגדיר אותה ב-SecurityContext של ה-Pod. ב-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,‏ 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.
שינוי של רכיבי webhook דינמיים לאישור	רק באשכולות Autopilot, ‏GKE משנה את ה-webhooks לשינוי כדי למנוע יירוט של משאבים במרחבי שמות מנוהלים, כמו kube-system. בקרת הגישה מתבצעת במישור הבקרה של האשכול, ולכן המגבלה הזו לא נאכפת באשכולות Standard, גם כשעומסי העבודה משתמשים ב-ComputeClass של Autopilot. בנוסף, Autopilot דוחה תגובות לפעולות webhook שמציינות אחד או יותר מהמשאבים הבאים, וכל משאבי המשנה של המשאבים האלה. - 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 אי אפשר להשתמש בתו הכללי לחיפוש כוכבית (*) למשאבים או לקבוצות כדי לעקוף את ההגבלה הזו.
בקשות חתימה על אישורים	אפשר ליצור CertificateSigningRequests ב-Autopilot כדי ליצור אישורים שחתומים על ידי רשות האישורים של האשכול. כדי למנוע הפרעה לרכיבי המערכת, אשכולות Autopilot דוחים בקשות CertificateSigningRequest של זהויות מוכרות עם הרשאות, כמו קבוצות מערכת, סוכני מערכת או סוכני שירות של IAM שמנוהלים על ידי Google. המגבלה הזו לא חלה על אשכולות רגילים, שמאפשרים ליצור CertificateSigningRequests לזהויות ידועות עם הרשאות.
אמצעי האבטחה של GKE	באשכולות Autopilot מופעלים עבורכם אמצעי האבטחה המומלצים של GKE. לרשימה של אמצעי אבטחה מופעלים ואופציונליים, עיין ב-אמצעי אבטחה ב-Autopilot.
מערכת ההפעלה של הצומת	ב-Autopilot נעשה שימוש במערכת הפעלה שמותאמת לקונטיינרים עם containerd כמערכת ההפעלה של הצומת. מערכת ההפעלה שמותאמת לקונטיינרים נוצרה על ידי Google והיא מנוהלת על ידה.
שדרוגי גרסאות של GKE	אשכולות Autopilot רשומים לערוץ הפצה של GKE בזמן היצירה, והשדרוגים האוטומטיים תמיד מופעלים. עם הזמן, Google משדרגת באופן אוטומטי את מישור הבקרה והצמתים לגרסה המאושרת האחרונה בערוץ ההפצה.

גבולות אבטחה ב-Autopilot

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

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

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

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

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

המלצות אבטחה לפי תרחיש לדוגמה

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

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

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

אימות והרשאה

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

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

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

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

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

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

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

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

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

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