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

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

מידע נוסף:

• מבוא כללי ל-Binary Authorization
• Codelab: אבטחה של פריסות GKE באמצעות Binary Authorization

ארכיטקטורה

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

בצינור עיבוד הנתונים הזה:

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

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

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

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

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

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

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

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

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

• צפייה בגורמים מאמתים ב-Binary Authorization
  • roles/binaryauthorization.attestorsViewer
• חתימה/אימות של CryptoKey ב-Cloud KMS (אם משתמשים במפתח ב-KMS כדי לחתום על אישור)
  • roles/cloudkms.signerVerifier
• צירוף מופעי Artifact Analysis להערות
  • 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" לחשבון השירות של Cloud Build:

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

6. הוספת התפקיד "מפענח/מצפין של מפתח הצפנה ב-Cloud KMS" לחשבון השירות של 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" לחשבון השירות של 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:

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

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

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

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

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

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

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

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

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

מוסיפים שלב create-attestation ל-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
   

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

• יצירת שלב מותאם אישית ב-Cloud Build כדי לחתום על אישורים של Binary Authorization ולהעלות אותם ב-GitHub.