אבטחת פריסות של תמונות ב-Cloud Run וב-Google Kubernetes Engine

בדף הזה מוסבר איך אפשר לאבטח פריסות של תמונות ב-Cloud Run וב-Google Kubernetes Engine באמצעות Cloud Build.

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

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

  1. מפעילים את ממשקי ה-API של Cloud Build,‏ Binary Authorization ו-Artifact Registry.

    תפקידים שנדרשים להפעלת ממשקי API

    כדי להפעיל ממשקי API, צריך את תפקיד ה-IAM 'אדמין של Service Usage' (roles/serviceusage.serviceUsageAdmin), שכולל את ההרשאה serviceusage.services.enable. איך מקצים תפקידים

    הפעלת ממשקי ה-API

  2. כדי להשתמש בדוגמאות של שורת הפקודה במדריך הזה, צריך להתקין ולהגדיר את Google Cloud SDK.

  3. הגדרה של Binary Authorization לפלטפורמה

שליטה בפריסות באמצעות Binary Authorization

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

‫Cloud Build יוצר וחותם על אישורים בזמן הבנייה. באמצעות built-by-cloud-build Binary Authorization, אפשר לאמת את ההצהרות ולפרוס רק קובצי אימג' שנוצרו על ידי Cloud Build.

כדי ליצור את built-by-cloud-build attestor בפרויקט, מריצים build בפרויקט הזה.

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

המסוף

  1. נכנסים לדף Binary Authorization במסוף Google Cloud :

    מעבר אל Binary Authorization

  2. בכרטיסייה מדיניות, לוחצים על עריכת המדיניות.

  3. בתיבת הדו-שיח Edit Policy (עריכת מדיניות), בוחרים באפשרות Allow only images that have been approved by all of the following attestors (אפשר להשתמש רק בתמונות שאושרו על ידי כל המאשרים הבאים).

  4. לוחצים על הוספת מאשרים.

  5. בתיבת הדו-שיח הוספת מאשרים:

    1. בוחרים באפשרות Add by project and attestor name ומבצעים את השלבים הבאים:
      1. בשדה Project name, מזינים את הפרויקט שבו מריצים את Cloud Build.
      2. לוחצים על השדה שם המאשר ורואים שהמאשר built-by-cloud-build זמין.
      3. לחץ על built-by-cloud-build.

    2. אפשר גם ללחוץ על הוספה לפי מזהה משאב של גורם מאמת (attestor). בשדה מזהה משאב המאמת, מזינים

      projects/PROJECT_ID/attestors/built-by-cloud-build

      מחליפים את PROJECT_ID בפרויקט שבו מריצים את Cloud Build.

  6. לוחצים על הוספת מאשר אחד.

  7. לוחצים על שמירת המדיניות.

gcloud

  1. מייצאים את המדיניות הקיימת לקובץ באמצעות הפקודה הבאה:

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

  2. עורכים את קובץ המדיניות.

  3. עורכים אחד מהכללים הבאים:

    • defaultAdmissionRule
    • clusterAdmissionRules
    • istioServiceIdentityAdmissionRules
    • kubernetesServiceAccountAdmissionRules

  4. מוסיפים בלוק requireAttestationsBy לכלל אם הוא לא קיים כבר.

  5. בבלוק requireAttestationsBy, מוסיפים

    projects/PROJECT_ID/attestors/built-by-cloud-build

    מחליפים את PROJECT_ID בפרויקט שבו מריצים את Cloud Build.

  6. שומרים את קובץ המדיניות.

  7. מייבאים את קובץ המדיניות.

    gcloud container binauthz policy import /tmp/policy.yaml

    קובץ מדיניות לדוגמה שמכיל את ההפניה אל built-by-cloud-build-attestor:

    defaultAdmissionRule:
  evaluationMode: REQUIRE_ATTESTATION
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
  requireAttestationsBy:
    - projects/PROJECT_ID/attestors/built-by-cloud-build
name: projects/PROJECT_ID/policy

    מחליפים את PROJECT_ID במזהה הפרויקט שבו מריצים את Cloud Build.

אפשר לראות שגיאות במדיניות בהודעות היומן של Binary Authorization עבור GKE או Cloud Run.

שימוש במצב פרימטר לבדיקות

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

כדי להפעיל הרצה יבשה:

המסוף

  1. נכנסים לדף Binary Authorization במסוף Google Cloud .

    עוברים אל Binary Authorization.

  2. לוחצים על עריכת המדיניות.

  3. בכלל ברירת המחדל או בכלל ספציפי, בוחרים באפשרות מצב הרצה יבשה.

  4. לוחצים על שמירת המדיניות.

