הגדרת מדיניות באמצעות API בארכיטקטורת REST

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

סקירה כללית

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

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

כדי להגדיר מדיניות, צריך:

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

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

הגדרת פרויקט ברירת מחדל

אם עדיין לא עשיתם את זה, מגדירים את פרויקט ברירת המחדל Google Cloud :

PROJECT_ID=PROJECT_ID
gcloud config set project ${PROJECT_ID}

כאשר PROJECT_ID הוא מזהה הפרויקט.

ייצוא המדיניות

החלק הזה רלוונטי ל-GKE,‏ Distributed Cloud,‏ Cloud Run ו-Cloud Service Mesh.

מייצאים את המדיניות לקובץ JSON במערכת המקומית:

curl \
    -H "Authorization: Bearer $(gcloud auth application-default print-access-token)" \
    -H "x-goog-user-project: ${PROJECT_ID}" \
    "https://binaryauthorization.googleapis.com/v1/projects/${PROJECT_ID}/policy" \
    -o "/tmp/policy.json"

כברירת מחדל, הקובץ מכיל את התוכן הבא:

{
  "name": "projects/PROJECT_ID/policy",
  "globalPolicyEvaluationMode": "ENABLE",
  "defaultAdmissionRule": {
    "evaluationMode": "ALWAYS_ALLOW",
    "enforcementMode": "ENFORCED_BLOCK_AND_AUDIT_LOG"
  }
}

ניהול תמונות מוחרגות

החלק הזה רלוונטי ל-GKE,‏ Distributed Cloud,‏ Cloud Run ו-Cloud Service Mesh.

קובץ אימג' פטור הוא קובץ אימג' של קונטיינר שפטור מכללי המדיניות. ‫Binary Authorization תמיד מאפשר פריסה של תמונות שמוחרגות.

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

כדי להוסיף תמונה שפטורה מהמדיניות, מוסיפים צומת namePattern מתחת לרשימה admissionWhitelistPatterns בקובץ ה-JSON של המדיניות:

{
  "name": "projects/PROJECT_ID/policy",
  "admissionWhitelistPatterns": [
    {
      "namePattern": "MATCHING_PATTERN"
    }
  ],
  ...
}

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

Cloud Run

הקטע הזה רלוונטי ל-Cloud Run.

אי אפשר לציין ישירות שמות של תמונות שמכילים תג. לדוגמה, אי אפשר לציין את הערך IMAGE_PATH:latest.

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

  • * לכל הגרסאות של תמונה אחת. לדוגמה, us-docker.pkg.dev/myproject/container/hello@*
  • ‫** לכל התמונות בפרויקט, למשל us-docker.pkg.dev/myproject/**

אפשר להשתמש בשמות נתיבים כדי לציין תקציר בפורמט IMAGE_PATH@DIGEST.

מצב הערכה של מדיניות המערכת

הסעיף הזה רלוונטי ל-GKE ול-Distributed Cloud.

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

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

gcloud alpha container binauthz policy export-system-policy

כדי להפעיל את מצב ההערכה של מדיניות המערכת, מוסיפים את הצומת הבא ברמה העליונה לקובץ ה-JSON של המדיניות:

"globalPolicyEvaluationMode": "ENABLE"

כדי להשבית את מצב ההערכה של מדיניות המערכת, מוסיפים את השורה הבאה:

"globalPolicyEvaluationMode": "DISABLE"

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

gcloud alpha container binauthz policy export-system-policy \
  --location=REGION > /tmp/policy.yaml

מחליפים את REGION באזור שמשויך למדיניות המערכת שרוצים לייצא (או ב-global). דוגמאות: asia-east1,‏ europe-west1, ‏ us-central1.

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

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

החלק הזה רלוונטי ל-GKE,‏ Distributed Cloud,‏ Cloud Run ו-Cloud Service Mesh.

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

כלל ברירת המחדל מוגדר בצומת defaultAdmissionRule במדיניות. מידע נוסף על החלקים של הכלל הזה זמין במאמר ADMISSION_RULE בהפניה ל-YAML של המדיניות. דוגמאות לכללי ברירת מחדל מופיעות במאמר דוגמאות לכללי מדיניות.

כדי להגדיר את כלל ברירת המחדל, עורכים את הצומת defaultAdmissionRule בקובץ ה-JSON של המדיניות לפי הצורך:

  "defaultAdmissionRule": {
    "evaluationMode": "EVAL_MODE",
    "enforcementMode": "ENFORCEMENT_MODE"
    requireAttestationsBy: [
      ATTESTOR,
      ...
    ]
  }

where:

  • ‫EVAL_MODE מציין את סוג האילוץ ש-Binary Authorization מעריך לפני שהוא מאפשר פריסה של קובץ אימג' של קונטיינר.
  • ENFORCEMENT_MODE מציין את הפעולה שתתבצע אם קובץ אימג' של קונטיינר לא יעמוד במגבלות שמוגדרות בכלל.
  • ‫ATTESTOR מציין את הגורמים המאשרים (אם נדרש) שצריכים לחתום על קובץ אימג' של קונטיינר לפני שאפשר לפרוס אותה. צריך להשתמש בנתיב המלא של המאשר בפורמט projects/PROJECT_ID/attestors/ATTESTOR_NAME.

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

הגדרת כללים ספציפיים לאשכול (אופציונלי)

הסעיף הזה רלוונטי ל-GKE ול-Distributed Cloud.

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

כללים ספציפיים לאשכול מוגדרים בצמתים clusterAdmissionRules בקובץ ה-JSON של המדיניות. מידע נוסף על החלקים של הכלל הזה זמין במאמר ADMISSION_RULE בהפניה ל-YAML של המדיניות. דוגמה מופיעה במאמר דוגמאות למדיניות בקטע שימוש בכלל ספציפי לאשכול.

כדי להוסיף כלל ספציפי לאשכול:

בקובץ ה-JSON של המדיניות, מוסיפים צומת clusterAdmissionRules:

"clusterAdmissionRules": {
    "us-central1-a.test-cluster": {
      "evaluationMode": "REQUIRE_ATTESTATION",
      "requireAttestationsBy": [
        "ATTESTOR",
        ...
      ],
      "enforcementMode": "ENFORCED_BLOCK_AND_AUDIT_LOG"
    }
  },

כאשר CLUSTER_SPECIFIER הוא מזהה המשאב של האשכול שהכלל חל עליו.

  • ב-GKE, ב-GKE Attached Clusters וב-GKE ב-AWS, הפורמט הוא CLUSTER_LOCATION.CLUSTER_NAME – לדוגמה, us-central1-a.test-cluster.
  • ב-Google Distributed Cloud וב-Google Distributed Cloud, הפורמט הוא FLEET_MEMBERSHIP_LOCATION.FLEET_MEMBERSHIP_ID – לדוגמה, global.test-membership.

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

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

ייבוא קובץ JSON של מדיניות

החלק הזה רלוונטי ל-GKE,‏ Distributed Cloud,‏ Cloud Run ו-Cloud Service Mesh.

מייבאים את קובץ ה-JSON של המדיניות בחזרה אל Binary Authorization על ידי הזנת הפקודה הבאה:

curl -X PUT \
    -H "Content-Type: application/json" \
    -H "Authorization: Bearer $(gcloud auth application-default print-access-token)" \
    -H "x-goog-user-project: ${PROJECT_ID}" \
    --data-binary @/tmp/policy.json  \
    "https://binaryauthorization.googleapis.com/v1/projects/${PROJECT_ID}/policy"

המאמרים הבאים