אבטחת גרסאות build של קונטיינרים

אבטחת גרסאות build של קונטיינרים

מידע על Codelab זה

העדכון האחרון: מרץ 23, 2023

נכתב על ידי Christopher Grant

1.‏ מבוא

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

• On-Demand Scanning API מאפשר לסרוק קובצי אימג' של קונטיינרים באופן ידני כדי לאתר נקודות חולשה במערכת ההפעלה, באופן מקומי במחשב או מרחוק ב-Container Registry או ב-Artifact Registry.
• הממשק Container Scanner מאפשר לזהות אוטומטית נקודות חולשה של מערכת ההפעלה, ולסרוק בכל פעם שדוחפים תמונה ל-Container Registry או ל-Artifact Registry. הפעלת ה-API הזה גם מאפשרת סריקות של חבילות שפה לאיתור נקודות חולשה ב-Go ו-Java.

On-Demand Scanning API מאפשר לסרוק תמונות שמאוחסנות באופן מקומי במחשב או מרחוק ב-Container Registry או ב-Artifact Registry. כך מקבלים שליטה מפורטת על הקונטיינרים שרוצים לסרוק כדי לאתר נקודות חולשה. אתם יכולים להשתמש בסריקה לפי דרישה כדי לסרוק תמונות בצינור עיבוד הנתונים של CI/CD לפני שתחליטו אם לאחסן אותן במרשם.

מה תלמדו

בשיעור ה-Lab הזה:

• פיתוח קובצי אימג' באמצעות Cloud Build
• שימוש ב-Artifact Registry לקונטיינרים
• שימוש בסריקה אוטומטית של נקודות חולשה
• הגדרת סריקה על פי דרישה
• הוספה של סריקת תמונה ב-CICD ב-Cloud Build

2.‏ הגדרה ודרישות

הגדרת סביבה בקצב אישי

1. נכנסים למסוף Google Cloud ויוצרים פרויקט חדש או עושים שימוש חוזר בפרויקט קיים. אם אין לכם עדיין חשבון Gmail או חשבון Google Workspace, עליכם ליצור חשבון.

• Project name הוא השם המוצג של המשתתפים בפרויקט. זו מחרוזת תווים שלא משמשת את Google APIs. אפשר לעדכן אותו בכל שלב.
• Project ID הוא ייחודי בכל הפרויקטים ב-Google Cloud ואי אפשר לשנות אותו (אי אפשר לשנות אותו אחרי שמגדירים אותו). מסוף Cloud יוצר מחרוזת ייחודית באופן אוטומטי; בדרך כלל לא מעניין אותך מה זה. ברוב ה-Codelabs תצטרכו להפנות אל מזהה הפרויקט (בדרך כלל הוא מזוהה כ-PROJECT_ID). אם המזהה שנוצר לא מוצא חן בעיניך, יש לך אפשרות ליצור מזהה אקראי אחר. לחלופין, אפשר לנסות תבנית משלך ולבדוק אם היא זמינה. לא ניתן לשנות אותו אחרי השלב הזה, והוא יישאר למשך הפרויקט.
• לידיעתך, יש ערך שלישי – Project Number (מספר פרויקט), שחלק מממשקי ה-API משתמשים בו. מידע נוסף על כל שלושת הערכים האלה זמין במסמכי התיעוד.

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

הערה: אם משתמשים בחשבון Gmail, אפשר להשאיר את מיקום ברירת המחדל שמוגדר כללא ארגון. אם אתם משתמשים בחשבון Google Workspace, חשוב לבחור מיקום שמתאים לארגון שלכם.

2. בשלב הבא צריך להפעיל את החיוב במסוף Cloud כדי להשתמש במשאבים או בממשקי API של Cloud. מעבר ב-Codelab הזה לא אמור לעלות הרבה, אם בכלל. כדי להשבית את המשאבים ולא לצבור חיובים מעבר למדריך הזה, אתם יכולים למחוק את המשאבים שיצרתם או למחוק את הפרויקט כולו. משתמשים חדשים ב-Google Cloud זכאים להצטרף לתוכנית תקופת ניסיון בחינם בשווי 1,200 ש"ח.

הגדרת סביבה

ב-Cloud Shell, מגדירים את מזהה הפרויקט ואת מספר הפרויקט. שומרים אותם כמשתנים מסוג PROJECT_ID ו-PROJECT_ID.

export PROJECT_ID=$(gcloud config get-value project)
export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID \
    --format='value(projectNumber)')

הפעלת השירותים

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

gcloud services enable \
  cloudkms.googleapis.com \
  cloudbuild.googleapis.com \
  container.googleapis.com \
  containerregistry.googleapis.com \
  artifactregistry.googleapis.com \
  containerscanning.googleapis.com \
  ondemandscanning.googleapis.com \
  binaryauthorization.googleapis.com 

3.‏ פיתוח קובצי אימג' באמצעות Cloud Build

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

מתן גישה לחשבון השירות ב-Cloud Build

ל-Cloud Build נדרשות הרשאות כדי לגשת לממשק ה-API של הסריקה על פי דרישה. אפשר לספק גישה באמצעות הפקודות הבאות.

