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

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

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

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

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

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

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

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

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

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

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

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

הגדרת סביבת הפרויקט

בקטע הזה מגדירים משתני סביבה.

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

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

ATTESTOR_PROJECT_ID=ATTESTOR_PROJECT_ID
ATTESTOR_PROJECT_NUMBER="$(
    gcloud projects describe "${ATTESTOR_PROJECT_ID}" \
    --format="value(projectNumber)"
)"

צריך גם לקבל את השמות של חשבונות השירות בפרויקטים:

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

יצירת הערה ב-Artifact Analysis

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

כדי ליצור את ההערה, פועלים לפי השלבים הבאים:

1. מגדירים משתני סביבה לאחסון מזהה ההערה ותיאור שקל לקרוא:

   NOTE_ID=NOTE_ID
   NOTE_URI="projects/${ATTESTOR_PROJECT_ID}/notes/${NOTE_ID}"
   DESCRIPTION=DESCRIPTION
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫NOTE_ID: השם הפנימי של ההערה בתווים אלפאנומריים ללא רווחים – לדוגמה, test-attestor-note
   • ‫NOTE_URI: הנתיב המלא למשאב של ההערה
   • ‫DESCRIPTION: שם תצוגה קריא לאנשים של ההערה, לדוגמה Test Attestor Note

2. יוצרים קובץ JSON שמתאר את ההערה:

   cat > /tmp/note_payload.json << EOF
   {
     "name": "${NOTE_URI}",
     "attestation": {
       "hint": {
         "human_readable_name": "${DESCRIPTION}"
       }
     }
   }
   EOF
   

