.gif)
.jpg)
אם אתם רוצים לדאוג לאבטחה מקסימלית בסביבת תפעול הקוברנטיס שלכם, אתם צריכים לבנות אותו על יסודות מוצקים - והבנצ'מארק של The Center for Internet Security (CIS) יאפשר לכם לעשות זאת עם סט של הפרקטיקות הטובות ביותר, עימו תוכלו לבנות סביבת תפעול העומדת גם בצרכי הלקוחות וגם בצרכי הרגולטור.
הגרסאות האחרונות נותנות מענה לכל גרסאות הקוברנטיס. הבנצ'מארק הוא בעצם סדרה של המלצות, והוא מתנהל לפי גרסת ה-upstream של קוברנטיס (אם אתם משתמשים בהפצות מנוהלות כמו Google Kubernetes Engine [GKE], חלק מההמלצות יהיו לא רלוונטיות – לחצו כאן לגרסא מותאמת). במאמר זה נרחיב על חלק מהפיצ'רים אשר תוכלו למצוא בגרסאת הבנצ'מארק העדכנית.
צוללים לעומק
לבנצ'מארק יש מבנה שונה מזה של הגרסא האחרונה. אם בגרסאות הישנות, הגדרות המאסטר וה-worker node היו ב-high level, הרי שהגרסאות החדשות מפרידות את הבקרות לפי הרכיבים אליהם הם מתייחסים: רכיבי רמת הבקרה, etcd, הגדרת רמת הבקרה, worker nodes ו-worker policies. כך תוכלו לבצע שינויים להפצה מסוימת, במקום לנסות לשלוט במספר רכיבים במקביל או לנסות לשנות משהו שלא נמצא בתחום האחריות שלכם.
בכל הנוגע לבקרות ספציפיות, תוכלו לראות המלצות נוספות עבור:
• ניהול סודי: ההמלצות החדשות כוללות מזעור הגישה לסודות (5.1.2). מומלץ להשתמש בהם כקבצים על פני שימוש כמשתנים סביבתיים (5.4.1), ומומלץ לשקול אחסון חיצוני עבורם.
• תיעוד ביקורות: בנוסף להמלצה הקיימת בכל הנוגע לווידוא ההגדרות הרלוונטיות ושמירה על פעילות תקינה באמצעות ה-audit log flags ברמת הבקרה. בנוסף, ישנן המלצות נוספות שיוודאו שמדיניות הביקורות שתיווצר תהיה מינימלית (3.2.1), והיא גם תוודא שמדיניות זו תיתן מענה עבור חששות אבטחה מהותיים.
• מניעה של גישה שאינה נחוצה על ידי נעילות הרשאות בקוברנטיס, זאת לפי העקרון של מינימום פריווילגיות – עם דגש על מזעור ה-wildcard use ב-Roles ו-ClusterRoles (5.1.3).
גרסת ה-GKE
כפי שצוין לעיל, הבנצ'מארק לא תומך בהפצות מנוהלות של קוברנטיס, ולכן נוצרה גרסת בת, אשר הסירה חלק מהפיצ'רים שלא ניתן להגדיר או לנהל על ידי המשתמש, ביחד עם בקרות נוספות שהינן ספציפיות לענן של גוגל, וגם נחשבות למומלצות עבור ה-Clusters שלכם (לדוגמא) – מה שיוצר גרסא עם סט בקרות יחיד שנועד לתת לכם את פרקטיקת האבטחה האפקטיבית ביותר ב-GKE.
ההמלצות מתחלקות לשתי קבוצות: המלצות ברמה 1 נועדו להיות רלוונטיות עבור רוב תרחישי השימוש, ומומלץ ליישם אותן בהקדם (לדוגמא: הפעלה של Stackdriver Kubernetes Logging and Monitoring). המלצות ברמה 2 שמות יותר דגש על האבטחה, אך הן לא בהכרח רלוונטיות לכל סביבת עבודה. לכן, מומלץ להטמיע את ההמלצות הללו בזהירות בכדי להימנע מקונפליקטים בסביבות עבודה מורכבות. לדוגמא, המלצות אלו יכולות להיות מתאימות עבור עומסי עבודה מסוג multi-tenant יותר מאשר כאלו של single tenant – כמו למשל ההמלצה להשתמש ב-GKE Sandbox בכדי להריץ עומסי עבודה שאינם אמינים.
הצגת ההמלצות משתמשת בממשק פשוט המאפשר לכם לבחון מתודות אוטומטיות בקלות (כמו למשל API call או ה-gcloud CLI), ולכל הגדרה יש ערך שניתן להעריך בפשטות. לדוגמא, וידוא שה-node auto-upgrade פועל. המלצות שאינן מבוססות אוטומציה או כאלו שדורשות הטמעה ספציפית לסביבת העבודה שלכם יוצגו כ-Not Scored. לדוגמא – שימוש בחוקי ה-firewall בכדי להגביל כניסה ותעבורה ל-nodes שלכם, או שימוש בפיצ'ר בטא שאולי לא יהיה כדאי לשימוש ב-Production.
אם אתם רוצים להציע המלצות חדשות או לשנות קיימות, צרו קשר כאן.
הפעלה ובחינה של ה-CIS Benchmarks
ישנם בנצ'מארקים שהינם רלוונטיים ל-GKE, אך יש גם כלים זמינים שיעזרו לכם לבחון האם אכן עובדים לפי ההמלצות. כלי טוב שמתאים ל-CIS Kubernetes Benchmark הוא kube-bench שיבחן את ההגדרה הקיימת שלכם. עבור גרסת ה-GKE, אתם יכולים להשתמש במוצר הבא, אשר מטמיע את עצמו אל ה-Security Command Center, ומכיל כלי בחינה עבור CIS, GCP ו-GKE. על ידי הפעלת ה-Security Health Analytics, אתם תוכלו לגלות, לבחון ולתקן כל הגדרות Cluster שלא עומדות ביעדי המצוינות (לפי הבנצ'מארק המופיע ב-Vulnerabilities Dashboard ב-Security Command Center).
תיעוד הגדרות של GKE ברמת הבקרה
הבנצ'מארק החדש אמור לעזור לכם להטמיע ולהשתמש בפרקטיקות אבטחת הקוברנטיס הטובות ביותר, וכאן תוכלו לקרוא על רכיבים שטרם קיבלו מענה ומהו מצב ההתקדמות בכל הנוגע אליהם. אם אתם כבר משתמשים במדריך ה-GKE hardening, נוספו רפרנסים להמלצות המתאימות. כך, תוכלו לבחון בקלות האם ה-hardened clusters עומדים בדרישות שלכם.
מאת: מערכת IsraelClouds
רוצים להתעדכן בתכנים בנושאי AWS? הירשמו עכשיו לניוזלטר שלנו ותמיד תישארו בעניינים > להרשמה
אם אתם רוצים לדאוג לאבטחה מקסימלית בסביבת תפעול הקוברנטיס שלכם, אתם צריכים לבנות אותו על יסודות מוצקים - והבנצ'מארק של The Center for Internet Security (CIS) יאפשר לכם לעשות זאת עם סט של הפרקטיקות הטובות ביותר, עימו תוכלו לבנות סביבת תפעול העומדת גם בצרכי הלקוחות וגם בצרכי הרגולטור.
הגרסאות האחרונות נותנות מענה לכל גרסאות הקוברנטיס. הבנצ'מארק הוא בעצם סדרה של המלצות, והוא מתנהל לפי גרסת ה-upstream של קוברנטיס (אם אתם משתמשים בהפצות מנוהלות כמו Google Kubernetes Engine [GKE], חלק מההמלצות יהיו לא רלוונטיות – לחצו כאן לגרסא מותאמת). במאמר זה נרחיב על חלק מהפיצ'רים אשר תוכלו למצוא בגרסאת הבנצ'מארק העדכנית.
צוללים לעומק
לבנצ'מארק יש מבנה שונה מזה של הגרסא האחרונה. אם בגרסאות הישנות, הגדרות המאסטר וה-worker node היו ב-high level, הרי שהגרסאות החדשות מפרידות את הבקרות לפי הרכיבים אליהם הם מתייחסים: רכיבי רמת הבקרה, etcd, הגדרת רמת הבקרה, worker nodes ו-worker policies. כך תוכלו לבצע שינויים להפצה מסוימת, במקום לנסות לשלוט במספר רכיבים במקביל או לנסות לשנות משהו שלא נמצא בתחום האחריות שלכם.
בכל הנוגע לבקרות ספציפיות, תוכלו לראות המלצות נוספות עבור:
• ניהול סודי: ההמלצות החדשות כוללות מזעור הגישה לסודות (5.1.2). מומלץ להשתמש בהם כקבצים על פני שימוש כמשתנים סביבתיים (5.4.1), ומומלץ לשקול אחסון חיצוני עבורם.
• תיעוד ביקורות: בנוסף להמלצה הקיימת בכל הנוגע לווידוא ההגדרות הרלוונטיות ושמירה על פעילות תקינה באמצעות ה-audit log flags ברמת הבקרה. בנוסף, ישנן המלצות נוספות שיוודאו שמדיניות הביקורות שתיווצר תהיה מינימלית (3.2.1), והיא גם תוודא שמדיניות זו תיתן מענה עבור חששות אבטחה מהותיים.
• מניעה של גישה שאינה נחוצה על ידי נעילות הרשאות בקוברנטיס, זאת לפי העקרון של מינימום פריווילגיות – עם דגש על מזעור ה-wildcard use ב-Roles ו-ClusterRoles (5.1.3).
גרסת ה-GKE
כפי שצוין לעיל, הבנצ'מארק לא תומך בהפצות מנוהלות של קוברנטיס, ולכן נוצרה גרסת בת, אשר הסירה חלק מהפיצ'רים שלא ניתן להגדיר או לנהל על ידי המשתמש, ביחד עם בקרות נוספות שהינן ספציפיות לענן של גוגל, וגם נחשבות למומלצות עבור ה-Clusters שלכם (לדוגמא) – מה שיוצר גרסא עם סט בקרות יחיד שנועד לתת לכם את פרקטיקת האבטחה האפקטיבית ביותר ב-GKE.
ההמלצות מתחלקות לשתי קבוצות: המלצות ברמה 1 נועדו להיות רלוונטיות עבור רוב תרחישי השימוש, ומומלץ ליישם אותן בהקדם (לדוגמא: הפעלה של Stackdriver Kubernetes Logging and Monitoring). המלצות ברמה 2 שמות יותר דגש על האבטחה, אך הן לא בהכרח רלוונטיות לכל סביבת עבודה. לכן, מומלץ להטמיע את ההמלצות הללו בזהירות בכדי להימנע מקונפליקטים בסביבות עבודה מורכבות. לדוגמא, המלצות אלו יכולות להיות מתאימות עבור עומסי עבודה מסוג multi-tenant יותר מאשר כאלו של single tenant – כמו למשל ההמלצה להשתמש ב-GKE Sandbox בכדי להריץ עומסי עבודה שאינם אמינים.
הצגת ההמלצות משתמשת בממשק פשוט המאפשר לכם לבחון מתודות אוטומטיות בקלות (כמו למשל API call או ה-gcloud CLI), ולכל הגדרה יש ערך שניתן להעריך בפשטות. לדוגמא, וידוא שה-node auto-upgrade פועל. המלצות שאינן מבוססות אוטומציה או כאלו שדורשות הטמעה ספציפית לסביבת העבודה שלכם יוצגו כ-Not Scored. לדוגמא – שימוש בחוקי ה-firewall בכדי להגביל כניסה ותעבורה ל-nodes שלכם, או שימוש בפיצ'ר בטא שאולי לא יהיה כדאי לשימוש ב-Production.
אם אתם רוצים להציע המלצות חדשות או לשנות קיימות, צרו קשר כאן.
הפעלה ובחינה של ה-CIS Benchmarks
ישנם בנצ'מארקים שהינם רלוונטיים ל-GKE, אך יש גם כלים זמינים שיעזרו לכם לבחון האם אכן עובדים לפי ההמלצות. כלי טוב שמתאים ל-CIS Kubernetes Benchmark הוא kube-bench שיבחן את ההגדרה הקיימת שלכם. עבור גרסת ה-GKE, אתם יכולים להשתמש במוצר הבא, אשר מטמיע את עצמו אל ה-Security Command Center, ומכיל כלי בחינה עבור CIS, GCP ו-GKE. על ידי הפעלת ה-Security Health Analytics, אתם תוכלו לגלות, לבחון ולתקן כל הגדרות Cluster שלא עומדות ביעדי המצוינות (לפי הבנצ'מארק המופיע ב-Vulnerabilities Dashboard ב-Security Command Center).
תיעוד הגדרות של GKE ברמת הבקרה
הבנצ'מארק החדש אמור לעזור לכם להטמיע ולהשתמש בפרקטיקות אבטחת הקוברנטיס הטובות ביותר, וכאן תוכלו לקרוא על רכיבים שטרם קיבלו מענה ומהו מצב ההתקדמות בכל הנוגע אליהם. אם אתם כבר משתמשים במדריך ה-GKE hardening, נוספו רפרנסים להמלצות המתאימות. כך, תוכלו לבחון בקלות האם ה-hardened clusters עומדים בדרישות שלכם.
מאת: מערכת IsraelClouds
רוצים להתעדכן בתכנים בנושאי AWS? הירשמו עכשיו לניוזלטר שלנו ותמיד תישארו בעניינים > להרשמה
לפרטים נוספים ויצירת קשר עם נציג אורקל
הודעתך לא התקבלה - נסה שוב מאוחר יותר