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

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

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

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

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

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

    כדי להפעיל ממשקי API, נדרשת ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד 'בעלים' (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד 'אדמין בממשק Service Usage' (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים

    הפעלת ממשקי ה-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 מאמת החתימה בפרויקט, מריצים 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. חשוב לוודא שאתם מעבירים בדחיפה ל-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 הוא מזהה הפרויקט.

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

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"

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