Trang chủ
Bài đăng

GitOps là gì?

Chuyện về devsecops

Bạn không cần DevSecOps... nếu bạn chưa làm được GitOps

Giải phẫu một sáng kiến DevSecOps thất bại

Nhiều tổ chức áp dụng DevSecOps với các mục tiêu cao cả (Shift-Left, Trách nhiệm chia sẻ, Tự động hóa) nhưng lại gặp phải thất bại trong thực tế.

Các triệu chứng thất bại phổ biến:

  • Áp dụng không nhất quán: Các nhóm áp dụng công cụ một cách rời rạc, tạo ra các điểm mù bảo mật.
  • Lối mòn của quy trình thủ công: Các bản vá nóng (hotfix) thủ công, bỏ qua kiểm tra, tạo ra "hố đen" không thể kiểm toán.
  • Cơn ác mộng kiểm toán: Dữ liệu kiểm toán phân tán ở nhiều nơi (Jira, logs, email), tốn thời gian và không đáng tin cậy.
  • Sự kháng cự văn hóa: Developer xem bảo mật là rào cản, Ops ngần ngại từ bỏ quyền kiểm soát trực tiếp.

Vấn đề cốt lõi: Tồn tại khoảng trống lớn giữa CHÍNH SÁCH (những gì được viết) và SỰ THỰC THI (những gì đang chạy).

GitOps: Mặt phẳng điều khiển cho trạng thái mong muốn

GitOps là một mô hình vận hành sử dụng Git làm nguồn chân lý duy nhất (single source of truth). Nó được xây dựng trên 4 nguyên tắc:

  • Khai báo (Declarative): Toàn bộ trạng thái hệ thống (apps, infra, policy) được mô tả khai báo (vd: YAML).
  • Được phiên bản hóa (Versioned): Git là nơi lưu trữ duy nhất, tạo ra lịch sử thay đổi bất biến, có thể kiểm toán.
  • Được kéo tự động (Pulled Automatically): Một agent (ArgoCD, Flux) bên trong cluster *kéo* trạng thái từ Git (an toàn hơn push).
  • Được đối chiếu liên tục (Continuously Reconciled): Agent liên tục so sánh trạng thái thực tế với Git và tự động sửa chữa mọi "trôi dạt" (drift).

Quy trình làm việc GitOps điển hình:

1. Lập trình viên
(Push to Git)
2. Git repository
(Nguồn chân lý)
3. CI Pipeline
(Build/Test Image)
5. Trạng thái thực tế
(Cụm Kubernetes)
4. Tác nhân GitOps
(Pull & Đối chiếu)

Kết quả: Mọi thay đổi thủ công ("cowboy engineering") sẽ tự động bị hoàn nguyên, buộc tất cả phải tuân theo quy trình Git đã được kiểm duyệt.

Quản trị tự động: Policy as Code

GitOps cho phép thực thi "Policy as Code" (PaC). Các chính sách bảo mật không còn là tài liệu Word, chúng là tệp YAML được lưu trong Git, được quản lý phiên bản, kiểm thử và áp dụng tự động.

Ví dụ: Chặn container đặc quyền với Kyverno

Chính sách này (lưu trong Git) sẽ được tác nhân GitOps áp dụng, và Kyverno sẽ chặn mọi nỗ lực tạo Pod vi phạm.


apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-privileged-latest-tag
spec:
  validationFailureAction: Enforce
  rules:
  - name: validate-privileged-and-latest-tag
    match:
      any:
      - resources:
          kinds: [Pod]
    validate:
      message: "Chạy container đặc quyền hoặc dùng thẻ 'latest' là không được phép."
      pattern:
        spec:
          containers:
          - (securityContext):
              (privileged): "false"
          - image: "!*:latest"

Quy trình kiểm toán thay đổi như thế nào?

Kiểm toán truyền thống (Giờ/Ngày)

Yêu cầu: "Cho xem phê duyệt thay đổi tường lửa X."

Sàng lọc Jira, email, logs. Đối chiếu thủ công.

Yêu cầu: "Lỗ hổng Y được đưa vào khi nào?"

Đối chiếu log CI và báo cáo quét. Rất phức tạp.

Kiểm toán với GitOps (Phút)

Trả lời:

git show <hash>. Đây là link Pull Request với đầy đủ thảo luận và phê duyệt.

Trả lời:

git bisect để tìm ra chính xác commit gây ra lỗ hổng trong vài phút.

Xây dựng chuỗi cung ứng phần mềm an toàn

GitOps tích hợp các cổng kiểm soát bảo mật vào quy trình làm việc tự động.

Ví dụ: Chặn lỗ hổng với Trivy trong GitHub Actions

Đoạn mã CI này sẽ thất bại nếu Trivy phát hiện lỗ hổng `CRITICAL`, ngăn chặn image không an toàn được build và deploy.


name: Build and Scan Container Image
jobs:
  build-and-scan:
    runs-on: ubuntu-latest
    steps:
    - name: Checkout code
      uses: actions/checkout@v3

    # ... (Các bước build image) ...

    - name: Run Trivy vulnerability scanner
      uses: aquasecurity/trivy-action@master
      with:
        image-ref: 'ghcr.io/my-org/my-app:${{ github.sha }}'
        format: 'table'
        exit-code: '1' # Làm pipeline thất bại nếu có lỗi
        severity: 'CRITICAL,HIGH' # Chỉ tìm lỗi CRITICAL, HIGH

Các biện pháp bảo vệ khác:

  • GPG Signed Commits: Xác thực danh tính của tác giả commit một cách mật mã hóa.
  • Protected Branches & CODEOWNERS: Buộc phải có phê duyệt (vd: từ nhóm Security) trước khi merge.

Bằng chứng qua những con số (Các chỉ số DORA)

Các tổ chức áp dụng GitOps trưởng thành có hiệu suất vượt trội. Các cơ chế của GitOps (PR, tự động hóa, rollback nhanh) cải thiện trực tiếp các chỉ số DORA:

Deployment Frequency (Tăng)
Lead Time (Giảm)
Change Failure Rate (Giảm)
Time to Recovery (Giảm)

Cạm bẫy (Anti-Patterns) cần tránh

Việc áp dụng GitOps có thể thất bại nếu mắc phải các lỗi phổ biến sau:

  • Cấu trúc kho chứa kém: Dùng một kho chứa nguyên khối (monorepo) cho mọi thứ mà không có chiến lược rõ ràng.
  • Lưu trữ bí mật (secrets) trong Git: Sai lầm bảo mật nghiêm trọng. Phải dùng các công cụ như Sealed Secrets hoặc Vault.
  • Bỏ qua sự trôi dạt (Drift): Tắt tính năng tự động đối chiếu. Điều này làm mất đi lợi ích cốt lõi của GitOps.
  • Nhầm lẫn GitOps với CI/CD: Dùng Git chỉ để kích hoạt một đường ống "đẩy" (push) truyền thống. GitOps phải là "kéo" (pull).

Đăng nhận xét