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

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

במדריך הזה מוסבר איך להשתמש ב-Binary Authorization בהגדרה של כמה פרויקטים. למידע על הגדרה פשוטה יותר של פרויקט יחיד, אפשר לעיין במאמר תחילת העבודה עם Google Cloud CLI‏ (GKE).

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

מטרות

במדריך הזה תבצעו את המשימות הבאות:

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

צריך להגדיר את בקרת הגישה המתאימה לכל פרויקט באמצעות ניהול הזהויות והרשאות הגישה (IAM).

כדי להוסיף אבטחה, אתם יכולים להשתמש ב-VPC Service Controls כדי להגן על המשאבים שאתם יוצרים במדריך הזה. מידע נוסף מופיע במאמר אבטחה באמצעות VPC Service Controls.

עלויות

במסמך הזה משתמשים ברכיבים הבאים של Google Cloud, והשימוש בהם כרוך בתשלום:

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

משתמשים חדשים של Google Cloud ? יכול להיות שאתם זכאים לתקופת ניסיון בחינם.

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

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

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

התקינו את ה-CLI של Google Cloud.

אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.

כדי לאתחל את ה-CLI של gcloud, הריצו את הפקודה הבאה:

gcloud init

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

התקינו את ה-CLI של Google Cloud.

אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.

כדי לאתחל את ה-CLI של gcloud, הריצו את הפקודה הבאה:

gcloud init

מתקינים את kubectl כדי ליצור אינטראקציה עם GKE.

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

פרויקט הפריסה מנהל את אשכולות Google Kubernetes Engine ‏(GKE) שבהם פורסים תמונות, ואת המדיניות של Binary Authorization שאוכפת Binary Authorization בזמן הפריסה. יכול להיות שיהיו לכם יותר מפרויקט אחד לפריסה, בהתאם לגודל, למורכבות ולדרישות אחרות של הסביבה שלכם.

כדי להגדיר את פרויקט הפריסה:

יוצרים את הפרויקט ומפעילים את החיוב במסוף Google Cloud , אם עדיין לא עשיתם את זה.
הערה בנושא ניהול זהויות והרשאות גישה (IAM): פרויקט הפריסה מכיל את אשכול GKE. ההגדרה של ניהול הזהויות והרשאות הגישה (IAM) בפרויקט הזה צריכה לשקף את זה.
מגדירים משתני סביבה כדי לאחסן את Google Cloud הפרויקט והמספר:
```
DEPLOYER_PROJECT_ID=DEPLOYER_PROJECT_ID
```
מחליפים את DEPLOYER_PROJECT_ID במזהה הפרויקט ב- Google Cloud .
```
DEPLOYER_PROJECT_NUMBER=$(gcloud projects describe "${DEPLOYER_PROJECT_ID}" \
    --format="value(projectNumber)")
```

הפעלת ממשקי API:

Artifact Registry

gcloud --project=${DEPLOYER_PROJECT_ID} \
  services enable\
  container.googleapis.com\
  artifactregistry.googleapis.com\
  binaryauthorization.googleapis.com

מאחזרים את השם של חשבון השירות של הפרויקט שבו מתבצעת הפריסה:
```
DEPLOYER_SERVICE_ACCOUNT="service-${DEPLOYER_PROJECT_NUMBER}@gcp-sa-binaryauthorization.iam.gserviceaccount.com"
```
תשתמשו בשם של חשבון השירות בשלב מאוחר יותר, כשמגדירים הרשאות בהערה של Artifact Analysis שמשויכת למאמת.

הגדרת פרויקט המאמת

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

כדי להגדיר את פרויקט המאשר:

יוצרים את הפרויקט ומפעילים את החיוב במסוף Google Cloud , אם עדיין לא עשיתם את זה.
הערה בנושא ניהול הזהויות והרשאות הגישה (IAM): מכיוון שהפרויקט הזה מכיל את המאמתים שלכם, רק אנשי אבטחה צריכים לקבל הרשאת כתיבה.
מגדירים משתני סביבה לאחסון מזהה ומספר הפרויקט:
```
ATTESTOR_PROJECT_ID=ATTESTOR_PROJECT_ID
```
מחליפים את ATTESTOR_PROJECT_ID במזהה הפרויקט של גורם מאמת (attestor).
```
ATTESTOR_PROJECT_NUMBER=$(gcloud projects describe "${ATTESTOR_PROJECT_ID}" \
    --format="value(projectNumber)")
```

