אימות אפליקציות בהתאם למדיניות החברה בצינור CI

אם הארגון שלכם משתמש ב-Policy Controller כדי לנהל מדיניות באשכולות Google Kubernetes Engine, אתם יכולים לאמת את הגדרת הפריסה של אפליקציה בצינור השילוב הרציף (CI) שלה. במדריך הזה נסביר איך להגיע לתוצאה הזו. אימות האפליקציה שימושי אם אתם מפתחים שיוצרים צינור CI לאפליקציה, או מהנדסי פלטפורמה שיוצרים תבנית של צינור CI לכמה צוותים של אפליקציות.

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

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

במדריך הזה נשתמש ב-Cloud Build ככלי CI ובמאגר לדוגמה ב-GitHub שמכיל מדיניות להדגמות.

משאבים

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

הכלים שבהם משתמשים במדריך הזה כוללים את:

  • ‫Policy Controller: מבוסס על פרויקט הקוד הפתוח Open Policy Agent – Gatekeeper. Policy Controller אוכף מדיניות לגבי האובייקטים שנוצרים באשכול Kubernetes (לדוגמה, מניעת השימוש באפשרות ספציפית או אכיפת השימוש בתווית ספציפית). המדיניות הזו נקראת אילוצים. ההגבלות מוגדרות כמשאבים מותאמים אישית של Kubernetes. ‫Policy Controller זמין כחלק מ-GKE, אבל אפשר להשתמש ב-Open Policy Agent – Gatekeeper במקום ב-Policy Controller לצורך ההטמעה.

  • ‫GitHub: במדריך הזה אנחנו משתמשים ב-GitHub כדי לארח את מאגרי Git: אחד לאפליקציה לדוגמה, ואחד שמכיל את האילוצים של Policy Controller. כדי לפשט את התהליך, שני המאגרים הם שני תיקיות שונות במאגר Git אחד. בפועל, אלה יהיו מאגרי מידע שונים. אפשר להשתמש בכל פתרון Git.

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

  • ‫Kustomize: Kustomize הוא כלי להתאמה אישית של הגדרות Kubernetes. היא פועלת על ידי לקיחת תצורות "בסיסיות" והחלת התאמות אישיות עליהן. הוא מאפשר לכם להשתמש בגישת DRY (Don't Repeat Yourself) להגדרות של Kubernetes. בעזרת Kustomize, אפשר לשמור את הרכיבים שמשותפים לכל הסביבות בתצורות הבסיסיות וליצור התאמות אישיות לכל סביבה. במדריך הזה, אנחנו שומרים את ההגדרות של Kustomize במאגר האפליקציות, ויוצרים (לדוגמה, מחילים את ההתאמות האישיות) את ההגדרות בצינור ה-CI. אפשר להשתמש במושגים שמתוארים במדריך הזה עם כל כלי שמייצר הגדרות Kubernetes שמוכנות להחלה על אשכול (לדוגמה, הפקודה helm template).

  • ‫Kpt: Kpt הוא כלי ליצירת תהליכי עבודה להגדרות של Kubernetes. ‫Kpt מאפשרת לאחזר, להציג, להתאים אישית, לעדכן, לאמת ולהחיל הגדרות של Kubernetes. הוא תואם לרוב הכלים הקיימים במערכת האקולוגית של Kubernetes, כי הוא פועל עם קובצי Git ו-YAML. במדריך הזה אנחנו משתמשים ב-kpt בצינור ה-CI כדי לאחזר את האילוצים ממאגר anthos-config-management-samples, וכדי לאמת את הגדרות ה-Kubernetes מול האילוצים האלה.

פייפליין

בתרשים הבא מוצג צינור ה-CI שבו אנחנו משתמשים במדריך הזה:

צינור עיבוד נתונים של CI עבור Policy Controller

צינור הנתונים פועל ב-Cloud Build, והפקודות מופעלות בספרייה שמכילה עותק של מאגר האפליקציה לדוגמה. הצינור מתחיל ביצירת ההגדרות הסופיות של Kubernetes באמצעות Kustomize. לאחר מכן, המערכת מאחזרת את האילוצים שרוצים לבצע לגביהם אימות ממאגר anthos-config-management-samples באמצעות kpt. לבסוף, המערכת משתמשת ב-kpt כדי לאמת את תצורות Kubernetes בהתאם למגבלות האלה. כדי לבצע את השלב האחרון הזה, אנחנו משתמשים בפונקציית הגדרה ספציפית שנקראת gatekeeper, שמבצעת את האימות הזה. במדריך הזה מפעילים את צינור ה-CI באופן ידני, אבל בפועל כדאי להגדיר אותו כך שיפעל אחרי git push למאגר Git.

מטרות

  • הפעלת צינור עיבוד נתונים של CI לאפליקציה לדוגמה באמצעות Cloud Build.
  • שימו לב שצינור עיבוד הנתונים נכשל בגלל הפרת מדיניות.
  • משנים את מאגר האפליקציות לדוגמה כך שיעמוד בדרישות המדיניות.
  • מריצים שוב את צינור ה-CI בהצלחה.

עלויות

במדריך הזה השתמשנו ברכיבים הבאים של Google Cloud, והשימוש בהם כרוך בתשלום:

  • Cloud Build
  • Google Kubernetes Engine

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

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

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

  1. בוחרים או יוצרים Google Cloud פרויקט. במסוף Google Cloud , עוברים לדף Manage resources:

    כניסה לדף Manage resources

  2. מפעילים את החיוב בפרויקט.

  3. כדי להריץ את הפקודות שמפורטות במדריך הזה, פותחים את Cloud Shell:

    כניסה ל-Cloud Shell

  4. ב-Cloud Shell, מריצים את הפקודה gcloud config get-value project.

    אם הפקודה לא מחזירה את המזהה של הפרויקט שבחרתם, מגדירים את Cloud Shell להשתמש בפרויקט:

    gcloud config set project PROJECT_ID

    מחליפים את PROJECT_ID במזהה הפרויקט.

  5. ב-Cloud Shell, מפעילים את Cloud Build API הנדרש:

    gcloud services enable cloudbuild.googleapis.com

אימות ההגדרות של האפליקציה לדוגמה

בקטע הזה מריצים צינור CI באמצעות Cloud Build למאגר אפליקציות לדוגמה שאנחנו מספקים. בצינור הזה מתבצעת אימות של הגדרת Kubernetes שזמינה במאגר של אפליקציית הדוגמה, בהתאם למגבלות שזמינות במאגר anthos-config-management-samples.

כדי לאמת את הגדרות האפליקציה:

  1. ב-Cloud Shell, משכפלים את מאגר האפליקציה לדוגמה:

    git clone https://github.com/GoogleCloudPlatform/anthos-config-management-samples.git

  2. מריצים את צינור ה-CI באמצעות Cloud Build. יומני ה-Build מוצגים ישירות ב-Cloud Shell.

    cd anthos-config-management-samples/ci-app/app-repo
gcloud builds submit .

    הצינור שאתם מריצים מוגדר בקובץ הבא.

    steps:
- id: 'Prepare config'
  # This step builds the final manifests for the app
  # using kustomize and the configuration files
  # available in the repository.
  name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
  entrypoint: '/bin/sh'
  args: ['-c', 'mkdir hydrated-manifests && kubectl kustomize config/prod > hydrated-manifests/prod.yaml']
- id: 'Download policies'
  # This step fetches the policies from the Anthos Config Management repository
  # and consolidates every resource in a single file.
  name: 'gcr.io/kpt-dev/kpt'
  entrypoint: '/bin/sh'
  args: ['-c', 'kpt pkg get https://github.com/GoogleCloudPlatform/anthos-config-management-samples.git/ci-app/acm-repo/cluster@main constraints
                  && kpt fn source constraints/ hydrated-manifests/ > hydrated-manifests/kpt-manifests.yaml']
- id: 'Validate against policies'
  # This step validates that all resources comply with all policies.
  name: 'gcr.io/kpt-fn/gatekeeper:v0.2'
  args: ['--input', 'hydrated-manifests/kpt-manifests.yaml']

    ב-Policy Controller, אילוצים הם מופעים של תבניות אילוצים. תבניות אילוצים מכילות את קוד Rego בפועל שמשמש להטמעת האילוץ. כדי שהפונקציה gcr.io/kpt-fn/gatekeeper תפעל, צריך להגדיר גם את תבנית האילוצים וגם את האילוצים. מאגר המדיניות לדוגמה מכיל את שניהם, אבל במציאות הם יכולים להיות מאוחסנים במקומות שונים. משתמשים בפקודה kpt pkg get לפי הצורך כדי להוריד גם תבניות אילוצים וגם אילוצים.

    במדריך הזה משתמשים ב-gcr.io/kpt-fn/gatekeeper עם Cloud Build כדי לאמת משאבים, אבל יש עוד שתי אפשרויות חלופיות:

    kpt fn eval hydrated-manifests/kpt-manifests.yaml --image gcr.io/kpt-fn/gatekeeper:v0.2

    gator test -f hydrated-manifests/kpt-manifests.yaml

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

    [...]
Step #2 - "Validate against policies": [error] apps/v1/Deployment/nginx-deployment : Deployment objects should have an 'owner' label indicating who created them.
Step #2 - "Validate against policies": violatedConstraint: deployment-must-have-owner
Finished Step #2 - "Validate against policies"
2022/05/11 18:55:18 Step Step #2 - "Validate against policies" finished
2022/05/11 18:55:19 status changed to "ERROR"
ERROR
ERROR: build step 2 "gcr.io/kpt-fn/gatekeeper:v0.2" failed: exit status 1
2022/05/11 18:55:20 Build finished with ERROR status

    ההגבלה שההגדרה מפרה מוגדרת בקובץ הבא. זהו משאב מותאם אישית של Kubernetes שנקרא K8sRequiredLabels.

    apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: deployment-must-have-owner
spec:
  match:
    kinds:
      - apiGroups: ["apps"]
        kinds: ["Deployment"]
  parameters:
    labels:
      - key: "owner"
    message: "Deployment objects should have an 'owner' label indicating who created them."

    תבנית האילוצים שמתאימה לאילוץ הזה מופיעה ב-requiredlabels.yaml ב-GitHub.

  4. יוצרים את ההגדרה המלאה של Kubernetes בעצמכם, ורואים שהתווית owner באמת חסרה. כדי ליצור את ההגדרה:

    kubectl kustomize config/prod

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

בקטע הזה מוסבר איך לתקן את הפרת המדיניות באמצעות Kustomize:

  1. ב-Cloud Shell, מוסיפים קטע commonLabels לקובץ הבסיס של Kustomization:

    cat <<EOF >> config/base/kustomization.yaml
commonLabels:
  owner: myself
EOF

  2. יוצרים את ההגדרה המלאה של Kubernetes ורואים שהתווית owner מופיעה עכשיו:

    kubectl kustomize config/prod

  3. מריצים מחדש את צינור ה-CI באמצעות Cloud Build:

    gcloud builds submit .

    הפלט של התהליך יהיה:

    [...]
Step #2 - "Validate against policies": [RUNNING] "gcr.io/kpt-fn/gatekeeper:v0"
Step #2 - "Validate against policies": [PASS] "gcr.io/kpt-fn/gatekeeper:v0"
[...]

הסרת המשאבים

  1. במסוף Google Cloud , נכנסים לדף Manage resources.

    כניסה לדף Manage resources

  2. ברשימת הפרויקטים, בוחרים את הפרויקט שרוצים למחוק ולוחצים על Delete.
  3. כדי למחוק את הפרויקט, כותבים את מזהה הפרויקט בתיבת הדו-שיח ולוחצים על Shut down.