יצירת אישור ב-Binary Authorization בצינור Cloud Build

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

סקירה כללית על Cloud Build

‫Cloud Build (סקירה כללית) לוקח קוד מקור שמאוחסן במאגר מארח, מריץ את גרסאות ה-build והבדיקות שלכם ומאחסן את פלט התוכנה שמתקבל ב-Container Registry או בשירות אחסון אחר ב-Google Cloud Platform.

סקירה כללית על Binary Authorization

‫Binary Authorization (סקירה כללית) הוא מוצר שלGoogle Cloud שמחיל אילוצים על אפליקציות בזמן הפריסה. השילוב שלו עם Google Kubernetes Engine‏ (GKE) מאפשר למשתמשים לאכוף שקונטיינרים שנפרסו באשכול Kubernetes חתומים באופן קריפטוגרפי על ידי רשות מהימנה, ומאומתים על ידי גורם מאמת (attestor) של Binary Authorization.

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

מידע נוסף:

ארכיטקטורה

התרשים הבא מציג את הרכיבים בהגדרה של Binary Authorization/Cloud Build:

פייפליין אימות (attestation) של Binary Authorization ב-Cloud Build.
תרשים 1. צינור עיבוד נתונים של Cloud Build שיוצר אישור של Binary Authorization.

בצינור הזה:

  1. קוד ליצירת קובץ אימג' של קונטיינר מועבר למאגר מקור.

  2. כלי לאינטגרציה רציפה (CI),‏ Cloud Build, יוצר ובודק את הקונטיינר.

  3. ה-build מעביר את קובץ האימג' של הקונטיינר אל Container Registry או אל מאגר אחר שבו מאוחסנים קובצי האימג' שנוצרו.

  4. ‫Cloud Key Management Service, שמספק ניהול מפתחות לזוג המפתחות הקריפטוגרפיים, חותם על קובץ האימג' של הקונטיינר. החתימה שמתקבלת נשמרת באישור חדש שנוצר.

  5. בזמן הפריסה, הגורם המאשר מאמת את האישור באמצעות המפתח הציבורי מזוג המפתחות. ‫Binary Authorization אוכף את המדיניות על ידי דרישה של אימות (attestation) חתומים כדי לפרוס את קובץ אימג' של קונטיינר.

יצירת אישור באמצעות Cloud Build עם Cloud Key Management Service

בקטע הזה מוסבר איך מטמיעים את הארכיטקטורה שלמעלה. הוא משתמש בשלב בנייה מותאם אישית בקוד פתוח מ-Cloud Build Community. שלב ה-build המותאם אישית חותם על קובץ אימג' של קונטיינר, יוצר את האימות (attestation) ומעלה אותו ל-Binary Authorization.

הגדרת ניהול זהויות והרשאות גישה (IAM)

כדי להשתמש בשלב הבנייה הזה, לחשבון השירות של Cloud Build צריכים להיות תפקידי ה-IAM הבאים:

  • Binary Authorization Attestor Viewer
    • roles/binaryauthorization.attestorsViewer
  • ‫Cloud KMS CryptoKey Signer/Verifier (אם משתמשים במפתח ב-KMS לחתימה על אישור)
    • roles/cloudkms.signerVerifier
  • Artifact Analysis Notes Attacher
    • roles/containeranalysis.notes.attacher

אפשר להשתמש בפקודות הבאות כדי להוסיף את התפקידים לחשבון השירות ב-Cloud Build שמשויך לפרויקט:

  1. מפעילים את Cloud Build:

    מפעילים את Cloud Build API בפרויקט היעד Google Cloud .

  2. שומרים את מזהה הפרויקט במשתנה סביבה:

    PROJECT_ID=PROJECT_ID

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

  3. מגדירים את הפרויקט ב-Google Cloud CLI:

    gcloud config set project ${PROJECT_ID}

  4. מקבלים את מספר הפרויקט:

    PROJECT_NUMBER=$(gcloud projects list --filter="${PROJECT_ID}" --format="value(PROJECT_NUMBER)")

  5. מוסיפים את התפקיד Binary Authorization Attestor Viewer לחשבון השירות ב-Cloud Build:

    gcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --member serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \
  --role roles/binaryauthorization.attestorsViewer

  6. הוספת התפקיד Cloud KMS CryptoKey Signer/Verifier לחשבון השירות של Cloud Build (חתימה מבוססת-KMS):

    gcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --member serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \
  --role roles/cloudkms.signerVerifier

  7. מוסיפים את התפקיד Artifact Analysis Notes Attacher לחשבון השירות של Cloud Build:

    gcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --member serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \
  --role roles/containeranalysis.notes.attacher