gcloud

  1. מייצאים את מדיניות Binary Authorization לקובץ YAML:

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

  2. בכלי לעריכת טקסט, מגדירים את enforcementMode ל-DRYRUN_AUDIT_LOG_ONLY ושומרים את הקובץ.

    אסור להשתמש בהן וההפרות מתועדות.

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

    gcloud container binauthz policy import /tmp/policy.yaml

אפשר לראות שגיאות במדיניות בהודעות היומן של Binary Authorization עבור GKE או Cloud Run

מגבלות

  • שירותי Cloud Build ו-Binary Authorization צריכים להיות באותו פרויקט. אם אתם מריצים את פלטפורמת הפריסה בפרויקט אחר, אתם צריכים להגדיר תפקידי IAM להגדרה של כמה פרויקטים, ולהפנות לפרויקט Cloud Build כשאתם מוסיפים את מאמת built-by-cloud-build ב-Binary Authorization.

  • ‫Cloud Build לא יוצר אישורים כשמעבירים בדחיפה קובצי אימג' ל-Artifact Registry באמצעות שלב build מפורש docker push. חשוב לוודא שאתם מבצעים push ל-Artifact Registry באמצעות השדה images בשלב ה-build של docker build. מידע נוסף על images זמין במאמר דרכים שונות לאחסון תמונות ב-Artifact Registry.

  • צריך להשתמש בקובצי הגדרות נפרדים לבנייה עבור צינור עיבוד הנתונים לבנייה וצינור עיבוד הנתונים לפריסה. הסיבה לכך היא ש-Cloud Build יוצר אישורים רק אחרי שצינור ה-Build מסתיים בהצלחה. לאחר מכן, Binary Authorization יבדוק את האישור לפני פריסת התמונה.

הפעלת אישורים במאגרי כתובות פרטיים

כברירת מחדל, Cloud Build לא יוצר אישורים של Binary Authorization עבור build במאגרי build פרטיים. כדי ליצור אישורים, מוסיפים את האפשרות requestedVerifyOption: VERIFIED לקובץ הגדרות ה-build:

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: [ 'build', '-t', 'us-central1-docker.pkg.dev/$PROJECT_ID/quickstart-docker-repo/quickstart-image:tag1', '.' ]
images:
- 'us-central1-docker.pkg.dev/$PROJECT_ID/quickstart-docker-repo/quickstart-image:tag1'
options:
  requestedVerifyOption: VERIFIED

אחרי שמוסיפים את requestedVerifyOption, ‏ Cloud Build מפעיל יצירת אישורים ומטא-נתונים של מקור לתמונה.

הצגת המטא-נתונים של המאמת

גורם מאמת (attestor) נוצר בפעם הראשונה שמריצים build בפרויקט. מזהה המאשר הוא מהצורה projects/PROJECT_ID/attestors/built-by-cloud-build, כאשר PROJECT_ID הוא מזהה הפרויקט.

אפשר לבדוק את המטא-נתונים של מאמת הבנייה באמצעות הפקודה הבאה:

curl -X GET -H "Content-Type: application/json" \
    -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    https://binaryauthorization.googleapis.com/v1beta1/projects/PROJECT_ID/attestors/built-by-cloud-build

מחליפים את PROJECT_ID בפרויקט שבו מריצים את Cloud Build.

הפלט מכיל מידע על הגורם המעיד ועל המפתחות הציבוריים התואמים. לדוגמה:

name": "projects/PROJECT_ID/attestors/built-by-cloud-build",
  "userOwnedDrydockNote": {
    "noteReference": "projects/PROJECT_ID/notes/built-by-cloud-build",
    "publicKeys": [
      {
        "id": "//cloudkms.googleapis.com/v1/projects/verified-builder/locations/asia/keyRings/attestor/cryptoKeys/builtByGCB/cryptoKeyVersions/1",
        "pkixPublicKey": {
          "publicKeyPem": "-----BEGIN PUBLIC KEY-----\nMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEMMvFxZLgIiWOLIXsaTkjTmOKcaK7\neIZrgpWHpHziTFGg8qyEI4S8O2/2wh1Eru7+sj0Sh1QxytN/KE5j3mTvYA==\n-----END PUBLIC KEY-----\n",
          "signatureAlgorithm": "ECDSA_P256_SHA256"
        }
      },
...
      }
    ],
    "delegationServiceAccountEmail": "service-942118413832@gcp-binaryauthorization.iam.gserviceaccount.com"
  },
  "updateTime": "2021-09-24T15:26:44.808914Z",
  "description": "Attestor autogenerated by build ID fab07092-30f4-4f70-caf7-4545cbc404d6"

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