מדריך למתחילים: מעקב אחרי אבטחת ה-Pod באמצעות אימות רציף

מדריך למתחילים: מעקב אחרי אבטחת ה-Pod באמצעות אימות רציף

איך מתחילים להשתמש באימות רציף (CV) של Binary Authorization עם מדיניות מבוססת-בדיקות במדריך הזה לשימוש מהיר, משתמשים בבדיקות של CV הבאות כדי לאמת באופן רציף את הפעלת ה-Pods בתנאים הבאים:

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

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

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

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

הערה: אם התקנתם את ה-CLI של gcloud, השתמשו בפקודה gcloud components update כדי לבדוק אם הגרסה העדכנית מותקנת.

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

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

gcloud init

יוצרים או בוחרים 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 .

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

מפעילים את ממשקי ה-API של Binary Authorization ו-Google Kubernetes Engine:

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

כדי להפעיל ממשקי API, צריך את תפקיד ה-IAM 'אדמין של Service Usage' (roles/serviceusage.serviceUsageAdmin), שכולל את ההרשאה serviceusage.services.enable. איך מקצים תפקידים

gcloud services enable container.googleapis.com binaryauthorization.googleapis.com

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

הערה: אם התקנתם את ה-CLI של gcloud, השתמשו בפקודה gcloud components update כדי לבדוק אם הגרסה העדכנית מותקנת.

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

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

gcloud init

יוצרים או בוחרים 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 .

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

מפעילים את ממשקי ה-API של Binary Authorization ו-Google Kubernetes Engine:

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

כדי להפעיל ממשקי API, צריך את תפקיד ה-IAM 'אדמין של Service Usage' (roles/serviceusage.serviceUsageAdmin), שכולל את ההרשאה serviceusage.services.enable. איך מקצים תפקידים

gcloud services enable container.googleapis.com binaryauthorization.googleapis.com

1. מתקינים את כלי שורת הפקודה kubectl.
2. אם מדיניות Binary Authorization ואשכולות GKE נמצאים בפרויקטים שונים, צריך לוודא ש-Binary Authorization מופעל בשני הפרויקטים.

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

כדי להגדיר מדיניות פלטפורמה של GKE לניהול עלויות:

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

   cat << EOF > /tmp/my-policy.yaml
   gkePolicy:
     checkSets:
     - checks:
       - trustedDirectoryCheck:
           trustedDirPatterns:
           - us-central1-docker.pkg.dev/my-project/my-directory
         displayName: My trusted directory check
       - imageFreshnessCheck:
           maxUploadAgeDays: 30
         displayName: My image freshness check
       displayName: My trusted directory and image freshness check set
   EOF
   

   המדיניות הזו בודקת את התנאים הבאים:

   • התמונות של ה-Pods מאוחסנות במאגר Artifact Registry בשם us-central1-docker.pkg.dev/my-project/my-directory.

   • התמונות של ה-Pods הועלו למאגרי Artifact Registry או Container Registry ב-30 הימים האחרונים.

2. יוצרים את מדיניות הפלטפורמה:

   gcloud beta container binauthz policy create POLICY_ID \
       --platform=gke \
       --policy-file=/tmp/my-policy.yaml \
       --project=POLICY_PROJECT_ID
   

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

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

יצירה או עדכון של אשכול

כדי להפעיל CV באשכול, אפשר ליצור אשכול חדש או לעדכן אשכול קיים.

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

  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
  

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

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

  ממתינים ליצירת האשכול.

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

  חשוב: אם האכיפה של Binary Authorization כבר מופעלת באשכול, צריך להגדיר את --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE.

  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
  

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

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

  מחכים שהאשכול יעודכן.

פריסת תמונה

1. קבלת פרטי הכניסה של kubectl:

   gcloud container clusters get-credentials CLUSTER_NAME
   

2. פריסת תמונה:

   kubectl run hello-app \
       --image=us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
   

   התמונה us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0 עברה את בדיקת הרעננות כי היא הועלתה למאגר לפני פחות מ-30 ימים. אבל התמונה לא עומדת בדרישות של בדיקת הספרייה המהימנה כי היא לא נמצאת ב-us-central1-docker.pkg.dev/my-project/my-directory. כתוצאה מכך, ב-Cloud Logging נוצרות רשומות ביומן TrustedDirectoryCheck.

צפייה ביומנים

הרשומה ביומן מופיעה ב-Cloud Logging תוך 24 שעות אחרי הפריסה של ה-Pod, אבל יכול להיות שהיא תופיע תוך כמה שעות.

כדי להציג את היומן ב-Cloud Logging, משתמשים במסנן הבא:

logName:"binaryauthorization.googleapis.com%2Fcontinuous_validation"
"policyName"

היומן של Pod‏ hello-app דומה ליומן שמופיע בהמשך. יכול להיות שחלק מהשדות יהיו שונים בהתאם למזהה הפרויקט, לשם האשכול וכו'.

{
  "insertId": "637c2de7-0000-2b64-b671-24058876bb74",
  "jsonPayload": {
    "podEvent": {
      "endTime": "2022-11-22T01:14:30.430151Z",
      "policyName": "projects/1234567890/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": "Default check set",
              "checkSetIndex": "0",
              "checkName": "My trusted directory check",
              "verdict": "NON_CONFORMANT",
              "checkType": "TrustedDirectoryCheck",
              "checkIndex": "0"
            }
          ],
          "image": "us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0"
        }
      ],
      "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-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"
}

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

• ‫policyName: מדיניות פלטפורמה ש-CV השתמש בה כשזיהה את ההפרה

• ‫checkResults: בלוק של תוצאות שכולל את השדות הבאים:

  • explanation: הודעת שגיאה
  • ‫checkSetName: הערך displayName של קבוצת הבדיקה
  • ‫checkSetIndex: האינדקס של קבוצת הבדיקות במדיניות
  • ‫checkName: השם של הבדיקה
  • ‫checkIndex: האינדקס של הבדיקה בערכת הבדיקות
  • ‫verdict: התוצאה שהובילה ליצירת רשומה ביומן, במקרה הזה NOT_CONFORMANT כי הבדיקה לא עברה.

חלק מהבדיקות יכולות לכלול מידע נוסף שיעזור לכם להבין למה הבדיקה לא עברה.

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

הסרת המשאבים

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

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

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

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

• שימוש בבדיקת הרעננות של התמונה
• שימוש בבדיקת אישור חתימה פשוטה
• שימוש בבדיקת החתימה של Sigstore
• שימוש בבדיקת SLSA
• שימוש בבדיקה של מאגר מהימן
• שימוש בבדיקת נקודות חולשה

• צפייה ביומני CV

• CV ועל בדיקות אחרות של CV