מושגים ב-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 מצורפים נתמך Clusters
Kubernetes Namespaces
Kubernetes Service Accounts
‫GKE ב-AWS נתמך Clusters
Kubernetes Namespaces
Kubernetes Service Accounts
Google Distributed Cloud נתמך Clusters
Kubernetes Namespaces
Kubernetes Service Accounts
Google Distributed Cloud נתמך Clusters
Kubernetes Namespaces
Kubernetes Service Accounts
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

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

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

    gcr.io/example-project/*

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

    gcr.io/example-project/**

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

    gcr.io/example-project/helloworld

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

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

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

    gcr.io/example-project/helloworld@*

  6. כדי להוסיף לרשימת ההיתרים גרסה ספציפית של תמונה לפי ה-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) בזמן פריסת התמונה. המאמתים מכילים את המפתח הציבורי שתואם למפתח הפרטי שבו משתמש החותם כדי לחתום על תקציר התמונה וליצור את האישור. הכלי לאכיפת הרשאות בינאריות משתמש בבודק בזמן הפריסה כדי להגביל את התמונות שמותר לפרוס לאלה עם אישור נלווה שניתן לאימות, שנוצר לפני הפריסה.

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

למאמתים יש את הדברים הבאים:

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

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

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

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

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

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

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

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

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

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

הערות של Artifact Analysis

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

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