החלופות הטובות ביותר לסוכן מדיניות פתוחה עבור תאימות אבטחה מודרנית

Open Policy Agent מפעיל אכיפת מדיניות על פני ערימות מקוריות בענן מזה שנים, ומאפשר לצוותים להגדיר כללים כקוד וליישם אותם בכל מקום, מ-Kubernetes ועד ממשקי API. אך העיצוב הכללי שלו ושפת Rego עלולים להיראות כבדים, במיוחד כאשר עקומות הלמידה התלולות מאטות את הקצב או כאשר ההתמקדות נשארת בעיקר בתשתית ולא ביישומים. כיום ישנן פלטפורמות רבות עם יתרונות שונים: חלקן מפשטות את התחביר באופן דרמטי, אחרות מתמקדות ב-Kubernetes, וכמה מהן מתמקדות באישור יישומים מדויק ללא עלויות נוספות. חלופות אלה שומרות על הרעיון המרכזי – מדיניות הצהרתית, בגרסאות ב-Git, בדיקות אוטומטיות – תוך צמצום החיכוך בהגדרה, תחזוקה או קנה מידה. להלן כמה מהמתחרות החזקות ביותר כיום.

1. AppFirst

AppFirst נוקטת בגישה שונה בכך שהיא מאפשרת למפתחים להגדיר את צרכי האפליקציה, כגון מעבד, מסד נתונים, רשת ותמונת Docker, ואז מטפלת מאחורי הקלעים בהקצאת התשתית בפועל. ללא Terraform ידני, ללא התמודדות עם YAML, ללא התעסקות עם VPC – הפלטפורמה מפעילה משאבים מאובטחים ותואמים באופן אוטומטי ב-AWS, Azure או GCP. רישום, ניטור, התראות, מעקב עלויות לכל אפליקציה וסביבה, וכן יומני ביקורת מרכזיים מובנים מאפשרים מעקב ללא צורך בקוד דבק נוסף. קיימות אפשרויות לפריסה מתארחת SaaS או מתארחת עצמית, בהתאם להעדפות השליטה.

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

נקודות עיקריות

• הגדרה הממוקדת באפליקציות מניעה הקצאה אוטומטית של תשתיות
• תומך ב-AWS, Azure ו-GCP
• כולל אבטחה מובנית, יכולת ניטור ונראות עלויות
• אפשרויות פריסה SaaS או פריסה עצמית
• אין צורך בקוד אינפרא אדום ידני

יתרונות

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

חסרונות

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

פרטי קשר

• אֲתַר אִינטֶרנֶט: www.appfirst.dev

2. אוסו

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

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

נקודות עיקריות

• הגדרת מדיניות מרכזית באמצעות שפה הצהרתית
• תומך במודלים RBAC, ABAC ו-ReBAC במסגרת אחת
• כולל ניטור והתאמות דינמיות של הרשאות מינימליות
• שירות מתארח בענן עם תכונות זמינות גבוהה
• יומני ביקורת ונראות החלטות מובנים

יתרונות

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

חסרונות

• מודלים מדיניים עשויים לדרוש זמן עד שהם מתאימים נכון בהתחלה
• מסתמך במידה רבה על הענן לצורך שימוש מנוהל
• עשוי להיראות כמו תגובה מוגזמת לצרכים פשוטים מאוד של נגישות

פרטי קשר

• אתר אינטרנט: www.osohq.com
• דוא"ל: security@osohq.com
• LinkedIn: www.linkedin.com/company/osohq
• טוויטר: x.com/osoHQ

3. סרבוס

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

הליבה נשארת בקוד פתוח, בעוד שהרכזת מוסיפה ניהול מרכזי, אינטגרציה של CI/CD למדיניות ושבילים לביקורת. מהנדסים מעריכים לעתים קרובות את העיצוב חסר המצב לצורך קנה מידה ואת היכולת לבדוק מדיניות לפני פריסה. בפועל, הדבר מצמצם את פיזור קוד ההרשאות, אך מוסיף רכיב נוסף לתפעול.

נקודות עיקריות

• נקודת החלטה על מדיניות קוד פתוח עם SDKs לשפות רבות
• תומך ב-RBAC, ABAC ו-PBAC
• ארכיטקטורה נטולת מצב עבור חביון נמוך וסקלביליות
• פריסה גמישה, כולל מארח עצמי ומרכז מנוהל
• אימות מדיניות מוכן ל-CI/CD ותמיכה ב-GitOps

יתרונות

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

חסרונות

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

פרטי קשר

• אתר אינטרנט: www.cerbos.dev
• דוא"ל: help@cerbos.dev
• LinkedIn: www.linkedin.com/company/cerbos-dev
• טוויטר: x.com/cerbosdev

4. OpenFGA

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

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

נקודות עיקריות

• מודלים מבוססי יחסים בהשראת זנזיבר
• תומך במקרי שימוש של ReBAC, RBAC ו-ABAC
• ממשקי API ו-SDK ידידותיים למשתמש עבור שפות מרובות
• זמני בדיקת אישור של מילי-שניות
• קוד פתוח עם ממשל קהילתי

