הגדרת מדיניות באמצעות ה-CLI של gcloud

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

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

לפני שמתחילים

  1. מפעילים את Binary Authorization.
  2. יצירת אשכול
  3. אם אתם מתכוונים להשתמש באישורים, מומלץ ליצור מאשרי אישורים לפני שמגדירים את המדיניות. אפשר ליצור מאמתים באמצעות כלי שורת פקודה או דרך מסוףGoogle Cloud .

  4. מגדירים את מזהה הפרויקט לפרויקט שבו הפעלתם את Binary Authorization:

    PROJECT_ID=PROJECT_ID
gcloud config set project ${PROJECT_ID}

ייצוא קובץ ה-YAML של המדיניות

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

כדי לעדכן את המדיניות, קודם מייצאים אותה לקובץ YAML מקומי, באופן הבא:

gcloud container binauthz policy export > /tmp/policy.yaml

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

defaultAdmissionRule:
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
  evaluationMode: ALWAYS_ALLOW
globalPolicyEvaluationMode: ENABLE
name: projects/PROJECT_ID/policy

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

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

admissionWhitelistPatterns:
  - namePattern: EXEMPT_IMAGE_PATH

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

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

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

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

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

כדי להגדיר את כלל ברירת המחדל, עורכים את הצומת defaultAdmissionRule בקובץ policy.yaml לפי הצורך:

defaultAdmissionRule:
  evaluationMode: EVALUATION_MODE
  enforcementMode: ENFORCEMENT_MODE
  requireAttestationsBy:
  - ATTESTOR
  - ...

מחליפים את מה שכתוב בשדות הבאים:

  • ‫EVALUATION_MODE: מצב ההערכה מציין את סוג האילוץ שמנגנון האכיפה של Binary Authorization אוכף בזמן הפריסה. מחליפים את EVALUATION_MODE באחת מהאפשרויות הבאות:

    • ‫ALWAYS_ALLOW: מאפשר פריסה של כל התמונות.
    • ‫ALWAYS_DENY: לא מאפשרת פריסה של תמונות.
    • ‫REQUIRE_ATTESTATION: מאפשר פריסה של תמונה אם יש לה אישור אחד או יותר שאפשר לאמת באמצעות כל המאמתים שמוסיפים לכלל הזה. בזמן הפריסה, האוכף מאמת את האישור באמצעות המאמתים שמוסיפים לרשימת ATTESTOR בכלל הזה. במאמר יצירת מאמתים מוסבר איך ליצור מאמתים. אם מציינים את הערך REQUIRE_ATTESTATION, צריך להוסיף גם בלוק requireAttestationsBy שמכיל לפחות גורם מאמת (attestor) אחד. במאמר יצירת מאמתים מוסבר איך ליצור מאמתים.

  • ‫ENFORCEMENT_MODE: מצב האכיפה מציין איך הכלי לאכיפת הכללים מגיב כשבתמונה יש הפרה של כלל. מחליפים את ENFORCEMENT_MODE באחד מהערכים הבאים:

    • ‫ENFORCED_BLOCK_AND_AUDIT_LOG: חסימת תמונות שמפירות את הכלל ורישום מידע על ההפרה ביומני הביקורת של Cloud (ברירת מחדל).
    • ‫DRYRUN_AUDIT_LOG_ONLY: מאפשר פריסה של כל התמונות, אבל רושם ביומני הביקורת של Cloud את פרטי האכיפה, כולל פרטים על הפרות.

  • ‫ATTESTOR: אם מגדירים את EVALUATION_MODE לערך REQUIRE_ATTESTATION, צריך להוסיף גם בלוק requireAttesationsBy. בבלוק, מפרטים מאמת אחד או יותר לפי מזהה המשאב. מזהה המשאב הוא בפורמט הבא:

    projects/PROJECT_ID/attestors/ATTESTOR_NAME.

    מידע נוסף על יצירת מאמתים זמין במאמר בנושא יצירת מאמתים.

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

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

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

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

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

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

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

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.

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

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

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

בקובץ policy.yaml, מוסיפים צומת clusterAdmissionRules:

clusterAdmissionRules:
  CLUSTER_SPECIFIER:
    evaluationMode: EVALUATION_MODE
    enforcementMode: ENFORCEMENT_MODE
    requireAttestationsBy:
    - ATTESTOR
    - ...

