מושגים ב-Binary Authorization

בדף הזה מוסברים מושגים שקשורים ל-Binary Authorization.

מדיניות

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

אימות מתמשך (CV), משתמש בסוג אחר של מדיניות שנקרא מדיניות פלטפורמה.

מדיניות כוללת את החלקים הבאים:

אפשר להגדיר מדיניות באמצעות אחת מהאפשרויות הבאות:

  • מסוףGoogle Cloud
  • פקודות gcloud

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

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

הוראות להגדרה ולשימוש ב-Binary Authorization בפלטפורמות נתמכות זמינות במאמר הגדרה לפי פלטפורמה.

הגדרה לדוגמה של כמה פרויקטים ב-GKE

כללים

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

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

כלל ברירת המחדל

לכל מדיניות יש כלל ברירת מחדל. הכלל הזה חל על כל בקשת פריסה שלא תואמת לכלל ספציפי. בקובץ YAML של מדיניות, כלל ברירת המחדל מצוין בצומת defaultAdmissionRule.

מידע נוסף על הגדרת כלל ברירת המחדל זמין במאמר הגדרת מדיניות.

כללים ספציפיים

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

בקובץ YAML של מדיניות, כל כלל שספציפי לאשכול מוגדר בצומת clusterAdmissionRule.

סוגי הכללים הנתמכים לפי פלטפורמה

בטבלה הבאה מוצגים סוגי הכללים שנתמכים בכל פלטפורמת פריסה.

פלטפורמה כלל ברירת המחדל כלל ספציפי
GKE נתמך אשכולות
מרחבי שמות של Kubernetes
חשבונות שירות של Kubernetes
Cloud Run נתמך לא נתמך
אשכולות GKE מצורפים נתמך אשכולות
מרחבי שמות של Kubernetes
חשבונות שירות של Kubernetes
‫GKE ב-AWS נתמך אשכולות
מרחבי שמות של Kubernetes
חשבונות שירות של Kubernetes
Google Distributed Cloud נתמך אשכולות
מרחבי שמות של Kubernetes
חשבונות שירות של Kubernetes
Google Distributed Cloud נתמך אשכולות
מרחבי שמות של Kubernetes
חשבונות שירות של Kubernetes
Cloud Service Mesh נתמך זהויות שירות ב-Cloud Service Mesh

מצבי בדיקה

לכל כלל יש מצב הערכה שמציין את סוג האילוץ ש-Binary Authorization אוכף לגבי הכלל. מצב ההערכה של כלל מוגדר באמצעות המאפיין evaluationMode בקובץ ה-YAML של המדיניות.

יש שלושה מצבי הערכה:

  • הפעלת כל התמונות: מאפשרת פריסה של כל התמונות.
  • איסור שימוש בכל התמונות: איסור שימוש בכל התמונות.
  • דרישה לאישורים: נדרש חותם לחתום דיגיטלית על תקציר התמונה וליצור אישור לפני הפריסה. בזמן הפריסה, הכלי לאכיפת Binary Authorization משתמש בגורם מאמת (attestor) כדי לאמת את החתימה באימות (attestation) לפני פריסת התמונה המשויכת.

מצבי האכיפה

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

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

  • הפעלה יבשה: יומן ביקורת בלבד: מצב הפעלה יבשה הוא מצב אכיפה במדיניות שמאפשר פריסה של תמונות שלא עומדות בדרישות, אבל כותב פרטים על הפריסה ביומני הביקורת של Cloud. מצב הרצה יבשה מאפשר לכם לבדוק מדיניות, למשל בסביבת הייצור, לפני שהאכיפה נכנסת לתוקף.

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

מציינים את מצב האכיפה של כלל באמצעות המאפיין enforcementMode בקובץ ה-YAML של המדיניות.

מידע נוסף על הודעות שנכתבות ביומני הביקורת של Cloud זמין במאמרים צפייה ביומני ביקורת (GKE,‏ Google Distributed Cloud, ‏ Cloud Service Mesh) או צפייה ביומני ביקורת (Cloud Run).

אימות רציף

אימות רציף (CV) הוא תכונה של Binary Authorization שבודקת מעת לעת תמונות שמשויכות ל-Pods פעילים כדי לוודא שהן ממשיכות לעמוד בדרישות המדיניות.

מידע נוסף על CV

תמונות מוחרגות

