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

בדף הזה מוסבר איך להשתמש בבדיקת אישור חתימה פשוטה של אימות רציף (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, נדרשת ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד 'בעלים' (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד 'אדמין של Service Usage' (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 פרויקט.

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

    • 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, נדרשת ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד 'בעלים' (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד 'אדמין של Service Usage' (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים 

    gcloud services enable binaryauthorization.googleapis.com cloudkms.googleapis.com container.googleapis.com
    14.
  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

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

  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