תובנות אבטחה בזמן הריצה

1. מבוא

בשיעור ה-Lab הזה תפרסו אפליקציה ב-Cloud Run ובאשכול GKE ותצפו בתובנות לגבי האבטחה של הפריסה ב-Software Delivery Shield Security

מה תלמדו

  • תובנות אבטחה ב-Artifact Registry
  • תובנות אבטחה ב-Cloud Run
  • GKE Security Posture

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

הגדרה של פרויקט ב-Cloud

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

b35bf95b8bf3d5d8.png

a99b7ace416376c4.png

bd84a6d3004737c5.png

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

הגדרת הסביבה

לוחצים על הסמל משמאל לסרגל החיפוש כדי להפעיל את Cloud Shell.

ecdc43ada29e91b.png

מ-Cloud Shell, מפעילים את ממשקי ה-API שנדרשים ל-Lab הזה:

gcloud services enable run.googleapis.com \
  cloudbuild.googleapis.com \
  artifactregistry.googleapis.com \
  container.googleapis.com \
  containersecurity.googleapis.com

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

6356559df3eccdda.png

אמורה להופיע הודעה על הצלחה, כמו זו:

Operation "operations/acf.p2-327036483151-73d90d00-47ee-447a-b600-a6badf0eceae" finished successfully.

מריצים את הפקודה כדי ליצור את אשכול GKE באופן אסינכרוני. תשתמשו בו בהמשך שיעור ה-Lab:

gcloud beta container clusters create gke-cluster \
    --zone us-central1-a \
    --async

3. הכנת הבקשה

קודם כול, תכינו אפליקציית Node.js פשוטה שמבוססת על Express ומגיבה לבקשות HTTP.

ב-Cloud Shell, יוצרים ספרייה חדשה בשם starter-nodejs ועוברים אליה:

mkdir starter-nodejs
cd starter-nodejs

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

cat > ./package.json << EOF
{
  "name": "cloudrun-starter-app",
  "version": "1.0.0",
  "description": "Node.js Starter Application",
  "main": "index.js",
  "scripts": {
    "start": "node index.js"
  },
  "author": "",
  "license": "Apache-2.0",
  "dependencies": {
    "express": "^4.18.2"
  }
}
EOF

הקובץ שלמעלה מכיל פקודה של סקריפט הפעלה ותלות ב-Express, מסגרת אפליקציות האינטרנט.

לאחר מכן, באותה ספרייה, מריצים את הפקודות הבאות כדי ליצור קובץ index.js:

cat > ./index.js << EOF
const express = require('express');
const app = express();

app.get('/', (req, res) => {
  console.log('Received a request.');
  res.send("Hello Cloud Run!");
});

const port = process.env.PORT || 8080;

app.listen(port, () => {
  console.log('Listening on port', port);
});
EOF

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

4. פריסת אפליקציית Cloud Run

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

gcloud run deploy starter-app \
  --source . \
  --region us-central1 \
  --allow-unauthenticated \
  --max-instances=3

מאשרים את יצירת המאגר ב-Artifact Registry:

Deploying from source requires an Artifact Registry Docker repository to store built containers. A repository named [cloud-run-source-deploy] in region [us-central1] will be created.

Do you want to continue (Y/n)? y

5. תובנות לגבי אבטחה ב-Artifact Registry וב-Cloud Build

תהליך הבנייה יימשך כמה דקות.

פותחים את Cloud Build ובודקים את ארטיפקטים של ה-build עבור ה-build האחרון.

בממשק המשתמש של Cloud Build במסוף Google Cloud יש חלונית תובנות בנושא אבטחה של Software Delivery Shield, שבה מוצג מידע על האבטחה שקשור ל-build, כמו רמת SLSA, פגיעויות בתלות ואישור המקור של Build.

7d9fd2213f3704c4.png

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

חוזרים למסוף Cloud Shell ומוודאים שהפריסה של אפליקציית Cloud Run הושלמה.

Done.
Service [starter-app] revision [starter-app-00001-maw] has been deployed and is serving 100 percent of traffic.
Service URL: https://starter-app-nin5jpgefq-uc.a.run.app

6. תובנות אבטחה ב-Cloud Run

