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

בדף הזה מוסבר איך להשתמש בבדיקת אישור חתימה פשוטה של אימות רציף (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 פרויקט.

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

    • Select a project: כדי לבחור פרויקט לא צריך תפקיד IAM ספציפי – אפשר לבחור כל פרויקט שקיבלתם בו תפקיד.
    • יצירת פרויקט: כדי ליצור פרויקט, צריך את התפקיד Project Creator (יצירת פרויקטים) (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, צריך את תפקיד ה-IAM 'אדמין של Service Usage' (roles/serviceusage.serviceUsageAdmin), שכולל את ההרשאה serviceusage.services.enable. איך מקצים תפקידים

    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 פרויקט.

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

    • Select a project: כדי לבחור פרויקט לא צריך תפקיד IAM ספציפי – אפשר לבחור כל פרויקט שקיבלתם בו תפקיד.
    • יצירת פרויקט: כדי ליצור פרויקט, צריך את התפקיד Project Creator (יצירת פרויקטים) (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, צריך את תפקיד ה-IAM 'אדמין של Service Usage' (roles/serviceusage.serviceUsageAdmin), שכולל את ההרשאה serviceusage.services.enable. איך מקצים תפקידים

    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, צריך לבקש מהאדמין להקצות לסוכן השירות של Binary Authorization בכל פרויקט את תפקידי ה-IAM הבאים:

  • אם פרויקט האשכול שונה מפרויקט המדיניות: Binary Authorization Policy Evaluator (roles/binaryauthorization.policyEvaluator) on the cluster project Binary Authorization Service Agent, for it to access the policy project
  • אם פרויקט האימות שונה מפרויקט המדיניות: Container Analysis Occurrences Viewer (roles/containeranalysis.occurrences.viewer) on the policy project Binary Authorization Service Agent, for it to access the attestation project

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

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

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

כדי לוודא שלסוכן השירות של אישור בינארי בכל פרויקט יש את ההרשאות הנדרשות להערכת בדיקת האישור הפשוטה של חתימת CV, צריך להקצות לסוכן השירות של אישור בינארי בכל פרויקט את תפקידי ה-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 במזהה הפרויקט שמכיל את המדיניות.

  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 בודק את האישור, הוא משתמש במפתח הציבורי כדי לאמת את האישור.

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

PKIX Cloud KMS

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

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

    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}
    

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

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

  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

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

בקטע הזה יוצרים אשכול שמשתמש באכיפת מדיניות 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 רק עם מדיניות פלטפורמה מבוססת-בדיקות. אם האכיפה של מדיניות 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 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 עם מדיניות פלטפורמה מבוססת-בדיקה.

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

  • 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 לא יכולה למצוא את האישור ורושמת את ההפרה ב-Cloud Logging.

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

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 נפרס. מכיוון שיש אישור לתמונה, לא נוצרים רשומות ביומן שקשורות ל-Pod הזה.

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

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

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

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

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

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

צפייה ביומנים של רשומות קורות חיים

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

{
  "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 או את 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: מזהה הפרויקט של המדיניות

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