Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

יצירת גורמים מאמתים (attestors) באמצעות API בארכיטקטורת REST

בדף הזה מוסבר איך ליצור גורם מאמת (attestor) בהתאמה אישית ב-Binary Authorization באמצעות API בארכיטקטורת REST.

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

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

סקירה כללית

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

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

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

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

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

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

אם עדיין לא עשיתם את זה, מגדירים את פרויקט ברירת המחדל Google Cloud :

PROJECT_ID=PROJECT_ID
gcloud config set project ${PROJECT_ID}

הגדרת הסביבה

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

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

אם פרויקט גורם מאמת (attestor) ופרויקט הפריסה הם אותו פרויקט, השתמשו באותו מזהה פרויקט בשני המשתנים.

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

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. כל אישור נשמר כמופע של ההערה הזו.

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

מגדירים משתני סביבה לאחסון מזהה ההערה ותיאור שקל לקרוא:
```
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)

בכלי לעריכת טקסט, יוצרים קובץ JSON ב-/tmp/note_payload.json שמתאר את הערת Artifact Analysis:

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

יוצרים את ההערה על ידי שליחת בקשת HTTP ל-Artifact Analysis REST API:
```
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/"

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

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

כדי להגדיר את ההרשאות:

יוצרים קובץ 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

מוסיפים את חשבון השירות ואת תפקידי הגישה המבוקשים למדיניות ה-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 כשמגדירים את המדיניות.

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

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

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

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

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

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

PKIX (Cloud KMS)

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

כדי להגדיר את משתני הסביבה שנדרשים ליצירת זוג המפתחות, מריצים את הפקודות הבאות:
```
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

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

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

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

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

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

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

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

הקובץ הזה מכיל גם מפתח ציבורי וגם מפתח פרטי, ולכן צריך לחלץ את המפתח הציבורי לקובץ נפרד כדי להוסיף אותו למאמת:
```
PUBLIC_KEY_FILE="/tmp/ec_public.pem"
openssl ec -in ${PRIVATE_KEY_FILE} -pubout -out ${PUBLIC_KEY_FILE}
```

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

השלב הבא הוא ליצור את המאמת עצמו ב-Binary Authorization עם ההערה המשויכת של Artifact Analysis. צריך גם להוסיף את המפתח הציבורי הקריפטוגרפי.

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

מגדירים משתנה סביבה לאחסון השם של המאמת כפי שהוא מוגדר ב-Binary Authorization:
```
ATTESTOR_NAME=ATTESTOR_NAME
```
כאשר ATTESTOR_NAME הוא שם המאשר שרוצים ליצור (לדוגמה, build-secure או prod-qa).

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

PKIX (Cloud KMS)

מגדירים משתני סביבה נוספים כדי לאחסן מידע על צמד המפתחות של Cloud KMS עבור הקריאה ל-Binary Authorization API.

KMS_CRYPTO_KEY_URI="projects/${KMS_KEY_PROJECT_ID}/locations/${KMS_KEY_LOCATION}/keyRings/${KMS_KEYRING_NAME}/cryptoKeys/${KMS_KEY_NAME}"
KMS_CRYPTO_KEY_VERSION_URI="${KMS_CRYPTO_KEY_URI}/cryptoKeyVersions/${KMS_KEY_VERSION}"
KMS_KEY_ID="//cloudkms.googleapis.com/v1/${KMS_CRYPTO_KEY_VERSION_URI}"

מורידים את קובץ המפתח הציבורי מ-Cloud KMS ושומרים אותו בקובץ בשם /tmp/kms_public_key.pem במערכת המקומית.

יוצרים קובץ JSON שמכיל את המידע שנדרש ליצירת גורם מאמת (attestor):

cat > /tmp/attestor.json << EOM
{
    "userOwnedDrydockNote": {
        "noteReference": "${NOTE_URI}",
        "publicKeys": {
            "id": "${KMS_KEY_ID}",
            "pkixPublicKey": {
                "signatureAlgorithm": "${KMS_KEY_ALGORITHM}",
                "publicKeyPem": $( \
                    python < /tmp/kms_public_key.pem \
                    -c 'import json, sys; print(json.dumps(sys.stdin.read()))' \
                )
            }
        }
    }
}
EOM

יוצרים את הגורם המעיד:

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/attestor.json \
"https://binaryauthorization.googleapis.com/v1/projects/${ATTESTOR_PROJECT_ID}/attestors?attestorId=${ATTESTOR_NAME}"

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

יוצרים קובץ JSON שמכיל את המידע שנדרש ליצירת גורם מאמת (attestor):

cat > /tmp/attestor.json << EOM
{
   "userOwnedGrafeasNote": {
       "noteReference": "${NOTE_URI}",
       "publicKeys": {
           "pkixPublicKey": {
               "signatureAlgorithm": "ecdsa_p256_sha256",
               "publicKeyPem": $( \
                   python < ${PUBLIC_KEY_FILE} \
                   -c 'import json, sys; print(json.dumps(sys.stdin.read()))' \
               )
           }
       }
   }
}
EOM

יוצרים את הגורם המעיד:

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/attestor.json \
"https://binaryauthorization.googleapis.com/v1/projects/${ATTESTOR_PROJECT_ID}/attestors?attestorId=${ATTESTOR_NAME}"

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

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

cat > /tmp/iam_request.json << EOM
{
  'resource': 'projects/${ATTESTOR_PROJECT_ID}/attestors/${ATTESTOR_NAME}',
  'policy': {
    'bindings': [
      {
        'role': 'roles/binaryauthorization.attestorsVerifier',
        'members': [
          'serviceAccount:${DEPLOYER_SERVICE_ACCOUNT}'
        ]
      }
    ]
  }
}
EOM

מוסיפים את חשבון השירות ואת תפקידי הגישה המבוקשים למדיניות ה-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://binaryauthorization.googleapis.com/v1beta1/projects/${ATTESTOR_PROJECT_ID}/attestors/${ATTESTOR_NAME}:setIamPolicy"

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

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

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

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

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

יצירת גורמים מאמתים (attestors) באמצעות API בארכיטקטורת REST קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

סקירה כללית

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

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

הגדרת הסביבה

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

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

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

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

PKIX (Cloud KMS)

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

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

PKIX (Cloud KMS)

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

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

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

יצירת גורמים מאמתים (attestors) באמצעות API בארכיטקטורת REST