Kaniko לבניית תמונות Docker ב-Kubernetes: הגדרה ואבטחה

הרצת Docker-in-Docker (dind) בצינור CI בתוך Kubernetes פירושה עיגון של /var/run/docker.sock מהצומת לתוך קונטיינר הבנייה, מה שמעניק לו גישת root למארח. כל קוד שנבנה בצינור זה עלול לברוח מהקונטיינר — זהו לא איום היפותטי אלא ממשי, בדומה ל-CVE-2019-5736. אנו פותרים בעיה זו עם Kaniko — כלי לבניית תמונות Docker כולו במרחב המשתמש ללא דמון Docker. המהנדסים שלנו יישמו את Kaniko ביותר מ-50 פרויקטים, תוך הבטחת בידוד ומהירות בנייה. הודות לשכבת מטמון, עלויות תשתית CI מופחתות ב-40–50%, והחזר השקעה מושג בתוך החודש הראשון.

כיצד Kaniko בונה תמונות ללא דמון Docker

Kaniko מבצע כל הוראת Dockerfile בקונטיינר מבודד. במקום להשתמש במערכת קבצים overlay, הוא מצלם שינויים במערכת הקבצים לאחר כל פקודת RUN/COPY ויוצר שכבות ידנית. הוא פועל כמשתמש רגיל ואינו דורש --privileged. זה הופך בנייה לבטוחה גם באשכולות מרובי-דיירים. לפי הפרויקט, Kaniko נמצא בשימוש בייצור על ידי אלפי צוותים, והקוד שלו מתוחזק באופן פעיל על ידי הקהילה.

התקנת Kaniko שלב אחר שלב ב-GitLab CI

1. הכן Secret עם אישורים. צור Kubernetes Secret מסוג docker-registry או הרכב config.json עם אימות לרג'יסטרי שלך.
2. הגדר את תמונת Kaniko ב-CI. השתמש ב-gcr.io/kaniko-project/executor:v1.23.0-debug והעבר את הארגומנטים הדרושים.
3. אפשר שכבת מטמון. הוסף דגלים --cache=true ו---cache-repo כדי להאיץ בניות חוזרות.
4. הרץ את הבנייה. Kaniko יבנה את התמונה וידחוף אותה לרג'יסטרי ללא עיגון docker.sock.

דוגמה מינימלית:

---
build:
  image:
    name: gcr.io/kaniko-project/executor:v1.23.0-debug
    entrypoint: [""]
  script:
    - mkdir -p /kaniko/.docker
    - echo "{\"auths\":{\"$CI_REGISTRY\":{\"auth\":\"$(echo -n $CI_REGISTRY_USER:$CI_REGISTRY_PASSWORD | base64)\"}}}" > /kaniko/.docker/config.json
    - /kaniko/executor --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/Dockerfile --destination $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA --cache=true --cache-repo $CI_REGISTRY_IMAGE/cache

מה מספקת שכבת המטמון של Kaniko

build: image: name: gcr.io/kaniko-project/executor:v1.23.0-debug entrypoint: [""] script: - mkdir -p /kaniko/.docker - echo "{\"auths\":{\"$CI_REGISTRY\":{\"auth\":\"$(echo -n $CI_REGISTRY_USER:$CI_REGISTRY_PASSWORD | base64)\"}}}" > /kaniko/.docker/config.json - /kaniko/executor --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/Dockerfile --destination $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA --cache=true --cache-repo $CI_REGISTRY_IMAGE/cache — Kaniko שומר שכבות ביניים במאגר נפרד. בבניות חוזרות עם אותן הוראות והקשר, הוא עושה שימוש חוזר בשכבות מהמטמון. זה מקצר את זמן הבנייה לתמונות עם תלויות שלא השתנו. בפרויקטים שלנו, חיסכון בזמן מגיע ל-70% בבניות חוזרות, תוך קיצוץ עלויות CI בממוצע של 40-50%. אנו גם מגדירים מדיניות שמירת מטמון כדי למנוע הצפת הרג'יסטרי.

אפשרויות מצב צילום:

עבור רוב הפרויקטים, --cache=true מספיק, אך אם התמונה נבנית בצורה שגויה, עבור ל-full.

בנייה כ-Kubernetes Job

כדי להשתמש ב-Kaniko ישירות באשכול (לא ב-GitLab Runner), הפעל Kubernetes Job:

---
apiVersion: batch/v1
kind: Job
metadata:
  name: build-my-app
spec:
  template:
    spec:
      restartPolicy: Never
      containers:
        - name: kaniko
          image: gcr.io/kaniko-project/executor:v1.23.0
          args:
            - "--dockerfile=/workspace/Dockerfile"
            - "--context=git://github.com/my-org/my-app#main"
            - "--destination=my-registry.io/my-app:latest"
            - "--cache=true"
            - "--cache-repo=my-registry.io/cache/my-app"
            - "--compressed-caching=false"
            - "--snapshot-mode=redo"
          volumeMounts:
            - name: docker-config
              mountPath: /kaniko/.docker
      volumes:
        - name: docker-config
          secret:
            secretName: registry-credentials
            items:
              - key: .dockerconfigjson
                path: config.json
---

redo — Kaniko משכפל את המאגר ישירות, אין צורך ב-PVC עם מקורות. עבור מאגרים פרטיים דרך SSH או עם טוקן: apiVersion: batch/v1 kind: Job metadata: name: build-my-app spec: template: spec: restartPolicy: Never containers: - name: kaniko image: gcr.io/kaniko-project/executor:v1.23.0 args: - "--dockerfile=/workspace/Dockerfile" - "--context=git://github.com/my-org/my-app#main" - "--destination=my-registry.io/my-app:latest" - "--cache=true" - "--cache-repo=my-registry.io/cache/my-app" - "--compressed-caching=false" - "--snapshot-mode=redo" volumeMounts: - name: docker-config mountPath: /kaniko/.docker volumes: - name: docker-config secret: secretName: registry-credentials items: - key: .dockerconfigjson path: config.json . --context=git:// — מצב מדויק יותר (ומעט איטי יותר) מאשר --git git_token=<token>. משמש כאשר התמונה שונה מהצפוי במצב ברירת מחדל.

כיצד Kaniko מתמודד עם בניות מרובות-פלטפורמות

Kaniko יכול לבנות תמונות עבור ארכיטקטורות אחרות באמצעות הדגל /workspace. עם זאת, אמולציה דרך QEMU מאטה את התהליך פי 2-3. לייצור, השתמש בצמתים מקומיים או בחוות בנייה לכל ארכיטקטורה. חלופה היא buildx, אך היא דורשת דמון Docker.

השוואה עם buildah ו-img

Kaniko נבחר בשל פשטותו ותמיכה רחבה במערכות CI. buildah משמש כאשר יש צורך במהירות וקבלת הגדרת מרחב שמות משתמש על הצמתים מקובלת.

מה כלול ביישום Kaniko

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

• CI/CD עובד עם Kaniko בתשתית שלך.
• מטמון מוגדר עם מדיניות שמירה.
• תיעוד לתחזוקה ושגיאות נפוצות.
• המלצות לאופטימיזציה נוספת.

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

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