מפעילים את Artifact Analysis API ו-Binary Authorization API:

gcloud services --project=${ATTESTOR_PROJECT_ID} \
    enable containeranalysis.googleapis.com \
    binaryauthorization.googleapis.com

מאחזרים את השם של חשבון השירות של פרויקט המאמת:
```
ATTESTOR_SERVICE_ACCOUNT="service-${ATTESTOR_PROJECT_NUMBER}@gcp-sa-binaryauthorization.iam.gserviceaccount.com"
```
תשתמשו בשם של חשבון השירות בשלב מאוחר יותר, כשמגדירים הרשאות בהערה של Artifact Analysis שמשויכת למאמת.

הגדרת פרויקט האישורים

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

יוצרים את הפרויקט ומפעילים את החיוב במסוף Google Cloud , אם עדיין לא עשיתם את זה.
הערה בנושא ניהול הזהויות והרשאות הגישה (IAM): לכל התפקידים שקשורים לאישור בינארי צריכה להיות הרשאת קריאה להערות ולמקרים של ניתוח ארטיפקטים בפרויקט הזה, אבל רק למנהלי אישורים צריכה להיות הרשאת כתיבה.
מגדירים משתנה סביבה לאחסון שם הפרויקט:
```
ATTESTATION_PROJECT_ID=ATTESTATION_PROJECT_ID
```
מחליפים את ATTESTATION_PROJECT_ID במזהה פרויקט האימות.

מפעילים את Artifact Analysis API ו-Binary Authorization API:

gcloud services --project=${ATTESTATION_PROJECT_ID} \
    enable containeranalysis.googleapis.com \
    binaryauthorization.googleapis.com

יצירת אשכול

עכשיו אפשר ליצור אשכול GKE בפרויקט של כלי הפריסה. זהו האשכול שבו רוצים להריץ את האימג'ים של הקונטיינרים שנפרסו. כשיוצרים את האשכול, מעבירים את הדגל --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE לפקודה gcloud container clusters create.

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

gcloud --project=${DEPLOYER_PROJECT_ID} \
    container clusters create \
    --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE \
    --zone us-central1-a \
    test-cluster

בדוגמה הזו, יוצרים אשכול בשם test-cluster באזור GKE‏ us-central1-a.

צריך גם לעדכן את קובץ kubeconfig המקומי בהתקנת kubectl. הפעולה הזו מספקת את פרטי הכניסה ופרטי נקודת הקצה שנדרשים כדי לגשת לאוסף ב-GKE.

כדי לעדכן את הקובץ המקומי kubeconfig:

gcloud --project=${DEPLOYER_PROJECT_ID} \
    container clusters get-credentials \
    --zone us-central1-a \
    test-cluster

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

גורם מאמת הוא צד שאחראי לאימות של השלמת תהליך נדרש לפני שאפשר לפרוס קובץ אימג' של קונטיינר. הגורם הזה יכול להיות משתמש אנושי, או לרוב תהליך במכונה כמו מערכת build ובדיקה, או צינורות עיבוד נתונים של אינטגרציה רציפה (CI) ופריסה (CD). יוצרים את המאמתים בפרויקט המאמת.

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

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

במדריך הזה יש מאמת אחד בשם test-attestor והערה של ניתוח מאגר תגים בשם test-attestor-note. בתרחיש מהעולם האמיתי, יכולים להיות כל מספר של מאמתים, כל אחד מייצג צד שמשתתף בתהליך ההרשאה של התמונה.

יצירת ההערה של Artifact Analysis

מגדירים משתנים שמאחסנים את השם של גורם מאמת (attestor) ואת ההערה של Artifact Analysis
```
ATTESTOR_NAME=test-attestor
NOTE_ID=test-attestor-note
```
מחליפים את:
- ‫test-attestor: שם גורם מאמת שבחרתם.
- ‫test-attestor-note: שם הערה של מאמת לפי בחירתכם.

יוצרים קובץ JSON ב-/tmp/note_payload.json שמתאר את הערת ניתוח המאגר:

cat > /tmp/note_payload.json << EOM
{
  "name": "projects/${ATTESTOR_PROJECT_ID}/notes/${NOTE_ID}",
  "attestation": {
    "hint": {
      "human_readable_name": "Attestor Note"
    }
  }
}
EOM