3. יוצרים את ההערה על ידי שליחת בקשת HTTP אל Artifact Analysis API בארכיטקטורת REST:

   curl -X POST \
       -H "Content-Type: application/json" \
       -H "Authorization: Bearer $(gcloud auth print-access-token)"  \
       -H "x-goog-user-project: ${ATTESTOR_PROJECT_ID}" \
       --data-binary @/tmp/note_payload.json  \
       "https://containeranalysis.googleapis.com/v1/projects/${ATTESTOR_PROJECT_ID}/notes/?noteId=${NOTE_ID}"
   

   זהירות: Binary Authorization לא תומך ב-Artifact Analysis באחסון אזורי או בנקודות קצה אזוריות. מומלץ להשתמש בנקודת קצה ל-API הגלובלית של Artifact Analysis ‏ (https://containeranalysis.googleapis.com/).

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

   curl \
       -H "Authorization: Bearer $(gcloud auth print-access-token)"  \
       -H "x-goog-user-project: ${ATTESTOR_PROJECT_ID}" \
       "https://containeranalysis.googleapis.com/v1/projects/${ATTESTOR_PROJECT_ID}/notes/"
   

הגדרת הרשאות IAM להערה

צריך להקצות תפקיד בממשק לניהול הזהויות והרשאות הגישה (IAM) לחשבון השירות של פרויקט המאמת במשאב ההערה של Artifact Analysis. כדי לעשות זאת, מוסיפים את חשבון השירות של פרויקט המאמת לתפקיד containeranalysis.notes.occurrences.viewer במדיניות IAM של ההערה.

כדי להוסיף את התפקיד:

1. יוצרים קובץ JSON שמכיל את המידע שנדרש להגדרת תפקיד IAM בהערה:

   cat > /tmp/iam_request.json << EOM
   {
     "resource": "${NOTE_URI}",
     "policy": {
       "bindings": [
         {
           "role": "roles/containeranalysis.notes.occurrences.viewer",
           "members": [
             "serviceAccount:${ATTESTOR_SERVICE_ACCOUNT}"
           ]
         }
       ]
     }
   }
   EOM
   

2. מוסיפים את חשבון השירות ואת תפקידי הגישה המבוקשים למדיניות ה-IAM של ההערה שיצרתם:

   curl -X POST  \
       -H "Content-Type: application/json" \
       -H "Authorization: Bearer $(gcloud auth print-access-token)" \
       -H "x-goog-user-project: ${ATTESTOR_PROJECT_ID}" \
       --data-binary @/tmp/iam_request.json \
       "https://containeranalysis.googleapis.com/v1/projects/${ATTESTOR_PROJECT_ID}/notes/${NOTE_ID}:setIamPolicy"
   

   הערה: כשמוסיפים תפקיד למדיניות באמצעות השיטה הקודמת, הוא מחליף את כל התפקידים הקיימים בהערה. אם רוצים לשמור את התפקידים הקיימים, צריך לוודא שהם כלולים בקובץ הנתונים הקודם בפורמט JSON.

שימוש בכמה פרויקטים

אם מאחסנים את המאמת בפרויקט אחד ומבצעים פריסה בפרויקט נפרד, צריך להעניק את התפקיד roles/binaryauthorization.attestorsVerifier לחשבון השירות שמשויך לפרויקט הפריסה במאמת.

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

Binary Authorization מאפשרת להשתמש במפתחות PKIX או במפתחות הצפנה פוסט-קוונטית (PQC) כדי לאמת אימותים (attestations). צריך להגדיר רק סוג אחד של מפתח באחת מהשיטות הבאות:

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

יצירת מפתחות להצפנה פוסט-קוונטית (PQC)

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

• אלגוריתמים נתמכים: Binary Authorization תומך באלגוריתמים של חתימת PQC, כמו ML-DSA-65 ‏ (Dilithium3), ליצירה ולאימות של הצהרות.
• ניהול מפתחות: מומלץ לנהל את מפתחות ה-PQC באמצעות Cloud Key Management Service. ‫Cloud KMS מספק אחסון וניהול מאובטחים של המפתחות הקריפטוגרפיים האלה.

יצירת זוג מפתחות PQC

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

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

       KMS_KEY_PROJECT_ID=KMS_KEY_PROJECT_ID
       KMS_KEY_LOCATION=KMS_KEY_LOCATION
       KMS_KEYRING_NAME=KMS_KEYRING_NAME
       KMS_KEY_NAME=KMS_KEY_NAME
       KMS_KEY_VERSION=KMS_KEY_VERSION
       KMS_KEY_PURPOSE=asymmetric-signing
       KMS_KEY_ALGORITHM=KMS_KEY_ALGORITHM
       KMS_PROTECTION_LEVEL=KMS_PROTECTION_LEVEL
     

2. מחליפים את מה שכתוב בשדות הבאים:

   • ‫KMS_KEY_PROJECT_ID: מזהה הפרויקט שבו שמורים המפתחות
   • ‫KMS_KEY_LOCATION: המיקום של המפתח
   • ‫KMS_KEYRING_NAME: השם של אוסף המפתחות
   • ‫KMS_KEY_NAME: השם של המפתח
   • ‫KMS_KEY_VERSION: גרסת המפתח
   • ‫KMS_KEY_ALGORITHM: האלגוריתם; ml-dsa-65
   • ‫KMS_PROTECTION_LEVEL: רמת ההגנה, למשל software

3. כדי ליצור את מחזיק המפתחות, מריצים את הפקודה הבאה:

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

4. כדי ליצור את המפתח, מריצים את הפקודה הבאה:

     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}
   

יצירת צמד מפתחות

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

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

PKIX (Cloud KMS)

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

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

   KMS_KEY_PROJECT_ID=KMS_KEY_PROJECT_ID
   KMS_KEY_LOCATION=KMS_KEY_LOCATION
   KMS_KEYRING_NAME=KMS_KEYRING_NAME
   KMS_KEY_NAME=KMS_KEY_NAME
   KMS_KEY_VERSION=KMS_KEY_VERSION
   KMS_KEY_PURPOSE=asymmetric-signing
   KMS_KEY_ALGORITHM=KMS_KEY_ALGORITHM
   KMS_PROTECTION_LEVEL=KMS_PROTECTION_LEVEL
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫KMS_KEY_PROJECT_ID: המזהה של הפרויקט שבו המפתחות מאוחסנים
   • ‫KMS_KEY_LOCATION: המיקום של המפתח
   • ‫KMS_KEYRING_NAME: השם של אוסף המפתחות
   • ‫KMS_KEY_NAME: השם של המפתח
   • ‫KMS_KEY_VERSION: גרסת המפתח
   • ‫KMS_KEY_ALGORITHM: האלגוריתם; מומלץ להשתמש ב-ec-sign-p256-sha256
   • ‫KMS_PROTECTION_LEVEL: רמת ההגנה, לדוגמה software

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}
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫KMS_KEY_NAME: השם של המפתח
   • ‫KMS_KEY_LOCATION: המיקום של המפתח
   • ‫KMS_KEYRING_NAME: השם של אוסף המפתחות
   • ‫KMS_KEY_PURPOSE: מטרת המפתח, מוגדרת ל-ASYMMETRIC_SIGN
   • ‫KMS_KEY_ALGORITHM: האלגוריתם, מומלץ להשתמש ב-ec-sign-p256-sha256
   • ‫KMS_PROTECTION_LEVEL: רמת ההגנה, לדוגמה software

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

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

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

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

   ‫PRIVATE_KEY_FILE הוא שם הקובץ שמכיל את המפתח הפרטי שמשמש לחתימה על מטען הייעודי (payload) של האישור.

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

