יצירת מאמתים באמצעות מסוף Google Cloud

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

משתמשי Cloud Build: במקום זאת, אתם יכולים להשתמש בbuilt-by-cloud-build מאמת כדי לפרוס רק תמונות שנוצרו על ידי Cloud Build.

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

לפני שיוצרים מאמתים, צריך:

1. מפעילים את Binary Authorization.

2. מגדירים Binary Authorization לפלטפורמה.

סקירה כללית

גורם מאמת הוא Google Cloud משאב שמשמש את Binary Authorization לאימות אימות (attestation). מידע נוסף על Binary Authorization זמין במאמר סקירה כללית על Binary Authorization.

כדי ליצור מאמת:

• מגדירים זוג מפתחות שאפשר להשתמש בו כדי לחתום על תמונה, ליצור אישור, ולאחר מכן לאמת את התמונה, כשהיא נפרסת. זוגות מפתחות PKIX הם זוגות מפתחות שנוצרים על ידי Cloud Key Management Service ‏(Cloud KMS) בפורמט שתואם ל-PKIX.
• יוצרים את המאמת עצמו ב-Binary Authorization ומשייכים אליו את המפתח הציבורי שיצרתם

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

הגדרת מפתחות קריפטוגרפיים

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

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

יצירה של צמד מפתחות PKIX

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

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

זוגות המפתחות האסימטריים שנוצרו ואוחסנו ב-Cloud KMS תואמים לפורמט PKIX. כדי ליצור מפתח Cloud KMS לשימוש עם Binary Authorization, אפשר לעיין במאמר בנושא יצירת מפתחות אסימטריים. כשיוצרים את המפתח, חשוב לבחור באפשרות Asymmetric Sign (חתימה אסימטרית) בתור מטרת המפתח.

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

PKIX (Cloud KMS)

כדי ליצור את זוג המפתחות ב-Cloud KMS, מבצעים את הפעולות הבאות:

1. מגדירים את משתני הסביבה שנדרשים ליצירת זוג המפתחות.

   KMS_KEY_PROJECT_ID=${PROJECT_ID}
   KMS_KEYRING_NAME=my-binauthz-keyring
   KMS_KEY_NAME=my-binauthz-kms-key-name
   KMS_KEY_LOCATION=global
   KMS_KEY_PURPOSE=asymmetric-signing
   KMS_KEY_ALGORITHM=ec-sign-p256-sha256
   KMS_PROTECTION_LEVEL=software
   KMS_KEY_VERSION=1
   

2. יוצרים את אוסף המפתחות.

   gcloud kms keyrings create ${KMS_KEYRING_NAME} \
     --location ${KMS_KEY_LOCATION}
   

3. יוצרים את המפתח:

   gcloud kms keys create ${KMS_KEY_NAME} \
     --location ${KMS_KEY_LOCATION} \
     --keyring ${KMS_KEYRING_NAME}  \
     --purpose ${KMS_KEY_PURPOSE} \
     --default-algorithm ${KMS_KEY_ALGORITHM} \
     --protection-level ${KMS_PROTECTION_LEVEL}
   

PKIX (מפתח מקומי)

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

כדי ליצור זוג מפתחות PKIX אסימטריים מקומיים חדשים ולאחסן אותם בקובץ, מבצעים את הפעולות הבאות:

1. יוצרים את המפתח:

   PRIVATE_KEY_FILE="/tmp/ec_private.pem"
   openssl ecparam -genkey -name prime256v1 -noout -out ${PRIVATE_KEY_FILE}
   

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

   PUBLIC_KEY_FILE="/tmp/ec_public.pem"
   openssl ec -in ${PRIVATE_KEY_FILE} -pubout -out ${PUBLIC_KEY_FILE}
   

יצירת גורם מאמת

השלב הבא הוא ליצור את הגורם המאמת (attestor) עצמו ולשייך לו Artifact Analysis ומפתח ציבורי.

ב-Binary Authorization נעשה שימוש בArtifact Analysis כדי לאחסן מטא-נתונים מהימנים שמשמשים בתהליך ההרשאה. לכל גורם מאמת (attestor) שיוצרים, צריך ליצור הערה אחת של Artifact Analysis. כל אישור נשמר כמופע של ההערה הזו.

כדי ליצור את המאמת:

1. עוברים לדף Binary Authorization של פרויקט גורם מאמת (attestor).

   מעבר אל Binary Authorization

2. בכרטיסייה Attestors, לוחצים על Create.

3. לוחצים על יצירת מאשר חדש.

4. בקטע Attestor Name, מזינים שם למאשר (לדוגמה, build-secure או prod-qa).