gcloud projects add-iam-policy-binding ${PROJECT_ID} \
        --member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \
        --role="roles/iam.serviceAccountUser"
        
gcloud projects add-iam-policy-binding ${PROJECT_ID} \
        --member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \
        --role="roles/ondemandscanning.admin"

יצירה ושינוי בספריית עבודה

mkdir vuln-scan && cd vuln-scan

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

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

cat > ./Dockerfile << EOF
FROM gcr.io/google-appengine/debian9@sha256:ebffcf0df9aa33f342c4e1d4c8428b784fc571cdf6fbab0b31330347ca8af97a

# System
RUN apt update && apt install python3-pip -y

# App
WORKDIR /app
COPY . ./

RUN pip3 install Flask==1.1.4
RUN pip3 install gunicorn==20.1.0

CMD exec gunicorn --bind :$PORT --workers 1 --threads 8 --timeout 0 main:app

EOF

צור קובץ בשם main.py עם התוכן הבא

cat > ./main.py << EOF
import os
from flask import Flask

app = Flask(__name__)

@app.route("/")
def hello_world():
    name = os.environ.get("NAME", "Worlds")
    return "Hello {}!".format(name)

if __name__ == "__main__":
    app.run(debug=True, host="0.0.0.0", port=int(os.environ.get("PORT", 8080)))
EOF

יצירת צינור עיבוד הנתונים של Cloud Build

הפקודה הבאה תיצור קובץ cloudbuild.yaml בספרייה שלכם שישמש לתהליך האוטומטי. בדוגמה הזו, השלבים מוגבלים לתהליך ה-build של הקונטיינר. עם זאת, בפועל צריך לכלול הוראות ובדיקות ספציפיות לאפליקציה בנוסף לשלבים של מאגר התגים.

יוצרים את הקובץ באמצעות הפקודה הבאה.

cat > ./cloudbuild.yaml << EOF
steps:

# build
- id: "build"
  name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image', '.']
  waitFor: ['-']


EOF

הפעלת צינור עיבוד הנתונים של CI

שליחת ה-build לעיבוד

gcloud builds submit

בדיקת פרטי ה-build

אחרי שתהליך ה-build התחיל, התקדמות הבדיקה במרכז הבקרה של Cloud Build.

1. פותחים את Cloud Build במסוף Cloud.
2. כדי לצפות בתוכן צריך ללחוץ על ה-build

4.‏ Artifact Registry לקונטיינרים

יצירת מאגר של Artifact Registry

בשיעור ה-Lab הזה תשתמשו ב-Artifact Registry כדי לאחסן ולסרוק את התמונות. יוצרים את המאגר באמצעות הפקודה הבאה.

gcloud artifacts repositories create artifact-scanning-repo \
  --repository-format=docker \
  --location=us-central1 \
  --description="Docker repository"

הגדרת Docer לשימוש בפרטי הכניסה של gcloud בגישה ל-Artifact Registry.

gcloud auth configure-docker us-central1-docker.pkg.dev

עדכון צינור עיבוד הנתונים של Cloud Build

יש לשנות את צינור עיבוד הנתונים של ה-build כדי לדחוף את התמונה שמתקבלת ל-Artifact Registry

cat > ./cloudbuild.yaml << EOF
steps:

# build
- id: "build"
  name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image', '.']
  waitFor: ['-']

# push to artifact registry
- id: "push"
  name: 'gcr.io/cloud-builders/docker'
  args: ['push',  'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image']

images:
  - us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image
EOF

הפעלת צינור עיבוד הנתונים של CI

שליחת ה-build לעיבוד

gcloud builds submit

5.‏ סריקה אוטומטית של נקודות חולשה

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

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

בסיום תהליך ה-build הקודם, צריך לבדוק את תוצאות התמונות ונקודות החולשה בלוח הבקרה של Artifact Registry.

1. פותחים את Artifact Registry במסוף Cloud
2. כדי להציג את התוכן, לוחצים על המאגר לסריקת ארטיפקטים.
3. לוחצים לפתיחת פרטי התמונה
4. לוחצים כדי להציג את התקציר האחרון של התמונה
5. בסיום הסריקה, לוחצים על כרטיסיית נקודות החולשה של התמונה

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

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

6.‏ סריקה על פי דרישה

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

בניית תמונה

בשלב הזה תשתמשו ב-Docker מקומי כדי ליצור את התמונה במטמון המקומי.

docker build -t us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image .

סריקת התמונה

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

gcloud artifacts docker images scan \
    us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image \
    --format="value(response.scan)" > scan_id.txt

בדיקת קובץ הפלט

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

cat scan_id.txt

לעיון בתוצאות סריקה מפורטות

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

gcloud artifacts docker images list-vulnerabilities $(cat scan_id.txt) 

הפלט מכיל כמות משמעותית של נתונים על כל נקודות החולשה שבתמונה.

סימון בעיות קריטיות

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

export SEVERITY=CRITICAL