מחליפים את מה שכתוב בשדות הבאים:

  • ‫CLUSTER_SPECIFIER: מזהה המשאב של האשכול שהכלל חל עליו. הפורמט של הכלל הוא:

    • ב-GKE, באשכולות GKE מצורפים וב-GKE ב-AWS, הפורמט הוא CLUSTER_LOCATION.CLUSTER_NAME—לדוגמה, us-central1-a.test-cluster.

    • בתוכנת Google Distributed Cloud (אשכולות GKE ב-Bare Metal או ב-VMware), הפורמט הוא, FLEET_MEMBERSHIP_LOCATION.FLEET_MEMBERSHIP_ID—לדוגמה, global.test-membership.

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

  • ‫EVALUATION_MODE: מצב ההערכה מציין את סוג האילוץ שמנגנון האכיפה של Binary Authorization אוכף בזמן הפריסה. מחליפים את EVALUATION_MODE באחת מהאפשרויות הבאות:

    • ‫ALWAYS_ALLOW: מאפשר פריסה של כל התמונות.
    • ‫ALWAYS_DENY: לא מאפשרת פריסה של תמונות.
    • ‫REQUIRE_ATTESTATION: מאפשר פריסה של תמונה אם יש לה אישור אחד או יותר שאפשר לאמת באמצעות כל המאמתים שמוסיפים לכלל הזה. בזמן הפריסה, האוכף מאמת את האישור באמצעות המאמתים שמוסיפים לרשימת ATTESTOR בכלל הזה. במאמר יצירת מאמתים מוסבר איך ליצור מאמתים. אם מציינים את הערך REQUIRE_ATTESTATION, צריך להוסיף גם בלוק requireAttestationsBy שמכיל לפחות גורם מאמת (attestor) אחד. במאמר יצירת מאמתים מוסבר איך ליצור מאמתים.

  • ‫ENFORCEMENT_MODE: מצב האכיפה מציין איך הכלי לאכיפת הכללים מגיב כשבתמונה יש הפרה של כלל. מחליפים את ENFORCEMENT_MODE באחד מהערכים הבאים:

    • ‫ENFORCED_BLOCK_AND_AUDIT_LOG: חסימת תמונות שמפירות את הכלל ורישום מידע על ההפרה ביומני הביקורת של Cloud (ברירת מחדל).
    • ‫DRYRUN_AUDIT_LOG_ONLY: מאפשר פריסה של כל התמונות, אבל רושם ביומני הביקורת של Cloud את פרטי האכיפה, כולל פרטים על הפרות.

  • ‫ATTESTOR: אם מגדירים את EVALUATION_MODE לערך REQUIRE_ATTESTATION, צריך להוסיף גם בלוק requireAttesationsBy. בבלוק, מפרטים מאמת אחד או יותר לפי מזהה המשאב. מזהה המשאב הוא בפורמט הבא:

    projects/PROJECT_ID/attestors/ATTESTOR_NAME.

    מידע נוסף על יצירת מאמתים זמין במאמר בנושא יצירת מאמתים.

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

אפשר ליצור כללים שמוגבלים לזהות של שירות רשת, לחשבון שירות של Kubernetes או למרחב שמות של Kubernetes.

הגדרת כלל עבור זהות שירות ב-Cloud Service Mesh

כדי להגדיר כלל לזהות שירות ב-Cloud Service Mesh, עורכים את הקובץ policy.yaml ומוסיפים בלוק istioServiceIdentityAdmissionRules, לדוגמה:

defaultAdmissionRule:
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
  evaluationMode: ALWAYS_DENY
globalPolicyEvaluationMode: ENABLE
istioServiceIdentityAdmissionRules:
  SERVICE_IDENTITY_ID:
    enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
    evaluationMode: ENFORCEMENT_MODE
    requireAttestationsBy:
    - <var>ATTESTOR</var>
    - ...

name: projects/PROJECT_ID/policy