תמונה שפטורה היא תמונה שפטורה מכללי המדיניות. Binary Authorization תמיד מאפשרת פריסה של תמונות שפטורות מאימות. לכל פרויקט יש רשימת היתרים של תמונות שפטורות מהכלל, שצוינו לפי נתיב הרישום. תמונות בנתיב gcr.io/google_containers/*, בנתיב k8s.gcr.io/** ובנתיבים נוספים פטורות כברירת מחדל, כי הן מכילות משאבים שנדרשים כדי ש-GKE יוכל להפעיל אשכול בהצלחה עם מדיניות ברירת המחדל שפעילה.

כדי להוסיף תמונה שפטורה מהכללים לרשימת ההיתרים, מוסיפים את השורה הבאה לקובץ המדיניות: 

admissionWhitelistPatterns:
  - namePattern: EXEMPT_IMAGE_PATH

מחליפים את EXEMPT_IMAGE_PATH בנתיב לתמונה שרוצים להחריג. כדי להחריג תמונות נוספות, מוסיפים עוד רשומות של - namePattern. מידע נוסף על admissionWhitelistPatterns

תבניות של רשימת ההיתרים

כדי להוסיף לרשימת ההיתרים את כל התמונות שמיקום המאגר שלהן תואם לנתיב שצוין:

gcr.io/example-project/*

כדי להוסיף לרשימת ההיתרים את כל התמונות שמיקום הרישום שלהן הוא כל תיקיית משנה של הנתיב שצוין (למשל, gcr.io/example-project/my-directory/helloworld):

gcr.io/example-project/**

כדי להוסיף תמונה ספציפית לרשימת ההיתרים:

gcr.io/example-project/helloworld

כדי להוסיף לרשימת ההיתרים גרסה ספציפית של תמונה לפי תג:

gcr.io/example-project/helloworld:latest
gcr.io/example-project/helloworld:my-tag

כדי להוסיף לרשימת ההיתרים את כל הגרסאות והתגים של תמונה:

gcr.io/example-project/helloworld@*

כדי להוסיף לרשימת ההיתרים גרסה ספציפית של תמונה לפי ה-digest שלה:

gcr.io/example-project/helloworld@sha256:77b0b75136b9bd0fd36fb50f4c92ae0dbdbbe164ab67885e736fa4374e0cbb8c

מידע נוסף על שימוש ב-digests של תמונות מאגר

כאן מוסבר איך לנהל תמונות שפטורות מסינון באמצעות מסוף Google Cloud , באמצעות כלי שורת הפקודה או באמצעות API בארכיטקטורת REST.

תמונות מערכת שמתוחזקות על ידי Google

האפשרות Trust all Google-maintained system images גורמת לכך ש-Binary Authorization יחריג רשימה של תמונות מערכת שמתחזקת על ידי Google מהערכה נוספת של המדיניות. כשההגדרה הזו מופעלת, המדיניות לא חוסמת תמונות שנדרשות על ידי GKE. המערכת מעריכה את מדיניות המערכת לפני הערכת מדיניות המשתמש ובנוסף לה.

אפשר להפעיל או להשבית את ההגדרה הזו באמצעות המאפיין globalPolicyEvaluationMode בקובץ ה-YAML של המדיניות. אפשר לראות את התוכן של מדיניות המערכת באמצעות הפקודה הבאה:

gcloud alpha container binauthz policy export-system-policy

הצהרות

אישור הוא מסמך דיגיטלי שמאשר תמונה. במהלך הפריסה, Binary Authorization מאמת את האישור לפני שהוא מאפשר לפרוס את התמונה.

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

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

כדי להפעיל אישורים ב-Binary Authorization, צריך להגדיר את evaluationMode במדיניות לערך REQUIRE_ATTESTATION.

איך יוצרים ומשתמשים בבודקים ובאישורים

החותמים

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

איך יוצרים ומשתמשים בבודקים ובאישורים

גורמים מאמתים

גורם מאמת (attestor) הוא Google Cloud משאב שמשמש את Binary Authorization לאימות אימות (attestation) בזמן פריסת התמונה. המאמתים מכילים את המפתח הציבורי שמתאים למפתח הפרטי שבו משתמש החותם כדי לחתום על תקציר התמונה וליצור את האישור. הכלי לאכיפת הרשאות בינאריות משתמש בבודק בזמן הפריסה כדי להגביל את התמונות שמותר לפרוס לאלה עם אישור נלווה שניתן לאימות, שנוצר לפני הפריסה.

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

לגורמים המאמתים יש:

כשמגדירים מדיניות שמכילה כלל Require Attestations, צריך להוסיף מאשר לכל אדם או תהליך שנדרשים לאמת שהתמונה מוכנה לפריסה. אפשר להוסיף מאמתים באמצעות מסוף Google Cloud , ממשק gcloud או Binary Authorization REST API.

איך יוצרים ומשתמשים בבודקים ובאישורים

מפתחות קריפטוגרפיים

Binary Authorization משתמש ב-חתימות דיגיטליות כדי לאמת תמונות בזמן הפריסה, כשהמדיניות מכילה כלל Require Attestations (נדרשים אישורים).

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

לאחר מכן, נוצר גורם מאמת (attestor) והוא נשמר במדיניות. המפתח הציבורי שתואם למפתח הפרטי שמשמש לחתימה מועלה ומצורף למאשר.

כשמנסים לפרוס תמונה, Binary Authorization משתמש במאמתים במדיניות כדי לאמת את האישורים של התמונה. אם אפשר לאמת את האישור, התמונה נפרסת.

ב-Binary Authorization יש תמיכה בשני סוגים של מפתחות:

  • תשתית של מפתח ציבורי (X.509) ‏(PKIX)
  • PGP

אפשר לאחסן מפתחות PKIX באופן מקומי, חיצוני או ב-Cloud Key Management Service.

יצירת מפתח קריפטוגרפי וגורם מאשר.

הערות של Artifact Analysis

ב-Binary Authorization נעשה שימוש ב-Artifact Analysis כדי לאחסן מטא-נתונים מהימנים שמשמשים בתהליך ההרשאה. לכל גורם מאמת (attestor) שיוצרים, צריך ליצור הערה אחת של Artifact Analysis. כל אישור נשמר כמופע של ההערה הזו.

כש-Binary Authorization מעריך כלל שמחייב שגורמי אימות יאמתו תמונה, הוא בודק את האחסון של Artifact Analysis כדי לראות אם האישורים הנדרשים קיימים.