יתרונות

• מטפל באופן טבעי בהרשאות מורכבות המונעות על ידי יחסים
• התקנה מקומית קלה עם Docker
• תהליך פיתוח שקוף
• סקאלה מפרויקטים קטנים ועד פלטפורמות גדולות

חסרונות

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

פרטי קשר

• אתר אינטרנט: openfga.dev
• טוויטר: x.com/OpenFGA

5. ארז

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

הפרויקט מתנהל ב-GitHub תחת Apache-2.0, עם SDKs הזמינים לשילוב. הוא משתלב היטב עם שירותים מנוהלים כמו Amazon Verified Permissions לאחסון והערכה. יש המעריכים את האופי הניתן לניתוח עבור סביבות רגישות מבחינה ביטחונית, אף על פי שבפועל הוא קשור יותר למערכות אקולוגיות מסוימות.

נקודות עיקריות

• שפה ייעודית עבור RBAC ו-ABAC
• הערכת מדיניות מהירה וממוינת
• תומך בהסקת מסקנות וניתוח אוטומטיים
• קוד פתוח מלא תחת Apache-2.0
• משתלב עם שירותים מנוהלים לפריסה

יתרונות

• מבנה מדיניות נקי וניתן לניתוח
• מאפייני ביצועים צפויים
• מונע חזרה על קוד בין שירותים שונים
• דגש חזק על יכולת אימות

חסרונות

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

פרטי קשר

• אתר אינטרנט: www.cedarpolicy.com

6. Authzed SpiceDB

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

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

נקודות עיקריות

• מודל מבוסס יחסים בהשראת זנזיבר
• gRPC ו-HTTP/JSON APIs לבדיקות וכתיבה
• עקביות הניתנת להגדרה לכל בקשה
• שפת סכמה עם אימות CI/CD
• מאגרי אחסון ניתנים לחיבור, כולל PostgreSQL ו-Spanner

יתרונות

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

חסרונות

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

פרטי קשר

• אתר אינטרנט: authzed.com
• LinkedIn: www.linkedin.com/company/authzed
• טוויטר: x.com/authzed

7. HashiCorp Sentinel

Sentinel מספק שפת מדיניות ומסגרת בעיקר לאכיפת כללים בכלי HashiCorp, במיוחד במהלך תוכניות Terraform לפני היישום. המדיניות נכתבת בסינטקס קריא משלה, ושואבת נתונים מהתוכנית או ממקורות חיצוניים כדי להחליט אם היא עברה או נכשלה. היא משתלבת ישירות בתהליכי עבודה כמו Terraform Cloud או Enterprise, ובודקת את התצורות מול כללי אבטחה, עלות או תאימות. השפה תומכת בייבוא של לוגיקה לשימוש חוזר ובדוגמאות לבדיקות מקומיות. כרכיב שניתן לשלב, היא נשארת קשורה לאקוסיסטם של HashiCorp ולא עומדת בפני עצמה באופן כללי.

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

נקודות עיקריות

• שפת מדיניות לקבלת החלטות מדויקות המבוססות על לוגיקה
• משתלב עם זרימות העבודה של Terraform plan/apply
• תומך בייבוא נתונים חיצוניים ובמסגרת בדיקות
• ניתן לשילוב במוצרי HashiCorp לארגונים
• בקרת גרסאות וידידותיות לאוטומציה

יתרונות

• התאמה הדוקה לממשל Terraform
• תחביר מדיניות קריא עם תמיכה בבדיקות
• מאתר הפרות לפני אספקת משאבים
• מודולים רב-פעמיים מפחיתים כפילויות

חסרונות

• מוגבל בעיקר לערכת הכלים של HashiCorp
• תהליכי עבודה חיצוניים פחות גמישים
• נדרש רישיון ארגוני לשימוש מלא

פרטי קשר

• אתר אינטרנט: www.hashicorp.com
• לינקדאין: www.linkedin.com/company/hashicorp
• פייסבוק: www.facebook.com/HashiCorp
• טוויטר: x.com/hashicorp

8. jsPolicy

jsPolicy משמש כבקר קבלה של Kubernetes המאפשר להפעיל מדיניות ב-JavaScript או ב-TypeScript במקום בשפות ספציפיות לתחום. הוא מטפל באימות ובשינוי בקשות, בנוסף לסוג מדיניות בקר ייחודי המופעל לאחר אירועים לצורך אכיפה מתמשכת. המדיניות מתקמפלת ומוטמעת כמשאבי Kubernetes רגילים, עם מערכת npm מלאה הזמינה לתלות ובדיקות. הגישה עושה שימוש חוזר בכלים מוכרים של JS ללינטינג, ניפוי באגים ושיתוף חבילות, מה שמרגיש מרענן אם Rego או YAML כבר גורמים לתסכול.

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

נקודות עיקריות

