שימוש בבדיקה פשוטה של אימות החתימה

בדף הזה מוסבר איך להשתמש בבדיקת אימות פשוטה של חתימה בתיקוף הרציף (CV) של Binary Authorization. הבדיקה מאמתת את האישורים של קובצי האימג' של קונטיינרים שמשויכים ל-Pods שפועלים באשכול Google Kubernetes Engine ‏(GKE) שבו מופעלת CV.

עלויות

במדריך הזה משתמשים בשירותי Google Cloud הבאים:

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

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

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

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

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

    gcloud init
  5. יוצרים או בוחרים פרויקט ב- Google Cloud .

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

    • בחירת פרויקט: כדי לבחור פרויקט לא נדרש תפקיד IAM ספציפי – אתם יכולים לבחור כל פרויקט שקיבלתם בו תפקיד.
    • יצירת פרויקט: כדי ליצור פרויקט, צריך את התפקיד "יצירת פרויקטים" (roles/resourcemanager.projectCreator), שכולל את ההרשאה resourcemanager.projects.create. איך מקצים תפקידים?
    • יוצרים פרויקט ב- Google Cloud :

      gcloud projects create PROJECT_ID

      מחליפים את PROJECT_ID בשם של הפרויקט ב- Google Cloud שאתם יוצרים.

    • בוחרים את הפרויקט שיצרתם ב- Google Cloud :

      gcloud config set project PROJECT_ID

      מחליפים את PROJECT_ID בשם הפרויקט ב- Google Cloud .

  6. מוודאים שהחיוב מופעל בפרויקט ב- Google Cloud .

  7. מפעילים את ממשקי ה-API של Binary Authorization,‏ Cloud Key Management Service ו-Google Kubernetes Engine, אם הם עדיין לא מופעלים:

    התפקידים שנדרשים כדי להפעיל ממשקי API

    כדי להפעיל ממשקי API, צריך את ההרשאה serviceusage.services.enable. אם אתם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד "בעלים" (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד "אדמין בממשק 'שימוש בשירות'" (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים

    gcloud services enable binaryauthorization.googleapis.com cloudkms.googleapis.com container.googleapis.com
  8. התקינו את ה-CLI של Google Cloud.

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

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

    gcloud init
  11. יוצרים או בוחרים פרויקט ב- Google Cloud .

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

    • בחירת פרויקט: כדי לבחור פרויקט לא נדרש תפקיד IAM ספציפי – אתם יכולים לבחור כל פרויקט שקיבלתם בו תפקיד.
    • יצירת פרויקט: כדי ליצור פרויקט, צריך את התפקיד "יצירת פרויקטים" (roles/resourcemanager.projectCreator), שכולל את ההרשאה resourcemanager.projects.create. איך מקצים תפקידים?
    • יוצרים פרויקט ב- Google Cloud :

      gcloud projects create PROJECT_ID

      מחליפים את PROJECT_ID בשם של הפרויקט ב- Google Cloud שאתם יוצרים.

    • בוחרים את הפרויקט שיצרתם ב- Google Cloud :

      gcloud config set project PROJECT_ID

      מחליפים את PROJECT_ID בשם הפרויקט ב- Google Cloud .

  12. מוודאים שהחיוב מופעל בפרויקט ב- Google Cloud .

  13. מפעילים את ממשקי ה-API של Binary Authorization,‏ Cloud Key Management Service ו-Google Kubernetes Engine, אם הם עדיין לא מופעלים:

    התפקידים שנדרשים כדי להפעיל ממשקי API

    כדי להפעיל ממשקי API, צריך את ההרשאה serviceusage.services.enable. אם אתם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד "בעלים" (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד "אדמין בממשק 'שימוש בשירות'" (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים

    gcloud services enable binaryauthorization.googleapis.com cloudkms.googleapis.com container.googleapis.com
  14. מוודאים שהגרסה של ה-CLI של gcloud עדכנית.
  15. מתקינים את כלי שורת הפקודה kubectl.
  16. אם כללי המדיניות של Binary Authorization ואשכולות GKE נמצאים בפרויקטים שונים, ודאו ש-Binary Authorization מופעל בשני הפרויקטים.

התפקידים הנדרשים

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

סקירה כללית

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

כדי לוודא שלסוכן השירות של Binary Authorization בכל פרויקט יש את ההרשאות הנדרשות לבדיקת אימות החתימה הפשוטה של CV, בקשו מהאדמין להקצות את תפקידי ה-IAM הבאים לסוכן השירות של Binary Authorization בכל פרויקט:

  • אם פרויקט האשכול שונה מפרויקט המדיניות: מעריך מדיניות של Binary Authorization (roles/binaryauthorization.policyEvaluator) בסוכן השירות של Binary Authorization בפרויקט האשכול, כדי שתהיה לו גישה לפרויקט המדיניות
  • אם פרויקט האימות שונה מפרויקט המדיניות: Container Analysis Occurrences Viewer (roles/containeranalysis.occurrences.viewer) בסוכן השירות של Binary Authorization בפרויקט המדיניות, כדי שתהיה לו גישה לפרויקט האימות

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

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

הקצאת תפקידים באמצעות ה-CLI של gcloud

כדי לוודא שלסוכן השירות של Binary Authorization בכל פרויקט יש את ההרשאות הנדרשות לבדיקת אימות החתימה הפשוטה של CV, צריך לתת לסוכן השירות של Binary Authorization בכל פרויקט את תפקידי ה-IAM הבאים:

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

    1. מאתרים את סוכן השירות של Binary Authorization בפרויקט של האשכול:

      PROJECT_NUMBER=$(gcloud projects list --filter="projectId:CLUSTER_PROJECT_ID" \
        --format="value(PROJECT_NUMBER)")
      CLUSTER_SERVICE_ACCOUNT="service-$PROJECT_NUMBER@gcp-sa-binaryauthorization.iam.gserviceaccount.com"
      

      מחליפים את CLUSTER_PROJECT_ID במזהה הפרויקט של האשכול.

    2. מאפשרים ל-CV להעריך את המדיניות באשכול:

      gcloud projects add-iam-policy-binding POLICY_PROJECT_ID \
          --member="serviceAccount:$CLUSTER_SERVICE_ACCOUNT" \
          --role='roles/binaryauthorization.policyEvaluator'
      

      מחליפים את POLICY_PROJECT_ID במזהה הפרויקט שמכיל את המדיניות.

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

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

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

      PROJECT_NUMBER=$(gcloud projects list \
        --filter="projectId:POLICY_PROJECT_ID" \
        --format="value(PROJECT_NUMBER)")
      SERVICE_ACCOUNT="service-$PROJECT_NUMBER@gcp-sa-binaryauthorization.iam.gserviceaccount.com"
      

      מחליפים את POLICY_PROJECT_ID במזהה הפרויקט שמכיל את המדיניות.

    2. מקצים את התפקיד:

      gcloud projects add-iam-policy-binding ATTESTATION_PROJECT_ID \
          --member="serviceAccount:$SERVICE_ACCOUNT" \
          --role='roles/containeranalysis.occurrences.viewer'
      

      מחליפים את ATTESTATION_PROJECT_ID במזהה הפרויקט שמכיל את האישורים.

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

בקטע הזה יוצרים זוג מפתחות אסימטריים של אלגוריתם חתימה דיגיטלית של עקומה אליפטית (ECDSA).

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

אתם יכולים להשתמש ב-Cloud Key Management Service או במפתחות מקומיים, אבל אנחנו ממליצים להשתמש במפתחות של Cloud KMS בסביבת הייצור.

PKIX Cloud KMS

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

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

    KMS_KEY_PROJECT_ID=KMS_KEY_PROJECT_ID
    KMS_KEYRING_NAME=KMS_KEYRING_NAME
    KMS_KEY_NAME=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
    KEY_FILE=KEY_FILE
    

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

    • ‫KMS_KEY_PROJECT_ID: מזהה הפרויקט
    • ‫KMS_KEYRING_NAME: שם לאוסף המפתחות ב-Cloud KMS
    • ‫KMS_KEY_NAME: שם למפתח Cloud KMS
    • ‫KEY_FILE: נתיב מקומי לשמירת המפתח של Cloud KMS
  2. יוצרים את אוסף המפתחות:

    gcloud kms keyrings create ${KMS_KEYRING_NAME} \
        --location=${KMS_KEY_LOCATION} \
        --project=${KMS_KEY_PROJECT_ID}
    
  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} \
        --project=${KMS_KEY_PROJECT_ID}
    
  4. מייצאים את חומר המפתח הציבורי לקובץ:

    gcloud kms keys versions get-public-key ${KMS_KEY_VERSION} \
        --key=${KMS_KEY_NAME} \
        --keyring=${KMS_KEYRING_NAME} \
        --location=${KMS_KEY_LOCATION} \
        --output-file=${KEY_FILE} \
        --project=${KMS_KEY_PROJECT_ID}
    

מפתח מקומי

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

  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}
    

יצירת מדיניות לפלטפורמה

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

  1. יוצרים את קובץ ה-YAML של מדיניות הפלטפורמה לבדיקת אימות חתימה פשוטה:

    PKIX Cloud KMS

    cat > /tmp/my-policy.yaml << EOF
    gkePolicy:
      checkSets:
      - checks:
        - simpleSigningAttestationCheck:
            containerAnalysisAttestationProjects:
            - projects/ATTESTATION_PROJECT_ID
            attestationAuthenticators:
              pkixPublicKeySet:
                pkixPublicKeys:
                  publicKeyPem: |
    $(awk '{printf "                %s\n", $0}' ${KEY_FILE})
                  signatureAlgorithm: ECDSA_P256_SHA256
                  keyId: |-
                    //cloudkms.googleapis.com/v1/projects/${KMS_KEY_PROJECT_ID}/locations/${KMS_KEY_LOCATION}/keyRings/${KMS_KEYRING_NAME}/cryptoKeys/${KMS_KEY_NAME}/cryptoKeyVersions/${KMS_KEY_VERSION}
    EOF
    

    מחליפים את ATTESTATION_PROJECT_ID במזהה הפרויקט שבו מאוחסנות ההצהרות שנוצרו באמצעות מפתח Cloud KMS הזה.

    מפתח מקומי

    cat > /tmp/my-policy.yaml <<EOF
    gkePolicy:
      checkSets:
      - checks:
        - simpleSigningAttestationCheck:
            containerAnalysisAttestationProjects:
            - projects/ATTESTATION_PROJECT_ID
            attestationAuthenticators:
              pkixPublicKeySet:
                pkixPublicKeys:
                  publicKeyPem: |
    $(awk '{printf "                %s\n", $0}' /tmp/ec_public.pem)
                  signatureAlgorithm: ECDSA_P256_SHA256
                  keyId: |
                    PUBLIC_KEY_ID
    EOF
    

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

    • ‫ATTESTATION_PROJECT_ID: מזהה הפרויקט שבו מאוחסנות ההצהרות שנוצרו באמצעות המפתח המקומי
    • ‫PUBLIC_KEY_ID: מזהה ייחודי של המפתח המקומי
  2. יוצרים את מדיניות הפלטפורמה:

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

    • POLICY_ID: מזהה מדיניות הפלטפורמה לבחירתכם. אם המדיניות נמצאת בפרויקט אחר, אפשר להשתמש בשם המלא של המשאב: projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID.
    • ‫POLICY_PATH: נתיב לקובץ המדיניות.
    • ‫POLICY_PROJECT_ID: מזהה הפרויקט של המדיניות.

    מריצים את הפקודה הבאה:

    ‫Linux,‏ macOS או Cloud Shell

    gcloud beta container binauthz policy create POLICY_ID \
        --platform=gke \
        --policy-file=POLICY_PATH \
        --project=POLICY_PROJECT_ID

    ‏Windows (PowerShell)

    gcloud beta container binauthz policy create POLICY_ID `
        --platform=gke `
        --policy-file=POLICY_PATH `
        --project=POLICY_PROJECT_ID

    Windows‏ (cmd.exe)

    gcloud beta container binauthz policy create POLICY_ID ^
        --platform=gke ^
        --policy-file=POLICY_PATH ^
        --project=POLICY_PROJECT_ID

  3. שומרים את ערך המזהה לשימוש מאוחר יותר:

    PUBLIC_KEY_ID="PUBLIC_KEY_ID"
    

    מחליפים את PUBLIC_KEY_ID במזהה שציינתם בשדה keyId בקובץ המדיניות של הפלטפורמה, בשלב מוקדם יותר במדריך הזה.

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

הפעלת CV

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

יצירת אשכול שמשתמש במעקב של CV

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

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

  • ‫CLUSTER_NAME: שם האשכול.
  • ‫LOCATION: המיקום, לדוגמה us-central1 או asia-south1.
  • ‫POLICY_PROJECT_ID: מזהה הפרויקט שבו מאוחסנת המדיניות.
  • ‫POLICY_ID: מזהה המדיניות.
  • ‫CLUSTER_PROJECT_ID: מזהה הפרויקט של האשכול.

מריצים את הפקודה הבאה:

‫Linux,‏ macOS או Cloud Shell

gcloud beta container clusters create CLUSTER_NAME \
    --location=LOCATION \
    --binauthz-evaluation-mode=POLICY_BINDINGS \
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID \
    --project=CLUSTER_PROJECT_ID

‏Windows (PowerShell)

gcloud beta container clusters create CLUSTER_NAME `
    --location=LOCATION `
    --binauthz-evaluation-mode=POLICY_BINDINGS `
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID `
    --project=CLUSTER_PROJECT_ID

Windows‏ (cmd.exe)

gcloud beta container clusters create CLUSTER_NAME ^
    --location=LOCATION ^
    --binauthz-evaluation-mode=POLICY_BINDINGS ^
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID ^
    --project=CLUSTER_PROJECT_ID

יצירת אשכול שמשתמש באכיפה ובמעקב של CV

בקטע הזה יוצרים אשכול שמשתמש גם באכיפת מדיניות project-singleton וגם במעקב CV עם מדיניות פלטפורמה מבוססת-בדיקות:

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

  • ‫CLUSTER_NAME: שם האשכול.
  • ‫LOCATION: המיקום, לדוגמה us-central1 או asia-south1.
  • ‫POLICY_PROJECT_ID: מזהה הפרויקט שבו מאוחסנת המדיניות.
  • ‫POLICY_ID: מזהה המדיניות.
  • ‫CLUSTER_PROJECT_ID: מזהה הפרויקט של האשכול.

מריצים את הפקודה הבאה:

‫Linux,‏ macOS או Cloud Shell

gcloud beta container clusters create CLUSTER_NAME \
    --location=LOCATION \
    --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE \
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID \
    --project=CLUSTER_PROJECT_ID

‏Windows (PowerShell)

gcloud beta container clusters create CLUSTER_NAME `
    --location=LOCATION `
    --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE `
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID `
    --project=CLUSTER_PROJECT_ID

Windows‏ (cmd.exe)

gcloud beta container clusters create CLUSTER_NAME ^
    --location=LOCATION ^
    --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE ^
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID ^
    --project=CLUSTER_PROJECT_ID

עדכון אשכול לשימוש במעקב של CV

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

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

  • ‫CLUSTER_NAME: שם האשכול
  • ‫LOCATION: המיקום. לדוגמה: us-central1 או asia-south1
  • ‫POLICY_PROJECT_ID: מזהה הפרויקט שבו מאוחסנת המדיניות
  • ‫POLICY_ID: מזהה המדיניות
  • ‫CLUSTER_PROJECT_ID: מזהה הפרויקט של האשכול

מריצים את הפקודה הבאה:

‫Linux,‏ macOS או Cloud Shell

gcloud beta container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --binauthz-evaluation-mode=POLICY_BINDINGS \
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID \
    --project=CLUSTER_PROJECT_ID

‏Windows (PowerShell)

gcloud beta container clusters update CLUSTER_NAME `
    --location=LOCATION `
    --binauthz-evaluation-mode=POLICY_BINDINGS `
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID `
    --project=CLUSTER_PROJECT_ID

Windows‏ (cmd.exe)

gcloud beta container clusters update CLUSTER_NAME ^
    --location=LOCATION ^
    --binauthz-evaluation-mode=POLICY_BINDINGS ^
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID ^
    --project=CLUSTER_PROJECT_ID

עדכון אשכול לשימוש באכיפה ובמעקב של CV

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

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

  • ‫CLUSTER_NAME: שם האשכול
  • ‫LOCATION: המיקום. לדוגמה: us-central1 או asia-south1
  • ‫POLICY_PROJECT_ID: מזהה הפרויקט שבו מאוחסנת המדיניות
  • ‫POLICY_ID: מזהה המדיניות
  • ‫CLUSTER_PROJECT_ID: מזהה הפרויקט של האשכול

מריצים את הפקודה הבאה:

‫Linux,‏ macOS או Cloud Shell

gcloud beta container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE \
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID \
    --project=CLUSTER_PROJECT_ID

‏Windows (PowerShell)

gcloud beta container clusters update CLUSTER_NAME `
    --location=LOCATION `
    --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE `
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID `
    --project=CLUSTER_PROJECT_ID

Windows‏ (cmd.exe)

gcloud beta container clusters update CLUSTER_NAME ^
    --location=LOCATION ^
    --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE ^
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID ^
    --project=CLUSTER_PROJECT_ID

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

בקטע הזה יוצרים הערה לדוגמה של Artifact Analysis כדי לקשר אישורים. כדי ליצור את ההערה:

  1. יוצרים את המשתנים של הפתק:

    NOTE_PROJECT_ID=NOTE_PROJECT_ID
    NOTE_ID="test-note"
    NOTE_URI="projects/${NOTE_PROJECT_ID}/notes/${NOTE_ID}"
    DESCRIPTION="CV test note"
    

    ‫NOTE_PROJECT_ID: מזהה הפרויקט שמכיל את ההערה.

  2. יוצרים את קובץ התוכן של ההערה:

    cat > /tmp/note_payload.json << EOM
    {
      "name": "${NOTE_URI}",
      "attestation": {
        "hint": {
          "human_readable_name": "${DESCRIPTION}"
        }
      }
    }
    EOM
    
  3. יוצרים את הפתק:

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

    ‫NOTE_PROJECT_ID: מזהה הפרויקט שמכיל את ההערה

  4. אופציונלי: כדי לוודא שההערה נוצרה:

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

    מחליפים את NOTE_PROJECT_ID במזהה הפרויקט שמכיל את ההערה.

בדיקת CV

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

לאחר מכן אתם מנסים לפרוס קובץ אימג' אחר שאין לו אישור. במקרה כזה, בדיקת ה-CV לא יכולה למצוא את ההצהרה ומתעדת את ההפרה ב-Cloud Logging.

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

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

יצירת אישור

כדי לעבור את בדיקת האימות של החתימה הפשוטה, צריך אימות תקין של קובץ האימג'.

אפשר ליצור אימות באמצעות ה-CLI של gcloud או ה-API בארכיטקטורת REST.

PKIX Cloud KMS

gcloud

כדי ליצור אימות באמצעות ה-CLI של gcloud:

  1. חותמים על קובץ האימג' ויוצרים את האימות באמצעות קידוד לפני אימות (PAE) (מומלץ):

    gcloud beta container binauthz attestations sign-and-create \
        --artifact-url=${IMAGE_TO_ATTEST} \
        --keyversion=${KMS_KEY_VERSION} \
        --keyversion-key=${KMS_KEY_NAME} \
        --keyversion-keyring=${KMS_KEYRING_NAME} \
        --keyversion-location=${KMS_KEY_LOCATION} \
        --note=${NOTE_URI} \
        --pae-encode-payload \
        --dsse-type=DSSE_TYPE
    

    מחליפים את DSSE_TYPE בסוג ה-DSSE לקידוד PAE. ערך ברירת המחדל של הדגל הוא application/vnd.dev.cosign.simplesigning.v1+json.

‫API בארכיטקטורת REST

כדי ליצור אימות (attestation) באמצעות ה-API בארכיטקטורת REST, בצע את הפעולות הבאות:

  1. יוצרים קובץ מטען ייעודי (payload) של חתימה:

    cat > /tmp/generated_payload.json << EOM
    {
      "critical": {
        "identity": {
          "docker-reference": "${IMAGE_PATH}"
        },
        "image": {
          "docker-manifest-digest": "${IMAGE_DIGEST}"
        },
        "type": "Google Cloud BinAuthz container signature"
      }
    }
    EOM
    
  2. חותמים על המטען הייעודי (payload):

    gcloud kms asymmetric-sign \
        --version=${KMS_KEY_VERSION} \
        --key=${KMS_KEY_NAME} \
        --keyring=${KMS_KEYRING_NAME} \
        --location=${KMS_KEY_LOCATION} \
        --digest-algorithm=sha256 \
        --input-file=/tmp/generated_payload.json \
        --signature-file=/tmp/ec_signature \
        --project=${KMS_KEY_PROJECT_ID}
    
  3. יוצרים את תוכן האישור:

    cat > /tmp/attestation.json << EOM
    {
    "resourceUri": "${IMAGE_TO_ATTEST}",
    "note_name": "${NOTE_URI}",
    "attestation": {
      "serialized_payload": "$(base64 --wrap=0 /tmp/generated_payload.json)",
      "signatures": [{
        "public_key_id": "${PUBLIC_KEY_ID}",
        "signature": "$(base64 --wrap=0 /tmp/ec_signature)"
      }]
    }
    }
    EOM
    
  4. יוצרים את האישור:

    curl -X POST "https://containeranalysis.googleapis.com/v1/projects/${NOTE_PROJECT_ID}/occurrences/" \
      -H "Content-Type: application/json" \
      -H "X-Goog-User-Project: ${NOTE_PROJECT_ID}" \
      -H "Authorization: Bearer $(gcloud auth print-access-token)" \
      --data-binary @/tmp/attestation.json
    

    מחליפים את NOTE_PROJECT_ID במזהה הפרויקט שמכיל את ההערה.

מפתח מקומי

gcloud

  1. יוצרים קובץ מטען ייעודי (payload) של חתימה:

    cat > /tmp/generated_payload.json << EOM
    {
      "critical": {
        "identity": {
          "docker-reference": "${IMAGE_PATH}"
        },
        "image": {
          "docker-manifest-digest": "${IMAGE_DIGEST}"
        },
        "type": "Google Cloud BinAuthz container signature"
      }
    }
    EOM
    
  2. יוצרים את קובץ המטען הייעודי (payload) של החתימה:

    openssl dgst -sha256 -sign ${PRIVATE_KEY_FILE} /tmp/generated_payload.json > /tmp/ec_signature
    
  3. יוצרים את האישור:

    gcloud container binauthz attestations create \
        --project=ATTESTATION_PROJECT_ID \
        --artifact-url=${IMAGE_TO_ATTEST} \
        --note=${NOTE_URI} \
        --signature-file=/tmp/ec_signature \
        --public-key-id=PUBLIC_KEY_ID
    

‫API בארכיטקטורת REST

  1. יוצרים קובץ מטען ייעודי (payload) של חתימה:

    cat > /tmp/generated_payload.json << EOM
    {
      "critical": {
        "identity": {
          "docker-reference": "${IMAGE_PATH}"
        },
        "image": {
          "docker-manifest-digest": "${IMAGE_DIGEST}"
        },
        "type": "Google Cloud BinAuthz container signature"
      }
    }
    EOM
    
  2. יוצרים את קובץ המטען הייעודי (payload) של החתימה:

    openssl dgst -sha256 -sign ${PRIVATE_KEY_FILE} /tmp/generated_payload.json > /tmp/ec_signature
    
  3. יוצרים את תוכן האישור:

    cat > /tmp/attestation.json << EOM
    {
    "resourceUri": "${IMAGE_TO_ATTEST}",
    "note_name": "${NOTE_URI}",
    "attestation": {
      "serialized_payload": "$(base64 --wrap=0 /tmp/generated_payload.json)",
      "signatures": [{
        "public_key_id": "${PUBLIC_KEY_ID}",
        "signature": "$(base64 --wrap=0 /tmp/ec_signature)"
      }]
    }
    }
    EOM
    
  4. יוצרים את האישור:

    curl -X POST "https://containeranalysis.googleapis.com/v1/projects/${NOTE_PROJECT_ID}/occurrences/" \
      -H "Content-Type: application/json" \
      -H "X-Goog-User-Project: ${NOTE_PROJECT_ID}" \
      -H "Authorization: Bearer $(gcloud auth print-access-token)" \
      --data-binary @/tmp/attestation.json
    

פריסת קובץ האימג' שיש לו אישור

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

  1. הגדרת kubectl:

    gcloud container clusters get-credentials CLUSTER_NAME \
        --location=LOCATION \
        --project=CLUSTER_PROJECT_ID
    

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

    • ‫CLUSTER_NAME: השם של האשכול
    • ‫LOCATION: מיקום האשכול
    • ‫CLUSTER_PROJECT_ID: מזהה הפרויקט של האשכול
  2. פורסים שירות ובודקים את הפריסה בהתאם למדיניות של Binary Authorization:

    kubectl run hello-app-with-attestation --image=$IMAGE_PATH@$IMAGE_DIGEST
    

    ה-Pod נפרס. לתמונה יש אישור, ולכן CV לא יוצר רשומות ביומן שקשורות ל-Pod הזה.

פריסת קובץ אימג' ללא אישור

בקטע הזה תפרסו קובץ אימג' שלא משויך אליו אישור.

בגלל שדרישות המדיניות דורשות אימותים ולקובץ האימג' הזה אין אימות, CV מתעד באופן קבוע את ההפרה בזמן שהקונטיינר פועל.

כדי לפרוס את קובץ האימג', מריצים את הפקודה הבאה:

kubectl run hello-app-without-attestation \
   --image=$IMAGE_PATH@$IMAGE_DIGEST

ה-Pod נפרס. בגלל שלתמונה אין אישור, CV יוצר רשומות ביומן בזמן שה-Pod פועל.

הצגת היומנים של רשומות ה-CV

אתם יכולים לחפש ברשומות של Cloud Logging כדי למצוא שגיאות בהגדרות של CV והפרות של אימות מדיניות הפלטפורמה של CV.

CV רושם שגיאות והפרות ב-Cloud Logging תוך 24 שעות. בדרך כלל הרשומות מופיעות תוך כמה שעות.

צפייה ביומני שגיאות בהגדרת ה-CV

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

gcloud logging read \
     --order="desc" \
     --freshness=7d \
     --project=CLUSTER_PROJECT_ID \
    'logName:"binaryauthorization.googleapis.com%2Fcontinuous_validation" "configErrorEvent"'

בפלט הבא מוצגת שגיאת הגדרה שבה לא נמצאה מדיניות פלטפורמה של CV:

{
  "insertId": "141d4f10-72ea-4a43-b3ec-a03da623de42",
  "jsonPayload": {
    "@type": "type.googleapis.com/google.cloud.binaryauthorization.v1beta1.ContinuousValidationEvent",
    "configErrorEvent": {
      "description": "Cannot monitor cluster 'us-central1-c.my-cluster': Resource projects/123456789/platforms/gke/policies/my-policy does not exist."
    }
  },
  "resource": {
    "type": "k8s_cluster",
    "labels": {
      "cluster_name": "my-cluster",
      "location": "us-central1-c",
      "project_id": "my-project"
    }
  },
  "timestamp": "2024-05-28T15:31:03.999566Z",
  "severity": "WARNING",
  "logName": "projects/my-project/logs/binaryauthorization.googleapis.com%2Fcontinuous_validation",
  "receiveTimestamp": "2024-05-28T16:30:56.304108670Z"
}

הצגת הפרות של אימות מדיניות הפלטפורמה של CV

אם אין תמונות שמפירות את כללי המדיניות של הפלטפורמה שהפעלתם, לא יופיעו רשומות ביומנים.

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

gcloud logging read \
     --order="desc" \
     --freshness=7d \
     --project=CLUSTER_PROJECT_ID \
    'logName:"binaryauthorization.googleapis.com%2Fcontinuous_validation" "policyName"'

מחליפים את CLUSTER_PROJECT_ID במזהה הפרויקט של האשכול.

סוגי הבדיקות

המידע על הפרות של בדיקות CV נרשם ביומן של checkResults. ברשומה, הערך checkType מציין את הבדיקה. אלה הערכים של כל בדיקה:

  • ImageFreshnessCheck
  • SigstoreSignatureCheck
  • SimpleSigningAttestationCheck
  • SlsaCheck
  • TrustedDirectoryCheck
  • VulnerabilityCheck

יומן לדוגמה

בדוגמה הבאה מוצגת רשומה ביומן של CV שמתארת תמונה שלא תואמת למדיניות ומפרה את הבדיקה של ספרייה מהימנה:

{
  "insertId": "637c2de7-0000-2b64-b671-24058876bb74",
  "jsonPayload": {
    "podEvent": {
      "endTime": "2022-11-22T01:14:30.430151Z",
      "policyName": "projects/123456789/platforms/gke/policies/my-policy",
      "images": [
        {
          "result": "DENY",
          "checkResults": [
            {
              "explanation": "TrustedDirectoryCheck at index 0 with display name \"My trusted directory check\" has verdict NOT_CONFORMANT. Image is not in a trusted directory",
              "checkSetName": "My check set",
              "checkSetIndex": "0",
              "checkName": "My trusted directory check",
              "verdict": "NON_CONFORMANT",
              "checkType": "TrustedDirectoryCheck",
              "checkIndex": "0"
            }
          ],
          "image": "gcr.io/my-project/hello-app:latest"
        }
      ],
      "verdict": "VIOLATES_POLICY",
      "podNamespace": "default",
      "deployTime": "2022-11-22T01:06:53Z",
      "pod": "hello-app"
    },
    "@type": "type.googleapis.com/google.cloud.binaryauthorization.v1beta1.ContinuousValidationEvent"
  },
  "resource": {
    "type": "k8s_cluster",
    "labels": {
      "project_id": "my-project",
      "location": "us-central1-a",
      "cluster_name": "my-test-cluster"
    }
  },
  "timestamp": "2022-11-22T01:44:28.729881832Z",
  "severity": "WARNING",
  "logName": "projects/my-project/logs/binaryauthorization.googleapis.com%2Fcontinuous_validation",
  "receiveTimestamp": "2022-11-22T03:35:47.171905337Z"
}

הסרת המשאבים

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

אתם יכולים להשבית את המעקב של CV או את Binary Authorization ו-CV באשכול.

השבתת Binary Authorization באשכול

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

gcloud beta container clusters update CLUSTER_NAME \
    --binauthz-evaluation-mode=DISABLED \
    --location=LOCATION \
    --project=CLUSTER_PROJECT_ID

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

  • ‫CLUSTER_NAME: שם האשכול
  • ‫LOCATION: מיקום האשכול
  • ‫CLUSTER_PROJECT_ID: מזהה הפרויקט של האשכול

השבתת המעקב אחר מדיניות שמבוססת על בדיקות באשכול

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

gcloud beta container clusters update CLUSTER_NAME  \
    --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE \
    --location=LOCATION \
    --project="CLUSTER_PROJECT_ID"

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

  • ‫CLUSTER_NAME: שם האשכול
  • ‫LOCATION: מיקום האשכול
  • ‫CLUSTER_PROJECT_ID: מזהה הפרויקט של האשכול

שימו לב שהדגל --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE מקביל לדגל הישן יותר --enable-binauthz.

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

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

gcloud beta container binauthz policy delete POLICY_ID \
    --platform=gke \
    --project="POLICY_PROJECT_ID"

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

  • ‫POLICY_ID: מזהה המדיניות
  • ‫POLICY_PROJECT_ID: מזהה הפרויקט של המדיניות

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