2. מחלקים את המפתח הפרטי למפתח ציבורי ומאחסנים אותו בקובץ:

   ‫PUBLIC_KEY_FILE הוא שם הקובץ שמכיל את המפתח הציבורי שמאוחסן בבודק.

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

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

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

1. מגדירים משתנה סביבה לאחסון השם של המאמת כפי שהוא מוגדר ב-Binary Authorization:

   ATTESTOR_NAME=ATTESTOR_NAME
   

   מחליפים את ATTESTOR_NAME בשם של גורם מאמת (attestor) שרוצים ליצור (לדוגמה, build-secure או prod-qa).

2. יוצרים את משאב המאשר ב-Binary Authorization:

   gcloud --project="${ATTESTOR_PROJECT_ID}" \
       container binauthz attestors create "${ATTESTOR_NAME}" \
       --attestation-authority-note="${NOTE_ID}" \
       --attestation-authority-note-project="${ATTESTOR_PROJECT_ID}"
   

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

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

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

   PKIX (Cloud KMS)

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

   gcloud --project="${ATTESTOR_PROJECT_ID}" \
       container binauthz attestors public-keys add \
       --attestor="${ATTESTOR_NAME}" \
       --keyversion-project="${KMS_KEY_PROJECT_ID}" \
       --keyversion-location="${KMS_KEY_LOCATION}" \
       --keyversion-keyring="${KMS_KEYRING_NAME}" \
       --keyversion-key="${KMS_KEY_NAME}" \
       --keyversion="${KMS_KEY_VERSION}"
   

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

   כדי להוסיף מפתח ציבורי PKIX שמאוחסן באופן מקומי למאמת, מריצים את הפקודה הבאה:

   gcloud --project="${ATTESTOR_PROJECT_ID}" \
       container binauthz attestors public-keys add \
       --attestor="${ATTESTOR_NAME}" \
       --pkix-public-key-file=${PUBLIC_KEY_FILE} \
       --pkix-public-key-algorithm=ecdsa-p256-sha256
   

   אם מוסיפים מפתח ציבורי למאמת ולא מציינים מזהה מפתח (שיכול להיות כל מחרוזת), המערכת תעניק לו מזהה באופן אוטומטי בפורמט RFC 6920: ‏ ni:///sha-256;..., כאשר ... הוא גיבוב מקודד של המפתח הציבורי. הערך הזה מוחזר בשדה id של פלט הפקודה. אפשר לשמור את המזהה שמוחזר ב-PUBLIC_KEY_ID ולהשתמש בו כדי ליצור אישור.

שמירת מזהה המפתח הציבורי

כדי ליצור אישור, צריך את מזהה המפתח הציבורי.

כדי לשמור את מזהה המפתח הציבורי, אפשר להעתיק אותו מהפלט של הפקודה הקודמת binauthz attestors public-keys add.

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

gcloud container binauthz attestors describe ${ATTESTOR_NAME}.

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

PUBLIC_KEY_ID=$(gcloud container binauthz attestors describe ${ATTESTOR_NAME} \
--format='value(userOwnedGrafeasNote.publicKeys[0].id)')

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

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

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

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

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