• מדיניות שנכתבה ב-JavaScript או ב-TypeScript
• תומך באימות, שינוי ומדיניות בקרים
• מנצל את npm לניהול חבילות וכלים
• מערכת אקולוגית JS מלאה עבור תהליכי פיתוח ובדיקה
• קוד פתוח עם תמיכת הקהילה

יתרונות

• שפה מוכרת מורידה את מחסום הכניסה עבור מפתחים רבים
• לוגיקה קלה לשינוי בהשוואה לאחרים
• בדיקות בוגרות ומערכת אקולוגית של חבילות
• מדיניות הבקרים מוסיפה גמישות לאחר האירוע

חסרונות

• סביבת ההפעלה JS מכניסה עומס פוטנציאלי לאשכול
• פחות הצהרתי מגישות YAML
• עלול להרגיש פחות “יליד Kubernetes” לטהרנים

פרטי קשר

• אתר אינטרנט: www.jspolicy.com
• LinkedIn: www.linkedin.com/company/loft-sh
• טוויטר: x.com/loft_sh

9. קובוורדן

Kubewarden פועל כמנוע מדיניות עבור קבלה ל-Kubernetes באמצעות WebAssembly כדי להפעיל מדיניות שנכתבה בשפות שונות. המחברים בוחרים Rust, Go, CEL, Rego או כל שפה שמכוונת ל-Wasm, ואז בונים ודוחפים מדיניות כתמונות קונטיינר להפצה. הוא מכסה אימות קבלה סטנדרטי ומוטציה, בנוסף לאימות JSON גולמי מחוץ להקשרים של Kubernetes טהור. הניידות נובעת מעצמאות הארכיטקטורה של Wasm, כך שאותו בינארי מדיניות פועל במערכות הפעלה וחומרה שונות. המדיניות נשארת ניטרלית מבחינת ספקים ומשתלבת עם רישומי קונטיינרים קיימים ו-CI/CD.

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

נקודות עיקריות

• ביצוע מדיניות מבוסס WebAssembly
• תומך ב-Rust, Go, CEL, Rego ויעדי Wasm אחרים
• מדיניות המופצת באמצעות רישומי מכולות
• ניתן להעברה בין ארכיטקטורות ומערכות הפעלה שונות
• אימות JSON גולמי לשימוש שאינו קשור לקבלה

יתרונות

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

חסרונות

• תהליך הבנייה של Wasm מוסיף מורכבות
• לעיתים נדרש כוונון ביצועים עבור מדיניות כבדה
• פחות דוגמטי ממנועי שפה אחת

פרטי קשר

• אתר אינטרנט: www.kubewarden.io

10. פוגה רגולה

Regula סורקת קבצי תשתית כקוד ומחפשת בעיות אבטחה ופערים בתאימות לפני שהכל מגיע לייצור. היא מטפלת בקוד ובתוכניות Terraform, בתבניות CloudFormation, במניפסטים של Kubernetes ואפילו ב-Azure ARM במצב תצוגה מקדימה. הכללים נכתבים ב-Rego – אותה שפה שבה משתמשת OPA – ומכסים את המכשולים הנפוצים של ספקי ענן המותאמים לנקודות הייחוס של CIS, כאשר הדבר הגיוני. הפעלתו באופן מקומי או הכנסתו לצינורות CI/CD מרגישה פשוטה, במיוחד עם הדוגמה של GitHub Actions שנמצאת ממש שם. מהנדסי Fugue ממשיכים להפעיל אותו, וקיימת תמונת Docker להורדה קלה.

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

נקודות עיקריות

• סורק תבניות Terraform, CloudFormation, Kubernetes YAML ו-ARM
• משתמש בכללים מבוססי Rego המותאמים לנקודות ייחוס CIS
• עובד ב-CLI מקומי או בצינורות CI/CD
• זמין כתמונת Docker ובאמצעות Homebrew
• מתוחזק על ידי מהנדסי Fugue

יתרונות

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

חסרונות

• כללי Rego עשויים להיראות מורכבים למתחילים
• מוגבל לסריקת IaC, לא לאכיפה בזמן ריצה
• תמיכה בתצוגה מקדימה עבור פורמטים מסוימים פירושה לעיתים קצוות לא חלקים

פרטי קשר

• אתר אינטרנט: github.com/fugue/regula 
• LinkedIn: www.linkedin.com/company/github
• טוויטר: x.com/github
• אינסטגרם: www.instagram.com/github

מַסְקָנָה

הבחירה בחלופה ל-OPA תלויה בדרך כלל בנקודת התורפה הגדולה ביותר שלכם כרגע. אם Rego מרגיש כמו ניפוי באגים אינסופי, או ש-sidecars מעמיסים על האשכול שלכם, בחרו במשהו מקורי וקליל יותר. חנויות Kubernetes בוחרות לעתים קרובות באפשרויות מבוססות YAML או WebAssembly שנמצאות בטריטוריה מוכרת. צוותי אפליקציות הזקוקים לאישור נקי ומדויק נוטים לבחור במודלים יחסיים או בשכבות אישור ייעודיות השומרות על מדיניות פשוטה וניתנת לבדיקה.

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