פיתוח ורישום של שלב ה-build המותאם אישית באמצעות Cloud Build

  1. משכפלים את מאגר הקהילה של Google Cloud Build:

    git clone https://github.com/GoogleCloudPlatform/cloud-builders-community.git

  2. מגדירים את החותם של Binary Authorization ל-Cloud Build:

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

    cd cloud-builders-community/binauthz-attestation
gcloud builds submit . --config cloudbuild.yaml

    שלב הבנייה בהתאמה אישית הועבר אל Google Container Registry של הפרויקט הנוכחי ומוכן לשימוש.

יצירת גורם מאמת (attestor) ב-Binary Authorization

יוצרים גורם מאמת (attestor) ש-Binary Authorization ישתמש בו בזמן הפריסה כדי לאמת את האימות (attestation).

הגדרה של מאמת ושל צמד מפתחות של Cloud Key Management Service ב-Binary Authorization:

איך יוצרים מאמת באמצעות ה-CLI

מוודאים שהמאמת נוצר

   gcloud --project="${ATTESTOR_PROJECT_ID}" container binauthz attestors list

הוספת שלב של יצירת אישור ל-cloudbuild.yaml

כדי להשתמש בשלב binauthz-attestation, צריך לעדכן את cloudbuild.yaml ולהוסיף את השלב שיחתום על ה-build שנשלח אל Container Registry.

בהמשך מפורטות שתי שיטות:

  • מעדכנים את cloudbuild.yaml באופן ידני.

  • מריצים צינור לדוגמה עם משתני הסביבה שהגדרתם קודם.

עדכון ידני של cloudbuild.yaml

  1. מעדכנים את cloudbuild.yaml באופן ידני על ידי הוספת שלב ה-build שבהמשך אחרי השלב שבו המאגר מועלה ל-Container Registry. הערה: צריך להחליף את ATTESTOR_NAME,‏ KMS_KEY_LOCATION,‏ KMS_KEYRING_NAME,‏ KMS_KEY_NAME ו-KMS_KEY_VERSION בערכים שלכם באופן ידני:

    - id: 'create-attestation'
  name: 'gcr.io/${PROJECT_ID}/binauthz-attestation:latest'
  args:
    - '--artifact-url'
    - 'gcr.io/${PROJECT_ID}/helloworld:latest'
    - '--attestor'
    - 'projects/${PROJECT_ID}/attestors/ATTESTOR_NAME'
    - '--keyversion'
    - 'projects/${PROJECT_ID}/locations/KMS_KEY_LOCATION/keyRings/KMS_KEYRING_NAME/cryptoKeys/KMS_KEY_NAME/cryptoKeyVersions/KMS_KEY_VERSION'

    גם המחרוזת הבאה תקינה:

    - id: 'create-attestation'
  name: 'gcr.io/${PROJECT_ID}/binauthz-attestation:latest'
  args:
    - '--artifact-url'
    - 'gcr.io/${PROJECT_ID}/helloworld:latest'
    - '--attestor'
    - 'ATTESTOR_NAME'
    - '--attestor-project'
    - '${PROJECT_ID}'
    - '--keyversion'
    - 'KEY_VERSION'
    - '--keyversion-project'
    - '${PROJECT_ID}'
    - '--keyversion-location'
    - 'KEY_LOCATION'
    - '--keyversion-keyring'
    - 'KEYRING_NAME'
    - '--keyversion-key'
    - 'KEY_NAME'

אופציונלי: בדיקת צינור הנתונים

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

  1. יוצרים קובץ cloudbuild.yaml עם משתני הסביבה שהגדרתם קודם:

    cd example
cat <<EOM > cloudbuild_example.yaml
steps:
  - id: 'build'
    name: 'gcr.io/cloud-builders/docker'
    args:
      - 'build'
      - '-t'
      - 'gcr.io/$PROJECT_ID/helloworld:latest'
      - '.'
  - id: 'publish'
    name: 'gcr.io/cloud-builders/docker'
    args:
      - 'push'
      - 'gcr.io/$PROJECT_ID/helloworld:latest'
  - id: 'create-attestation'
    name: 'gcr.io/$PROJECT_ID/binauthz-attestation:latest'
    args:
      - '--artifact-url'
      - 'gcr.io/$PROJECT_ID/helloworld:latest'
      - '--attestor'
      - 'projects/$PROJECT_ID/attestors/${ATTESTOR_NAME}'
      - '--keyversion'
      - 'projects/${PROJECT_ID}/locations/${KMS_KEY_LOCATION}/keyRings/${KMS_KEYRING_NAME}/cryptoKeys/${KMS_KEY_NAME}/cryptoKeyVersions/${KMS_KEY_VERSION}'
tags: ['cloud-builders-community']

EOM

  2. מריצים את Cloud Build עם הדוגמה cloudbuild_example.yaml:

    מהספרייה cloud-builders-community/binauthz-attestation/example, מריצים את הפקודות הבאות:

    gcloud builds submit . --config cloudbuild_example.yaml

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