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

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

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

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

כדי ליצור גורם מאשר:

  • יוצרים הערה ב-Artifact Analysis כדי לאחסן מטא-נתונים מהימנים שמשמשים בתהליך האימות.
  • מגדירים זוג מפתחות של תשתית של מפתח ציבורי (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 כדי לאחסן מטא-נתונים מהימנים שמשמשים בתהליך ההרשאה. לכל גורם מאשר שיוצרים, צריך ליצור הערה אחת של 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 ל-API בארכיטקטורת REST של Artifact Analysis:

    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}"

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

    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"

אם קיבלתם את השגיאה service account not found כשניסיתם להקצות את תפקיד ה-IAM, יכול להיות שאתם צריכים ליצור את סוכן השירות באופן ידני.

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

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

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

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

יצירת מפתחות להצפנה פוסט-קוונטית (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}

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

במדריך הזה תשתמשו ב-Elliptic Curve Digital Signature Algorithm (ECDSA)‎ המומלץ כדי ליצור זוג מפתחות PKIX. אפשר גם להשתמש בזוגות מפתחות RSA או PGP. למידע נוסף על אלגוריתמים של חתימה, ראו מטרות ואלגוריתמים של מפתחות.

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

‫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 (מפתח מקומי)

כדי ליצור זוג מפתחות 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}

יצירת ה-attestor

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

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

    ATTESTOR_NAME=ATTESTOR_NAME

    מחליפים את ATTESTOR_NAME בשם של הגורם המאשר שרוצים ליצור (לדוגמה, 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;..., כאשר ... הוא גיבוב (hash) מקודד של המפתח הציבורי. הערך הזה מוחזר בשדה 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}"

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