gcloud artifacts docker images list-vulnerabilities $(cat scan_id.txt) --format="value(vulnerability.effectiveSeverity)" | if grep -Fxq ${SEVERITY}; then echo "Failed vulnerability check for ${SEVERITY} level"; else echo "No ${SEVERITY} Vulnerabilities found"; fi

הפלט של הפקודה הזו יהיה

Failed vulnerability check for CRITICAL level

7.‏ סריקה ב-CICD באמצעות Cloud Build

מתן גישה לחשבון השירות ב-Cloud Build

ל-Cloud Build נדרשות הרשאות כדי לגשת לממשק ה-API של הסריקה על פי דרישה. אפשר לספק גישה באמצעות הפקודות הבאות.

gcloud projects add-iam-policy-binding ${PROJECT_ID} \
        --member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \
        --role="roles/iam.serviceAccountUser"
        
gcloud projects add-iam-policy-binding ${PROJECT_ID} \
        --member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \
        --role="roles/ondemandscanning.admin"

עדכון צינור עיבוד הנתונים של Cloud Build

הפקודה הבאה תיצור קובץ cloudbuild.yaml בספרייה שלכם שישמש לתהליך האוטומטי. בדוגמה הזו, השלבים מוגבלים לתהליך ה-build של הקונטיינר. עם זאת, בפועל צריך לכלול הוראות ובדיקות ספציפיות לאפליקציה בנוסף לשלבים של מאגר התגים.

יוצרים את הקובץ באמצעות הפקודה הבאה.

cat > ./cloudbuild.yaml << EOF
steps:

# build
- id: "build"
  name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image', '.']
  waitFor: ['-']

#Run a vulnerability scan at _SECURITY level
- id: scan
  name: 'gcr.io/cloud-builders/gcloud'
  entrypoint: 'bash'
  args:
  - '-c'
  - |
    (gcloud artifacts docker images scan \
    us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image \
    --location us \
    --format="value(response.scan)") > /workspace/scan_id.txt

#Analyze the result of the scan
- id: severity check
  name: 'gcr.io/cloud-builders/gcloud'
  entrypoint: 'bash'
  args:
  - '-c'
  - |
      gcloud artifacts docker images list-vulnerabilities \$(cat /workspace/scan_id.txt) \
      --format="value(vulnerability.effectiveSeverity)" | if grep -Fxq CRITICAL; \
      then echo "Failed vulnerability check for CRITICAL level" && exit 1; else echo "No CRITICAL vulnerability found, congrats !" && exit 0; fi

#Retag
- id: "retag"
  name: 'gcr.io/cloud-builders/docker'
  args: ['tag',  'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image', 'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good']


#pushing to artifact registry
- id: "push"
  name: 'gcr.io/cloud-builders/docker'
  args: ['push',  'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good']

images:
  - us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image
EOF

הפעלת צינור עיבוד הנתונים של CI

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

gcloud builds submit

כשל ב-Build של הביקורת

גרסת ה-build ששלחת תיכשל כי התמונה מכילה נקודות חולשה קריטיות.

אפשר לבדוק את כשל ה-build בדף היסטוריה של Cloud Build

איך לתקן את פרצת האבטחה

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

מחליפים את קובץ ה-Docker כדי להשתמש בתמונה של Debian 10 באמצעות הפקודה הבאה

cat > ./Dockerfile << EOF
from python:3.8-slim  

# App
WORKDIR /app
COPY . ./

RUN pip3 install Flask==2.1.0
RUN pip3 install gunicorn==20.1.0

CMD exec gunicorn --bind :\$PORT --workers 1 --threads 8 main:app

EOF

מריצים את תהליך ה-CI עם התמונה הטובה

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

gcloud builds submit

בדיקת הצלחה ב-Build

ה-build ששלחת עכשיו יצליח כי התמונה המעודכנת לא מכילה נקודות חולשה קריטיות.

לבדוק את הצלחת ה-build בדף היסטוריית השימוש ב-Cloud Build.

בדיקת תוצאות הסריקה

בדיקת התמונה הטובה במרשם של Artifact

1. פותחים את Artifact Registry במסוף Cloud
2. כדי להציג את התוכן, לוחצים על המאגר לסריקת ארטיפקטים.
3. לוחצים לפתיחת פרטי התמונה
4. לוחצים כדי להציג את התקציר האחרון של התמונה
5. יש ללחוץ על כרטיסיית נקודות החולשה של התמונה

8.‏ מעולה!

כל הכבוד, סיימת את ה-Codelab!

נושאים שטיפלנו בהם:

• פיתוח קובצי אימג' באמצעות Cloud Build
• Artifact Registry לקונטיינרים
• סריקה אוטומטית של נקודות חולשה
• סריקה על פי דרישה
• סריקה ב-CICD באמצעות Cloud Build

השלב הבא:

• אבטחת פריסות של תמונות ל-Cloud Run ול-Google Kubernetes Engine | משאבי עזרה ל-Cloud Build
• מדריך למתחילים: הגדרת מדיניות Binary Authorization באמצעות GKE | Google Cloud

הסרת המשאבים

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

מחיקת הפרויקט

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

—

עדכון אחרון: 21.03.23