מחליפים את מה שכתוב בשדות הבאים:

  • ‫SERVICE_IDENTITY_ID: זהות השירות של Cloud Service Mesh שהכלל הזה חל עליה. זה הפורמט של זהות השירות: PROJECT_ID.svc.id.goog/ns/NAMESPACE/sa/SERVICE_ACCOUNT. במזהה זהות השירות, מחליפים את הערכים הבאים:

    • ‫PROJECT_ID: מזהה הפרויקט שבו מוגדרים משאבי Kubernetes.
    • ‫NAMESPACE: מרחב השמות של Kubernetes.
    • ‫SERVICE_ACCOUNT: חשבון השירות.

  • ‫EVALUATION_MODE: מצב ההערכה מציין את סוג האילוץ שמנגנון האכיפה של Binary Authorization אוכף בזמן הפריסה. מחליפים את EVALUATION_MODE באחת מהאפשרויות הבאות:

    • ‫ALWAYS_ALLOW: מאפשר פריסה של כל התמונות.
    • ‫ALWAYS_DENY: לא מאפשרת פריסה של תמונות.
    • ‫REQUIRE_ATTESTATION: מאפשר פריסה של תמונה אם יש לה אישור אחד או יותר שאפשר לאמת באמצעות כל המאמתים שמוסיפים לכלל הזה. בזמן הפריסה, האוכף מאמת את האישור באמצעות המאמתים שמוסיפים לרשימת ATTESTOR בכלל הזה. במאמר יצירת מאמתים מוסבר איך ליצור מאמתים. אם מציינים את הערך REQUIRE_ATTESTATION, צריך להוסיף גם בלוק requireAttestationsBy שמכיל לפחות גורם מאמת (attestor) אחד. במאמר יצירת מאמתים מוסבר איך ליצור מאמתים.

  • ‫ENFORCEMENT_MODE: מצב האכיפה מציין איך הכלי לאכיפת הכללים מגיב כשבתמונה יש הפרה של כלל. מחליפים את ENFORCEMENT_MODE באחד מהערכים הבאים:

    • ‫ENFORCED_BLOCK_AND_AUDIT_LOG: חסימת תמונות שמפירות את הכלל ורישום מידע על ההפרה ביומני הביקורת של Cloud (ברירת מחדל).
    • ‫DRYRUN_AUDIT_LOG_ONLY: מאפשר פריסה של כל התמונות, אבל רושם ביומני הביקורת של Cloud את פרטי האכיפה, כולל פרטים על הפרות.

  • ‫ATTESTOR: אם מגדירים את EVALUATION_MODE לערך REQUIRE_ATTESTATION, צריך להוסיף גם בלוק requireAttesationsBy. בבלוק, מפרטים מאמת אחד או יותר לפי מזהה המשאב. מזהה המשאב הוא בפורמט הבא:

    projects/PROJECT_ID/attestors/ATTESTOR_NAME.

    מידע נוסף על יצירת מאמתים זמין במאמר בנושא יצירת מאמתים.

הגדרת כלל לחשבון שירות של Kubernetes

כדי להגדיר כלל לחשבון שירות של Kubernetes, עורכים את הקובץ policy.yaml ומוסיפים בלוק kubernetesServiceAccountAdmissionRules, לדוגמה:

defaultAdmissionRule:
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
  evaluationMode: ALWAYS_DENY
globalPolicyEvaluationMode: ENABLE
kubernetesServiceAccountAdmissionRules:
  KUBERNETES_SERVICE_ACCOUNT_ID:
    enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
    evaluationMode: ENFORCEMENT_MODE
    requireAttestationsBy:
    - <var>ATTESTOR</var>
    - ...
name: projects/PROJECT_ID/policy

מחליפים את מה שכתוב בשדות הבאים:

  • KUBERNETES_SERVICE_ACCOUNT_ID: חשבון השירות ב-Kubernetes שהכלל יחול עליו. מזהה חשבון השירות הוא בפורמט: NAMESPACE:SERVICE_ACCOUNT. במזהה חשבון השירות, מחליפים את הרכיבים הבאים:

    • ‫NAMESPACE: מרחב השמות של Kubernetes.
    • ‫SERVICE_ACCOUNT: השם של חשבון השירות.

  • ‫EVALUATION_MODE: מצב ההערכה מציין את סוג האילוץ שמנגנון האכיפה של Binary Authorization אוכף בזמן הפריסה. מחליפים את EVALUATION_MODE באחת מהאפשרויות הבאות:

    • ‫ALWAYS_ALLOW: מאפשר פריסה של כל התמונות.
    • ‫ALWAYS_DENY: לא מאפשרת פריסה של תמונות.
    • ‫REQUIRE_ATTESTATION: מאפשר פריסה של תמונה אם יש לה אישור אחד או יותר שאפשר לאמת באמצעות כל המאמתים שמוסיפים לכלל הזה. בזמן הפריסה, האוכף מאמת את האישור באמצעות המאמתים שמוסיפים לרשימת ATTESTOR בכלל הזה. במאמר יצירת מאמתים מוסבר איך ליצור מאמתים. אם מציינים את הערך REQUIRE_ATTESTATION, צריך להוסיף גם בלוק requireAttestationsBy שמכיל לפחות גורם מאמת (attestor) אחד. במאמר יצירת מאמתים מוסבר איך ליצור מאמתים.

  • ‫ENFORCEMENT_MODE: מצב האכיפה מציין איך הכלי לאכיפת הכללים מגיב כשבתמונה יש הפרה של כלל. מחליפים את ENFORCEMENT_MODE באחד מהערכים הבאים:

    • ‫ENFORCED_BLOCK_AND_AUDIT_LOG: חסימת תמונות שמפירות את הכלל ורישום מידע על ההפרה ביומני הביקורת של Cloud (ברירת מחדל).
    • ‫DRYRUN_AUDIT_LOG_ONLY: מאפשר פריסה של כל התמונות, אבל רושם ביומני הביקורת של Cloud את פרטי האכיפה, כולל פרטים על הפרות.

  • ‫ATTESTOR: אם מגדירים את EVALUATION_MODE לערך REQUIRE_ATTESTATION, צריך להוסיף גם בלוק requireAttesationsBy. בבלוק, מפרטים מאמת אחד או יותר לפי מזהה המשאב. מזהה המשאב הוא בפורמט הבא:

    projects/PROJECT_ID/attestors/ATTESTOR_NAME.

    מידע נוסף על יצירת מאמתים זמין במאמר בנושא יצירת מאמתים.