ב-Cloud Run יש חלונית אבטחה (בגרסת Preview) שבה מוצגים תובנות לגבי אבטחת שרשרת אספקת התוכנה, כמו מידע על תאימות לרמת ה-build של SLSA, אישור המקור של Build ונקודות חולשה שנמצאו בשירותים פעילים.

פותחים את Cloud Run ובודקים את תובנות האבטחה בכרטיסייה REVISIONS / SECURITY.

62a9f5d26207e58e.png

בחלונית הזו מוצג המידע הבא:

  • זהות והצפנה: כתובת האימייל של חשבון השירות שמוגדר כברירת מחדל ב-Compute Engine ומפתח ההצפנה שמשמש לפריסה.
  • רמת SLSA: הגרסה הזו היא ברמה 3 של SLSA, שמציינת את רמת הבשלות של תהליך build התוכנה בהתאם למפרט SLSA
  • נקודות חולשה: כל נקודות החולשה שנמצאו בתלות של האפליקציה.
  • פרטי ה-build: פרטים על ה-build, כמו ה-builder והקישור לצפייה ביומנים.
  • Build provenance: Provenance for the build, which is a collection of verifiable metadata about a build. הוא כולל פרטים כמו תקצירי התמונות שנבנו, מיקומי מקור הקלט, שרשרת הכלים של ה-build, שלבי ה-build ומשך ה-build.

7. GKE Security Posture

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

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

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

gcloud beta container clusters list

פלט לדוגמה:

NAME: gke-cluster
LOCATION: us-central1-a
MASTER_VERSION: 1.24.9-gke.3200
MASTER_IP: 34.29.226.228
MACHINE_TYPE: e2-medium
NODE_VERSION: 1.24.9-gke.3200
NUM_NODES: 3
STATUS: RUNNING

אחזור פרטי הכניסה וההגדרות של אשכול GKE:

gcloud container clusters get-credentials gke-cluster  \
    --region=us-central1-a

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

export PROJECT_ID=$(gcloud config get-value project)

kubectl run starter-app \
  --image us-central1-docker.pkg.dev/${PROJECT_ID}/cloud-run-source-deploy/starter-app:latest \
  --port 8080

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

הפעלה של סריקת הגדרות עומס עבודה:

gcloud beta container clusters update gke-cluster \
    --region=us-central1-a \
    --enable-workload-config-audit

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

‫GKE סורק אוטומטית את תמונות הקונטיינרים בכל Pod שעומד בדרישות ופועל באשכול GKE, כדי לזהות נקודות חולשה ידועות. לשם כך הוא משתמש בנתוני נקודות חולשה ממאגרי מידע ציבוריים של CVE, כמו NIST.

אם נמצאת נקודת חולשה בתמונות של הקונטיינרים, מערכת GKE מקצה לה דירוג חומרה ומציגה את התוצאות בלוח הבקרה של מצב האבטחה במסוף Google Cloud. בנוסף, GKE מוסיף רשומות ל-Cloud Logging לצורך ביקורת ומעקב.

הפעלת סריקת נקודות חולשה בעומסי עבודה:

gcloud beta container clusters update gke-cluster \
    --region=us-central1-a \
    --enable-workload-vulnerability-scanning \
    --async

פותחים את הדף Security Posture (מצב האבטחה) ב-GKE.

ממתינים כמה דקות עד לסיום הביקורת על עומס העבודה, ואז בודקים את התוצאות.

5b1b8158bc55ce67.png

בודקים את הבעיות בהגדרות ואת עומסי העבודה (workloads) המושפעים.

58e6f4b6d8eaa99a.png

למה כדאי להשתמש במרכז הבקרה של מצב האבטחה

לוח הבקרה של מצב האבטחה הוא אמצעי אבטחה בסיסי שאפשר להפעיל בכל אשכול GKE שעומד בדרישות. מומלץ להשתמש במרכז הבקרה 'מצב האבטחה' בכל האשכולות שלכם מהסיבות הבאות:

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

8. מעולה!

מעולה! סיימתם את ה-Codelab.

הנושאים שדיברנו עליהם:

  • מידע על תובנות אבטחה לגבי ארטיפקטים של בנייה ואפליקציות שפועלות ב-Cloud Run וב-GKE

הסרת המשאבים

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

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

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

עדכון אחרון: 21 במרץ 2023