יוצרים את ההערה על ידי שליחת בקשת HTTP ל-Artifact Analysis REST API:
```
curl -X POST \
    -H "Content-Type: application/json" \
    -H "Authorization: Bearer $(gcloud auth print-access-token)"  \
    --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)" \
"https://containeranalysis.googleapis.com/v1/projects/${ATTESTOR_PROJECT_ID}/notes/${NOTE_ID}"

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

עכשיו אפשר ליצור את המאשר:

יוצרים את המאשר ב-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}

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

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

אי אפשר להשתמש עדיין בגורם המאמת (attestor) שיצרתם בלי זוג מפתחות PKIX משויך, שאותו יוצרים בהמשך.

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

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

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

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

הגדרת הרשאות בהערה של Artifact Analysis

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

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

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

מוסיפים את חשבון השירות ואת תפקידי הגישה המבוקשים למדיניות ה-IAM של ההערה שיצרתם:
```
curl -X POST  \
    -H "Content-Type: application/json" \
    -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    --data-binary @/tmp/iam_request.json \
    "https://containeranalysis.googleapis.com/v1/projects/${ATTESTOR_PROJECT_ID}/notes/${NOTE_ID}:setIamPolicy"
```
זהירות: Binary Authorization לא תומך ב-Artifact Analysis באחסון אזורי או בנקודות קצה אזוריות. מומלץ להשתמש בנקודת קצה ל-API הגלובלית של Artifact Analysis ‏ (https://containeranalysis.googleapis.com/).

הגדרת מפתחות PKIX

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

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

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

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

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

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

כדי ליצור זוג מפתחות PKIX אסימטרי מקומי חדש ולאחסן אותו בקובץ:
PKIX (Cloud KMS)
בשלב הזה נסביר איך לבצע אימות באמצעות מפתחות שנוצרו ואוחסנו ב-Cloud Key Management Service.
1. מגדירים משתני סביבה לאחסון מידע על צמד המפתחות שמנוהל על ידי 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_PROJECT_ID: המזהה של הפרויקט שבו שמורים המפתחות
  
  ‫KMS_KEY_LOCATION: המיקום של המפתח
  
  ‫KMS_KEYRING_NAME: השם של אוסף המפתחות
  
  ‫KMS_KEY_NAME: השם של המפתח
  
  ‫KMS_KEY_VERSION: גרסת המפתח
2. [אופציונלי] מגדירים מפתח KMS:
  
  הערה: אם כבר יש לכם מפתח KMS, אתם יכולים לדלג על השלבים האלה.
  
  יוצרים מפתח KMS שהמפתח הציבורי שלו יכול להיות מאוחסן בבודק. בשלב הזה מוגדרים גם משתני סביבה שבהם תשתמשו בהמשך.
  
  כדי ליצור מפתח ולהגדיר את משתני הסביבה:
  
  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
  
  יוצרים אוסף מפתחות KMS:
  
  gcloud kms keyrings create ${KMS_KEYRING_NAME} \ --location ${KMS_KEY_LOCATION} \ --project ${KMS_KEY_PROJECT_ID}
  
  יוצרים את המפתח:
  
  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} \ --project ${KMS_KEY_PROJECT_ID}
  
  מידע נוסף על יצירת מפתחות KMS זמין במאמר בנושא יצירת מפתח אסימטרי.
3. מוסיפים את המפתח הציבורי למאמת:
  
  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 (מפתח מקומי)

אזהרה: אנחנו ממליצים מאוד לא להשתמש בזוגות מפתחות שנוצרו באופן מקומי בסביבות ייצור, כי הם מהווים סיכון אבטחה. במקום זאת, מומלץ להשתמש ב-Cloud Key Management Service. הדוגמה הזו מיועדת להמחשה בלבד.
1. כדי ליצור את המפתח הפרטי, מריצים את הפקודות הבאות:
  
  PRIVATE_KEY_FILE="/tmp/ec_private.pem" openssl ecparam -genkey -name prime256v1 -noout -out ${PRIVATE_KEY_FILE}
  
  ‫PRIVATE_KEY_FILE הוא שם הקובץ שמכיל את המפתח הפרטי שמאוחסן בגורם המאמת (attestor).
2. מחלקים את המפתח הפרטי למפתח ציבורי ומאחסנים אותו בקובץ:
  
  PUBLIC_KEY_FILE="/tmp/ec_public.pem" openssl ec -in ${PRIVATE_KEY_FILE} -pubout -out ${PUBLIC_KEY_FILE}
  
  ‫PUBLIC_KEY_FILE הוא שם הקובץ שמכיל את המפתח הציבורי שמאוחסן בבודק.
3. כדי להוסיף את המפתח הציבורי שייצאתם למאמת, מריצים את הקוד הבא.
  
  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
  
  Binary Authorization משתמש במפתח הציבורי של הגורם המאמת כדי לאמת את האימות (attestation).

הגדרת המדיניות

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

כדי להגדיר את המדיניות:

יוצרים קובץ מדיניות חדש שמאפשר תמונות מערכת שמתוחזקות על ידי Google, מגדירים את evaluationMode לערך REQUIRE_ATTESTATION ומוסיפים צומת בשם requireAttestationsBy שמפנה למאמת שיצרתם:

cat > /tmp/policy.yaml << EOM
    globalPolicyEvaluationMode: ENABLE
    defaultAdmissionRule:
      evaluationMode: REQUIRE_ATTESTATION
      enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
      requireAttestationsBy:
        - projects/${ATTESTOR_PROJECT_ID}/attestors/${ATTESTOR_NAME}
    name: projects/${DEPLOYER_PROJECT_ID}/policy
EOM

מייבאים את קובץ ה-YAML של המדיניות אל Binary Authorization:

gcloud --project=${DEPLOYER_PROJECT_ID} \
    container binauthz policy import /tmp/policy.yaml

מידע נוסף על הגדרת מדיניות זמין במאמר בנושא הגדרת מדיניות באמצעות CLI.

בדיקת המדיניות

במדריך הזה יוצרים אישור לדוגמה, לתמונות ציבוריות של 'Hello World!‎' מ-Artifact Registry. בתחילה, האכיפה חוסמת את פריסת התמונות כי לא קיים אישור נדרש.

כדי לנסות לפרוס את התמונה:

Artifact Registry

kubectl run hello-server --image us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0 --port 8080

עכשיו מאמתים שהפריסה נחסמה על ידי Binary Authorization:

kubectl get pods

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

No resources found.

אפשר לקבל פרטים נוספים על הפריסה:

kubectl get event --template \
'{{range.items}}{{"\033[0;36m"}}{{.reason}}:{{"\033[0m"}}\{{.message}}{{"\n"}}{{end}}'

תופיע תגובה שדומה לתגובה הבאה:

FailedCreate: Error creating: pods POD_NAME is forbidden: admission webhook "imagepolicywebhook.image-policy.k8s.io" denied the request: Image IMAGE_NAME denied by Binary Authorization default admission rule. Image IMAGE_NAME denied by attestor ATTESTOR_NAME: No attestations found

בפלט הזה:

‫POD_NAME: שם ה-Pod.
‫IMAGE_NAME: שם התמונה.
‫ATTESTOR_NAME: השם של הגורם המאמת.

חשוב למחוק את הפריסה כדי להמשיך לשלב הבא:

kubectl delete deployment hello-server

יצירת אישור

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

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

כדי ליצור אישור:

מגדירים משתנים שמאחסנים את נתיב הרישום ואת ה-digest של התמונה:

Artifact Registry

IMAGE_PATH="us-docker.pkg.dev/google-samples/containers/gke/hello-app"
IMAGE_DIGEST="sha256:37e5287945774f27b418ce567cd77f4bbc9ef44a1bcd1a2312369f31f9cce567"
IMAGE_TO_ATTEST=${IMAGE_PATH}@${IMAGE_DIGEST}

יצירת האישור
PKIX Cloud KMS
כדי ליצור את האישור באמצעות מפתח Cloud KMS, מריצים את הפקודה הבאה:
gcloud beta container binauthz attestations sign-and-create \ --project="${PROJECT_ID}" \ --artifact-url="${IMAGE_TO_ATTEST}" \ --attestor="${ATTESTOR_NAME}" \ --attestor-project="${PROJECT_ID}" \ --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 (מפתח מקומי)
כדי ליצור את האישור באמצעות מפתח מקומי:
1. יוצרים את המטען הייעודי (payload) של האימות:
  
  הערה: בפקודה הבאה, נדרש ${IMAGE_PATH} כדי ליצור את מטען החתימה לאישור, אבל רק ${IMAGE_DIGEST} נמצא בשימוש בזמן הפריסה. המשמעות היא שאפשר לפרוס תמונת קונטיינר זהה מכמה מיקומים עם אותו אישור.
  
  gcloud --project=${ATTESTATION_PROJECT_ID} \ container binauthz create-signature-payload \ --artifact-url=${IMAGE_TO_ATTEST} > /tmp/generated_payload.json
  
  קובץ ה-JSON של המטען הייעודי מכיל את הפרטים הבאים:
  
  Artifact Registry
  { "critical": { "identity": { "docker-reference": "us-docker.pkg.dev/google-samples/containers/gke/hello-app" }, "image": { "docker-manifest-digest": "sha256:37e5287945774f27b418ce567cd77f4bbc9ef44a1bcd1a2312369f31f9cce567" }, "type": "Google cloud binauthz container signature" } }
2. חתימה על המטען הייעודי (payload).
  
  אם משתמשים בקובצי PKIX מקומיים, חותמים על מטען הייעודי (payload) באמצעות המפתח הפרטי המקומי של PKIX ומפיקים קובץ חתימה:
  
  openssl dgst -sha256 -sign ${PRIVATE_KEY_FILE} /tmp/generated_payload.json > /tmp/ec_signature
  
  קובץ הפלט הוא גרסה חתומה של קובץ ה-JSON של מטען הייעודי (payload) שיצרתם למעלה.
3. מקבלים את מזהה המפתח הציבורי מהמאמת.
  
  אפשר לראות את המזהה של המפתח הציבורי בכל שלב באמצעות הפקודה: gcloud container binauthz attestors describe ATTESTOR_NAME.
  
  כדי לשמור את מזהה המפתח הציבורי במשתנה סביבה, מזינים את הפקודה הבאה:
  
  PUBLIC_KEY_ID=$(gcloud container binauthz attestors describe ${ATTESTOR_NAME} \ --format='value(userOwnedGrafeasNote.publicKeys[0].id)' --project ${ATTESTOR_PROJECT_ID})
4. יוצרים ומאמתים את האישור:
  
  gcloud container binauthz attestations create \ --project="${ATTESTATION_PROJECT_ID}" \ --artifact-url="${IMAGE_TO_ATTEST}" \ --attestor="projects/${ATTESTOR_PROJECT_ID}/attestors/${ATTESTOR_NAME}" \ --signature-file=/tmp/ec_signature \ --public-key-id="${PUBLIC_KEY_ID}" \ --validate
  
  הדגל validate בודק שאפשר לאמת את האישור על ידי המאשר שהגדרתם במדיניות.

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

gcloud --project=${ATTESTATION_PROJECT_ID} \
    container binauthz attestations list \
    --attestor=$ATTESTOR_NAME --attestor-project=$ATTESTOR_PROJECT_ID

מידע נוסף על יצירת אישורים זמין במאמר יצירת אישורים.

בדיקה מחדש של המדיניות

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

כדי לפרוס את התמונה:

kubectl run hello-server --image ${IMAGE_TO_ATTEST} --port 8080

כדי לוודא שהתמונה נפרסה:

kubectl get pods

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

NAME                            READY     STATUS    RESTARTS   AGE
hello-server-579859fb5b-h2k8s   1/1       Running   0          1m

עכשיו, אחרי שפרסתם בהצלחה את קובץ האימג' של הקונטיינר ואימתתם שההגדרה פועלת, אתם יכולים למחוק את האשכול שיצרתם ב-GKE:

gcloud --project=${DEPLOYER_PROJECT_ID} \
    container clusters delete \
    --zone=us-central1-a \
    test-cluster

הסרת המשאבים

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

מוחקים את האשכול שיצרתם ב-GKE:

gcloud container clusters delete \
    --zone=us-central1-a \
    test-cluster

אפשר גם למחוק Google Cloud פרויקטים שיצרתם בשביל המדריך הזה.

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

מטרות

עלויות

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

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

Artifact Registry

הגדרת פרויקט המאמת

הגדרת פרויקט האישורים

יצירת אשכול

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

יצירת ההערה של Artifact Analysis

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

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

הגדרת הרשאות בהערה של Artifact Analysis

הגדרת מפתחות PKIX

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

PKIX (Cloud KMS)

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

הגדרת המדיניות

בדיקת המדיניות

Artifact Registry

יצירת אישור

Artifact Registry

PKIX Cloud KMS

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

Artifact Registry

בדיקה מחדש של המדיניות

הסרת המשאבים

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

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