הגדרת כלל למרחב שמות של Kubernetes

כדי להגדיר כלל למרחב שמות של Kubernetes, עורכים את הקובץ policy.yaml ומוסיפים בלוק kubernetesNamespaceAdmissionRules, לדוגמה:

defaultAdmissionRule:
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
  evaluationMode: ALWAYS_DENY
globalPolicyEvaluationMode: ENABLE
kubernetesNamespaceAdmissionRules:
  KUBERNETES_NAMESPACE:
    enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
    evaluationMode: EVALUATION_MODE
    requireAttestationsBy:
    - <var>ATTESTOR</var>
    - ...
name: projects/PROJECT_ID/policy

מחליפים את מה שכתוב בשדות הבאים:

  • ‫KUBERNETES_NAMESPACE: מרחב השמות ב-Kubernetes שאליו מוגבלת ההגדרה של הכלל הזה.

  • ‫EVALUATION_MODE: מצב ההערכה מציין את סוג האילוץ שמנגנון האכיפה של Binary Authorization אוכף בזמן הפריסה. מחליפים את EVALUATION_MODE באחת מהאפשרויות הבאות:

    • ‫ALWAYS_ALLOW: מאפשר פריסה של כל התמונות.
    • ‫ALWAYS_DENY: לא מאפשרת פריסה של תמונות.
    • ‫REQUIRE_ATTESTATION: מאפשר פריסה של תמונה אם יש לה אישור אחד או יותר שאפשר לאמת באמצעות כל המאמתים שמוסיפים לכלל הזה. בזמן הפריסה, האוכף מאמת את האישור באמצעות המאמתים שמוסיפים לרשימת ATTESTOR בכלל הזה. במאמר יצירת מאמתים מוסבר איך ליצור מאמתים. אם מציינים את הערך REQUIRE_ATTESTATION, צריך להוסיף גם בלוק requireAttestationsBy שמכיל לפחות גורם מאמת (attestor) אחד. במאמר יצירת מאמתים מוסבר איך ליצור מאמתים.

  • ‫ENFORCEMENT_MODE: מצב האכיפה מציין איך הכלי לאכיפת הכללים מגיב כשבתמונה יש הפרה של כלל. מחליפים את ENFORCEMENT_MODE באחד מהערכים הבאים:

    • ‫ENFORCED_BLOCK_AND_AUDIT_LOG: חסימת תמונות שמפירות את הכלל ורישום מידע על ההפרה ביומני הביקורת של Cloud (ברירת מחדל).
    • ‫DRYRUN_AUDIT_LOG_ONLY: מאפשר פריסה של כל התמונות, אבל רושם ביומני הביקורת של Cloud את פרטי האכיפה, כולל פרטים על הפרות.

  • ‫ATTESTOR: אם מגדירים את EVALUATION_MODE לערך REQUIRE_ATTESTATION, צריך להוסיף גם בלוק requireAttesationsBy. בבלוק, מפרטים מאמת אחד או יותר לפי מזהה המשאב. מזהה המשאב הוא בפורמט הבא:

    projects/PROJECT_ID/attestors/ATTESTOR_NAME.

    מידע נוסף על יצירת מאמתים זמין במאמר בנושא יצירת מאמתים.

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

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

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

gcloud container binauthz policy import /tmp/policy.yaml

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