בדף הזה מוסבר איך להגדיר אילוצים של Policy Controller באמצעות תבניות אילוצים קיימות שסופקו על ידי Google.
הדף הזה מיועד למנהלי IT ולמפעילים שרוצים לוודא שכל המשאבים שפועלים בפלטפורמת הענן עומדים בדרישות התאימות של הארגון. לשם כך, הם יכולים לספק ולתחזק אוטומציה לביקורת או לאכיפה, ולהשתמש בתבניות של הגדרה הצהרתית. כדי לקבל מידע נוסף על תפקידים נפוצים ומשימות לדוגמה שאנחנו מתייחסים אליהם ב Google Cloud תוכן, אפשר לעיין במאמר תפקידים נפוצים של משתמשים ב-GKE ומשימות.
באמצעות Policy Controller אפשר לאכוף מדיניות עבור אשכול Kubernetes על ידי הגדרה של אובייקט אילוץ אחד או יותר. אחרי שמתקינים אילוץ, המערכת בודקת את הבקשות לשרת ה-API מול האילוץ, ואם הן לא עומדות בו היא דוחה אותן. מערכת הדיווח על משאבים קיימים שלא עומדים בדרישות מתבצעת בזמן הביקורת.
כל אילוץ מגובה בתבנית אילוצים שמגדירה את הסכימה והלוגיקה של האילוץ. אפשר להשתמש בתבניות של אילוצים שזמינות ב-Google ובצדדים שלישיים, או לכתוב תבניות משלכם. מידע נוסף על יצירת תבניות חדשות זמין במאמר כתיבת תבנית אילוץ.
לפני שמתחילים
בדיקה של ספריית תבניות האילוצים
כשמגדירים אילוץ, מציינים את תבנית האילוץ שהוא מרחיב. ספרייה של תבניות אילוצים נפוצות שפותחו על ידי Google מותקנת כברירת מחדל, ובארגונים רבים אין צורך ליצור תבניות אילוצים מותאמות אישית ישירות ב-Rego. תבניות אילוצים ש-Google מספקת מסומנות בתווית configmanagement.gke.io/configmanagement.
כדי להציג את האילוצים, משתמשים בפקודה הבאה:
kubectl get constrainttemplates \
-l="configmanagement.gke.io/configmanagement=config-management"
כדי לתאר תבנית אילוצים ולבדוק את הפרמטרים הנדרשים שלה, משתמשים בפקודה הבאה:
kubectl describe constrainttemplate CONSTRAINT_TEMPLATE_NAME
אפשר גם לראות את כל תבניות האילוצים בספרייה.
הגדרת אילוץ
מגדירים אילוץ באמצעות YAML, ולא צריך להבין או לכתוב Rego. במקום זאת, אילוץ מפעיל תבנית אילוצים ומספק לה פרמטרים שספציפיים לאילוץ.
אם אתם משתמשים ב-סנכרון תצורות עם מאגר היררכי, מומלץ ליצור את האילוצים בספרייה cluster/.
למגבלות יש את השדות הבאים:
- השדה
kindבאותיות קטנות תואם לשם של תבנית אילוצים. -
metadata.nameהוא שם האילוץ. - השדה
matchמגדיר על אילו אובייקטים חל האילוץ. כדי שאובייקט יהיה בהיקף של אילוץ, הוא צריך לעמוד בכל התנאים שצוינו.matchהתנאים מוגדרים על ידי שדות המשנה הבאים:-
kindsהם סוגי המשאבים שההגבלה חלה עליהם, שנקבעים על ידי שני שדות:apiGroupsהיא רשימה של קבוצות API של Kubernetes שתואמות ו-kindsהיא רשימה של סוגים שתואמים. '*' תואם לכל דבר. אם יש התאמה בין לפחות רשומה אחת שלapiGroupורשומה אחת שלkind, התנאיkindsמתקיים. -
scopeמקבל *, Cluster או Namespaced, שקובעים אם נבחרו משאבים בהיקף אשכול או בהיקף מרחב שמות (ברירת המחדל היא *). -
namespacesהיא רשימה של שמות מרחבי שמות שהאובייקט יכול להשתייך אליהם. האובייקט חייב להשתייך לפחות לאחד ממרחבי השמות האלה. משאבים במרחב שמות נחשבים כמשאבים ששייכים לעצמם. -
excludedNamespacesהיא רשימה של מרחבי שמות שהאובייקט לא יכול להשתייך אליהם. -
labelSelectorהוא סלקטור של תוויות Kubernetes שהאובייקט צריך לעמוד בו. -
namespaceSelectorהוא בורר תוויות במרחב השמות שאליו האובייקט שייך. אם מרחב השמות לא תואם לאובייקט, לא תהיה התאמה. משאבים של מרחב שמות מטופלים כאילו הם שייכים לעצמם.
-
- בשדה
parametersמוגדרים הארגומנטים של האילוץ, על סמך מה שתבנית האילוץ מצפה לקבל.
האילוץ הבא, שנקרא ns-must-have-geo, מפעיל תבנית אילוצים שנקראת K8sRequiredLabels, שנכללת בספריית תבניות האילוצים ש-Google מספקת. האילוץ מגדיר פרמטרים שתבנית האילוץ משתמשת בהם כדי להעריך אם מרחבי שמות כוללים את התווית geo עם ערך מסוים.
# ns-must-have-geo.yaml
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
name: ns-must-have-geo
spec:
match:
kinds:
- apiGroups: [""]
kinds: ["Namespace"]
parameters:
labels:
- key: "geo"
כדי ליצור את האילוץ, משתמשים ב-kubectl apply -f:
kubectl apply -f ns-must-have-geo.yaml
ביקורת על מגבלה
אם האילוץ מוגדר ומוטמע בצורה נכונה, השדה status.byPod[].enforced שלו מוגדר לערך true, בין אם האילוץ מוגדר לאכיפה או רק לבדיקה.
האילוצים נאכפים כברירת מחדל, והפרה של אילוץ מונעת פעולה מסוימת באשכול. אפשר להגדיר את spec.enforcementAction של אילוץ ל-dryrun כדי לדווח על הפרות בשדה status.violations בלי למנוע את הפעולה.
מידע נוסף על ביקורת זמין במאמר ביקורת באמצעות אילוצים.
הערות לגבי סנכרון של אילוצים
אם אתם מסנכרנים את האילוצים שלכם למקור מרכזי, כמו מאגר Git, באמצעות סנכרון תצורות או כלי אחר בסגנון GitOps, חשוב לזכור את ההערות הבאות כשמסנכרנים אילוצים.
מודל עקביות הדרגתי
אפשר להוסיף אילוצים למקור אמת כמו מאגר Git, ולהגביל את ההשפעה שלהם באמצעות ClusterSelectors או NamespaceSelectors. הסנכרון הוא עקבי בסופו של דבר, ולכן חשוב לזכור את ההערות הבאות:
- אם פעולה באשכול מפעילה אילוץ שבו NamespaceSelector מתייחס למרחב שמות שלא סונכרן, האילוץ נאכף והפעולה נמנעת. במילים אחרות, אם חסר מרחב שמות, המערכת לא תפעל.
- אם משנים את התוויות של מרחב שמות, יכול להיות שבמטמון יישמרו נתונים מיושנים למשך זמן קצר.
מומלץ לצמצם את הצורך לשנות את השם של מרחב שמות או את התוויות שלו, ולבדוק אילוצים שמשפיעים על מרחב שמות ששונה לו השם או התוויות כדי לוודא שהם פועלים כמצופה.
הגדרת Policy Controller לאילוצים של הפניות
כדי להפעיל אילוצי הפניה, צריך ליצור הגדרה שמציינת ל-Policy Controller אילו סוגים של אובייקטים צריך לעקוב, כמו מרחבי שמות.
שומרים את מניפסט ה-YAML הבא בקובץ ומחילים אותו באמצעות kubectl. קובץ המניפסט מגדיר את Policy Controller כך שיעקוב אחרי מרחבי שמות ו-Ingress.
יוצרים רשומה עם group, version ו-kind בקטע spec.sync.syncOnly, עם הערכים של כל סוג אובייקט שרוצים לעקוב אחריו.
apiVersion: config.gatekeeper.sh/v1alpha1
kind: Config
metadata:
name: config
namespace: "gatekeeper-system"
spec:
sync:
syncOnly:
- group: ""
version: "v1"
kind: "Namespace"
- group: "extensions"
version: "v1beta1"
kind: "Ingress"
הפעלת אילוצי שלמות
אילוץ הפניה מפנה לאובייקט אחר בהגדרה שלו. לדוגמה, אפשר ליצור אילוץ שמחייב שאובייקטים של Ingress באשכול יכללו שמות מארחים ייחודיים. האילוץ הוא רפרנסיאלי אם תבנית האילוץ שלו מכילה את המחרוזת data.inventory ב-Rego.
האילוצים של שלמות נתונים מופעלים כברירת מחדל אם מתקינים את Policy Controller באמצעות מסוף Google Cloud . אם מתקינים את Policy Controller באמצעות Google Cloud CLI, אפשר לבחור אם להפעיל אילוצי הפניה כשמתקינים את Policy Controller. העקביות של אילוצי שלמות נשמרת רק בסופו של דבר, וזה יוצר סיכונים:
בשרת API שעמוס מדי, יכול להיות שהתוכן של מטמון Policy Controller יהיה ישן מדי, ולכן אילוץ של הפניה יפעל בצורה לא תקינה. כלומר, ייראה כאילו פעולת האכיפה פועלת, אבל היא לא באמת פועלת. לדוגמה, אפשר ליצור Ingresses עם שמות מארחים כפולים מהר מדי, כך ש-admission controller לא יוכל לזהות את הכפילויות.
הסדר שבו המגבלות מותקנות והסדר שבו המטמון מתעדכן הם אקראיים.
אפשר לעדכן קלאסטר קיים כדי לאפשר אילוצי הפניה.
המסוף
כדי להשבית אילוצים שלמות נתונים:
- נכנסים לדף Policy בקטע Posture Management במסוף Google Cloud .
- בכרטיסייה הגדרות, בטבלת האשכולות, לוחצים על עריכה edit בעמודה עריכת ההגדרה.
- מרחיבים את התפריט Edit Policy Controller configuration (עריכת ההגדרה של Policy Controller).
- מסמנים את התיבה הפעלת תבניות של אילוצים שמפנות לאובייקטים אחרים מלבד האובייקט שנבדק כרגע.
- לוחצים על שמירת השינויים.
gcloud
כדי להפעיל תמיכה באילוצים של הפניה, מריצים את הפקודה הבאה:
gcloud container fleet policycontroller update \
--memberships=MEMBERSHIP_NAME \
--referential-rules
מחליפים את MEMBERSHIP_NAME בשם החברות של האשכול הרשום כדי להפעיל כללים שלמות. אפשר לציין כמה חברויות ולהפריד ביניהן באמצעות פסיקים.
השבתת אילוצים שלמותיים
כשמשביתים אילוצי הפניה, גם תבניות שמשתמשות באילוצי הפניה מוסרות מהאשכול, יחד עם אילוצים שמשתמשים בתבניות האלה.
המסוף
כברירת מחדל, אילוצי הפניה מופעלים כשמתקינים את Policy Controller באמצעות מסוף Google Cloud . כדי להשבית אילוצים שלמות נתונים:
- נכנסים לדף Policy בקטע Posture Management במסוף Google Cloud .
- בכרטיסייה הגדרות, בטבלת האשכולות, לוחצים על עריכה edit בעמודה עריכת ההגדרה.
- מרחיבים את התפריט Edit Policy Controller configuration (עריכת ההגדרה של Policy Controller).
- מבטלים את הסימון של התיבה Enable Constraint Templates that reference to objects other than the object currently being evaluated. (הפעלת תבניות של אילוצים שמפנות לאובייקטים אחרים מלבד האובייקט שנבדק כרגע).
- לוחצים על שמירת השינויים.
gcloud
כדי להשבית את התמיכה באילוצים של הפניות, מריצים את הפקודה הבאה:
gcloud container fleet policycontroller update \
--memberships=MEMBERSHIP_NAME \
--no-referential-rules
מחליפים את MEMBERSHIP_NAME בשם החברות של האשכול הרשום כדי להפעיל כללים שלמות. אפשר לציין כמה חברויות ולהפריד ביניהן באמצעות פסיקים.
הצגת רשימה של כל האילוצים
כדי לראות את כל האילוצים שהותקנו באשכול, משתמשים בפקודה הבאה:
kubectl get constraint
בנוסף, תוכלו לראות סקירה כללית של האילוצים שהוחלו ב Google Cloud מסוף. מידע נוסף זמין במאמר בנושא מדדים של Policy Controller.
הסרת אילוץ
כדי למצוא את כל האילוצים שמשתמשים בתבנית אילוצים, משתמשים בפקודה הבאה כדי להציג רשימה של כל האובייקטים עם אותו kind כמו kind של תבנית האילוצים:metadata.name
kubectl get CONSTRAINT_TEMPLATE_NAME
כדי להסיר אילוץ, מציינים את kind וname שלו:
kubectl delete CONSTRAINT_TEMPLATE_NAME CONSTRAINT_NAME
כשמסירים אילוץ, האכיפה שלו נפסקת ברגע ששרת ה-API מסמן את האילוץ כמחוק.
הסרת כל תבניות האילוצים
המסוף
כדי להשבית את ספריית תבניות האילוצים:
- נכנסים לדף Policy בקטע Posture Management במסוף Google Cloud .
- בכרטיסייה הגדרות, בטבלת האשכולות, לוחצים על עריכה edit בעמודה עריכת ההגדרה.
- בתפריט הוספה או עריכה של חבילות מדיניות, משביתים את ספריית התבניות ואת כל חבילות המדיניות do_not_disturb_on.
- לוחצים על שמירת השינויים.
gcloud
כדי להשבית את ספריית תבניות האילוצים, מריצים את הפקודה הבאה:
gcloud container fleet policycontroller content templates disable \
--memberships=MEMBERSHIP_NAME
מחליפים את MEMBERSHIP_NAME בשם החברות של האשכול הרשום כדי להשבית את ספריית תבניות האילוצים. אפשר לציין כמה חברויות ולהפריד ביניהן באמצעות פסיקים.
שחזור ספריית תבניות האילוצים
המסוף
כדי להפעיל את ספריית תבניות האילוצים:
- נכנסים לדף Policy בקטע Posture Management במסוף Google Cloud .
- בכרטיסייה הגדרות, בטבלת האשכולות, לוחצים על עריכה edit בעמודה עריכת ההגדרה.
- בתפריט הוספה או עריכה של חבילות מדיניות, מעבירים את המתג של ספריית התבניות למצב מופעל check_circle. אפשר גם להפעיל את כל חבילות המדיניות או חלק מהן.
- לוחצים על שמירת השינויים.
gcloud
כדי לשחזר את ספריית תבניות האילוצים, מריצים את הפקודה הבאה:
gcloud container fleet policycontroller content templates enable \
--memberships=MEMBERSHIP_NAME
מחליפים את MEMBERSHIP_NAME בשם החברות של האשכול הרשום כדי להפעיל את ספריית תבניות האילוצים. אפשר לציין כמה חברויות ולהפריד ביניהן באמצעות פסיקים.
המאמרים הבאים
- מידע על חבילות Policy Controller
- מאמרי העזרה בנושא ספריית תבניות האילוצים
- איך יוצרים אילוצים בהתאמה אישית
- פתרון בעיות ב-Policy Controller