5. כדי להוסיף את המפתח הציבורי למאמת:

   PKIX (מפתח מקומי)

   1. לוחצים על הוספת מפתח PKIX.
   2. לוחצים על ייבוא מקובץ.
   3. מנווטים אל קובץ מפתח PKIX ששמרתם קודם ובוחרים בו. הערה: אפשר גם להדביק מפתח ציבורי בפורמט PEM.
   4. בוחרים את אלגוריתם החתימה. המפתח לדוגמה במדריך הזה נוצר באמצעות האלגוריתם Elliptic Curve P256 - SHA Digest.

   PKIX (Cloud KMS)

   1. לוחצים על הוספת מפתח PKIX.
   2. לוחצים על ייבוא מ-Cloud KMS.

   3. בחלון שנפתח, מזינים את מזהה המשאב של גרסת המפתח. הפורמט של מזהה המשאב הוא:

      projects/KMS_KEY_PROJECT_ID/locations/KMS_KEY_LOCATION/keyRings/KMS_KEYRING_NAME/cryptoKeys/KMS_KEY_NAME/cryptoKeyVersions/KMS_KEY_VERSION
      

      where:

      • ‫KMS_KEY_PROJECT_ID הוא מזהה הפרויקט שבו מאוחסנים המפתחות.
      • ‫KMS_KEY_LOCATION הוא המיקום של המפתח (global הוא ברירת המחדל)
      • ‫KMS_KEYRING_NAME הוא השם של אוסף המפתחות.
      • ‫KMS_KEY_NAME הוא שם המפתח
      • ‫KMS_KEY_VERSION היא גרסת המפתח

      אם יצרתם זוג מפתחות Cloud KMS באמצעות משתני הסביבה לדוגמה שבדף הזה, תוכלו להציג את מזהה המשאב באמצעות הפקודה הבאה:

      ‫

      echo projects/${KMS_KEY_PROJECT_ID}/locations/${KMS_KEY_LOCATION}/keyRings/${KMS_KEYRING_NAME}/cryptoKeys/${KMS_KEY_NAME}/cryptoKeyVersions/${KMS_KEY_VERSION}
      

      כדי להוסיף את המפתח, צריכה להיות לכם הרשאת `cloudkms.publicKeyViewer` במשאב המפתח.

   4. לוחצים על שליחה.

6. אם רוצים להשתמש בהערה קיימת שיצרתם בעבר, מרחיבים את הקטע הגדרות מתקדמות.

   1. מבטלים את הסימון של האפשרות יצירת הערה של Artifact Analysis באופן אוטומטי הערה.

   2. מזינים את השם המלא בשדה Artifact Analysis Note ID (מזהה הערה של ניתוח ארטיפקט). השם צריך להיות בפורמט projects/PROJECT_ID/notes/NOTE_ID.

7. לוחצים על יצירה.

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

כדי לוודא שגורם מאמת (attestor) נוצר:

1. חוזרים לדף Binary Authorization במסוף Google Cloud .

2. פותחים את הכרטיסייה מאשרים.

הגדרה של כמה פרויקטים

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

הוספת קישור תפקידים ב-IAM לפרויקט הפריסה

צריך להוסיף את חשבון השירות של פרויקט הפריסה ל-attestor כ-IAM role binding. ההרשאה הזו משמשת את Binary Authorization כשהיא מעריכה מדיניות כדי לקבוע אם לחשבון יש הרשאות גישה למאמת.

צריך להוסיף את קישור התפקיד ב-IAM משורת הפקודה, כי השלב הזה לא נתמך במסוף Google Cloud .

כדי להוסיף את קישור התפקידים ב-IAM:

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

   DEPLOYER_PROJECT_ID=PROJECT_ID
   DEPLOYER_PROJECT_NUMBER="$(
       gcloud projects describe "${DEPLOYER_PROJECT_ID}" \
         --format="value(projectNumber)"
   )"
   

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

   DEPLOYER_SERVICE_ACCOUNT="service-${DEPLOYER_PROJECT_NUMBER}@gcp-sa-binaryauthorization.iam.gserviceaccount.com"
   

3. מוסיפים את קישור התפקידים ב-IAM:

   gcloud --project ATTESTOR_PROJECT_ID \
       beta container binauthz attestors add-iam-policy-binding \
       "projects/ATTESTOR_PROJECT_ID/attestors/ATTESTOR" \
       --member="serviceAccount:${DEPLOYER_SERVICE_ACCOUNT}" \
       --role=roles/binaryauthorization.attestorsVerifier
   

הוספת קישור תפקידים ב-IAM למשתמש שמגדיר את Binary Authorization

צריך להוסיף קשירת תפקיד IAM למשתמש שמוסיף גורם מאמת (attestor) למדיניות Binary Authorization בפרויקט של כלי הפריסה, כי למשתמש צריכה להיות הרשאה לצפייה בגורם המאמת (attestor) כדי להוסיף אותו. אם רוצים, אפשר לבטל את ההרשאה הזו בבטחה אחרי שמוסיפים את המאמת.

בנוסף, צריך להוסיף את הקישור של תפקיד IAM משורת הפקודה, כי השלב הזה לא נתמך במסוף Google Cloud .

כדי להוסיף את קישור התפקידים ב-IAM:

gcloud --project ATTESTOR_PROJECT_ID \
    beta container binauthz attestors add-iam-policy-binding \
    "projects/ATTESTOR_PROJECT_ID/attestors/ATTESTOR" \
    --member=ADMIN_EMAIL_ACCOUNT \
    --role=roles/binaryauthorization.attestorsViewer

כדי להסיר את הקישור בין תפקיד ה-IAM לבין המאמת אחרי שהמאמת נוסף:

gcloud --project ATTESTOR_PROJECT_ID \
    beta container binauthz attestors remove-iam-policy-binding \
    "projects/ATTESTOR_PROJECT_ID/attestors/ATTESTOR" \
    --member=ADMIN_EMAIL_ACCOUNT \
    --role=roles/binaryauthorization.attestorsViewer

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

• איך יוצרים אימותים (attestations) בשביל גורם מאמת (attestor).
• מעדכנים את מדיניות Binary Authorization כדי לדרוש אישורים באמצעות מסוףGoogle Cloud ,‏ Google Cloud CLI ו-API בארכיטקטורת REST.