Cách áp dụng bảo mật tại nguồn bằng GitOps

Nếu mô hình triển khai GitOps của bạn có vấn đề về bảo mật (ví dụ: quyền được định cấu hình sai do lỗi đánh máy), điều này sẽ được phổ biến cho đến khi hy vọng được phát hiện trong thời gian chạy , nơi hầu hết các sự kiện bảo mật được quét hoặc tìm thấy.

Điều gì sẽ xảy ra nếu bạn có thể khắc phục các vấn đề bảo mật tiềm ẩn trong cơ sở hạ tầng của mình tại nguồn?

Hãy bắt đầu với những điều cơ bản.

Git là gì?

Git là một hệ thống kiểm soát phiên bản phân tán mã nguồn mở . Nó theo dõi các thay đổi được thực hiện trong tệp (thường là tệp văn bản như mã nguồn) cho phép và thúc đẩy mô hình làm việc hợp tác . Nó là tiêu chuẩn_ de facto trong các hệ thống kiểm soát phiên bản ngày nay.

Bạn có thể có kho git cục bộ trên máy tính xách tay của mình, lưu trữ nó trên máy chủ của riêng bạn hoặc sử dụng một số nhà cung cấp như GitLab hoặc GitHub.

Có các “luồng” khác nhau về cách quản lý kho lưu trữ (git-flow, github-flow, v.v.), nhưng một ví dụ cơ bản về cách git được sử dụng như sau: Các thay đổi trong tệp được người dùng “cam kết” bởi "Nâng cấp" kho lưu trữ và thực hiện các thay đổi thích hợp trong một "nhánh".

Sau đó, người dùng tạo một yêu cầu (hoặc "yêu cầu kéo", "yêu cầu hợp nhất" hoặc chỉ "gửi bản vá") để đưa những thay đổi đó vào kho lưu trữ.

Sau đó, thường là một cuộc thảo luận xảy ra giữa “chủ sở hữu” và người dùng tạo yêu cầu và nếu mọi thứ suôn sẻ, thay đổi sẽ được chấp nhận và được thêm vào kho lưu trữ.

LƯU Ý: Nếu bạn muốn biết thêm, đây là thông tin chi tiết hơn về cơ chế git pull request.

Để xem một ví dụ trong thế giới thực, chỉ cần duyệt qua kho lưu trữ GitLab hoặc GitHub nguồn mở yêu thích của bạn và duyệt qua tab Yêu cầu kéo (hoặc Yêu cầu hợp nhất) (hoặc xem phần này để giải trí). Bạn có thể xem các thay đổi được đề xuất, nhận xét, nhãn, người đã đề xuất thay đổi, các công cụ chạy xác thực đối với các thay đổi được đề xuất, thông báo được gửi đến những người đang xem kho lưu trữ, v.v.

GitOps là gì?

Nói một cách đơn giản, GitOps chỉ là một phương pháp luận sử dụng kho lưu trữ git làm nguồn trung thực duy nhất cho nội dung phần mềm của bạn để bạn có thể tận dụng mô hình triển khai git (yêu cầu kéo, khôi phục, phê duyệt, v.v.) cho phần mềm của mình.

Có sách ( Đường dẫn đến GitOps , GitOps và Kubernetes hoặc Triển khai liên tục có nguồn gốc từ đám mây của GitOps ), sách trắng và nhiều bài đăng trên blog hơn chúng ta có thể đếm được nhưng hãy để chúng tôi giải thích rõ hơn về mục đích của GitOps bằng cách xem nhanh cách mọi thứ phát triển trong vài năm gần đây.

Trước khi có đám mây, việc thêm một máy chủ mới để lưu trữ ứng dụng của bạn đã mất hàng tuần. Bạn phải yêu cầu quyền, mua nó và thực hiện rất nhiều tác vụ thủ công. Sau đó, ảo hóa làm cho mọi thứ dễ dàng hơn nhiều. Bạn yêu cầu một máy ảo với một số thông số kỹ thuật và sau vài phút, bạn có quyền truy cập vào nó.

Sau đó, đám mây. Yêu cầu máy chủ, mạng, bộ nhớ và thậm chí cả cơ sở dữ liệu, hàng đợi nhắn tin, vùng chứa, công cụ học máy, không có máy chủ… chỉ là một lệnh gọi API! Bạn yêu cầu nó và một vài giây sau, bạn nhận được nó, chỉ như vậy. Bạn chỉ cần trả tiền cho những gì bạn sử dụng. Điều này cũng có nghĩa là cơ sở hạ tầng có thể được quản lý dưới dạng mã thực hiện các lệnh gọi API… và bạn lưu trữ mã của mình ở đâu? Trong kho lưu trữ git (hoặc bất kỳ hệ thống phiên bản nội dung nào khác).

Thuật ngữ GitOps được Weaveworks đặt ra vào năm 2017 và diễn giải OpenGitOps , một hệ thống GitOps dựa trên các nguyên tắc sau:

• Khai báo: nó xác định “cái gì”.
• Được tạo phiên bản và không thay đổi : do đó "git."
• Được kéo tự động : một tác nhân quan sát trạng thái mong muốn và những thay đổi xảy ra trong mã.
• Liên tục hòa giải : ai đó đã đề cập đến Kubernetes?

Bản chất của phương pháp GitOps về cơ bản là một bộ điều khiển hoặc bộ điều khiển (hoặc tác nhân) Kubernetes chạy trên cụm của bạn để quan sát các đối tượng Kubernetes chạy trên nó (được xác định bởi một CustomResource ) so sánh trạng thái hiện tại với trạng thái được chỉ định trong Git repo . Nếu nó không khớp, nó sẽ khắc phục ứng dụng bằng cách áp dụng các tệp kê khai được tìm thấy trong kho lưu trữ.

LƯU Ý: Có những cách tiếp cận hơi khác nhau đối với GitOps, ví dụ: push và pull, cách xử lý quản lý cấu hình, v.v. Đó là những chủ đề nâng cao, nhưng hiện tại, chúng ta hãy bám vào những điều cơ bản.

Sơ đồ sau đây cho thấy một hệ thống GitOps được đơn giản hóa:

• Một thay đổi mã được người dùng gửi đến kho lưu trữ Git.
• Sau đó, một quy trình được kích hoạt trên kho lưu trữ để kết hợp những thay đổi đó vào chính ứng dụng, bao gồm cả việc chạy các công cụ tự động hóa dựa trên mã mới đó để xác thực nó.
• Khi mọi thứ đã sẵn sàng, tác nhân GitOps chạy trong cụm Kubernetes, đang quan sát kho lưu trữ, thực hiện đối chiếu giữa trạng thái mong muốn (mã trong kho lưu trữ) và trạng thái hiện tại (các đối tượng chạy trên chính cụm Kubernetes).

Dựa trên Git có nghĩa là dễ dàng cho các nhà phát triển. Họ không cần phải lo lắng về một công cụ mới để tương tác, mà áp dụng các phương pháp tương tự được sử dụng để quản lý mã trong kho lưu trữ Git.

Nói về các công cụ GitOps, có một số công cụ đã có sẵn, bao gồm các công cụ mã nguồn mở như Flux hoặc ArgoCD , cả hai đều là các dự án ươm tạo CNCF .

Để biết định nghĩa ứng dụng trông như thế nào thông qua GitOps, đây là ví dụ về một ứng dụng đơn giản (được lưu trữ trong kho lưu trữ GitHub) được quản lý bởi Flux hoặc ArgoCD.

Với Flux:

 --- apiVersion: source.toolkit.fluxcd.io/v1beta2 kind: GitRepository metadata: name: my-example-app namespace: hello-world spec: interval: 30s ref: branch: master url: https://github.com/xxx/my-example-apps.git --- apiVersion: kustomize.toolkit.fluxcd.io/v1beta2 kind: Kustomization metadata: name: my-example-app namespace: hello-world spec: interval: 5m0s path: ./myapp prune: true sourceRef: kind: GitRepository name: my-example-app targetNamespace: hello-world

Với ArgoCD:

 apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: my-example-app namespace: hello-world spec: destination: namespace: my-example-app server: https://kubernetes.default.svc project: default source: path: myapp/ repoURL: https://github.com/xxx/my-example-apps.git targetRevision: HEAD syncPolicy: automated: {} syncOptions: - CreateNamespace=true

Cả hai đều tham chiếu đến kho lưu trữ Git nơi ứng dụng được lưu trữ (Triển khai), NameSpaces và một số chi tiết khác.

GitOps so với IaC

Cơ sở hạ tầng dưới dạng mã là một phương pháp xử lý các khối xây dựng của cơ sở hạ tầng của bạn như mã bằng cách sử dụng các kỹ thuật và công cụ khác nhau. Điều này có nghĩa là thay vì tạo thủ công cơ sở hạ tầng của bạn như máy ảo, vùng chứa, mạng hoặc lưu trữ thông qua giao diện web của nhà cung cấp cơ sở hạ tầng yêu thích của bạn theo cách thủ công, bạn xác định chúng dưới dạng mã và sau đó chúng được tạo / cập nhật / quản lý bằng các công cụ bạn chọn, chẳng hạn như dưới dạng terraform , crossplane hoặc pulumi , trong số những thứ khác.

Những lợi ích là rất lớn. Bạn có thể quản lý cơ sở hạ tầng của mình như thể nó là mã (bây giờ nó là mã) và tận dụng các phương pháp phát triển tốt nhất (tự động hóa, thử nghiệm, truy xuất nguồn gốc, kiểm soát phiên bản, v.v.) cho các tài sản cơ sở hạ tầng của bạn. Trên thực tế, có một xu hướng sử dụng "Cơ sở hạ tầng dưới dạng phần mềm" như một thuật ngữ để thay thế vì nó không chỉ đơn thuần là mã.

Có rất nhiều thông tin về chủ đề này, nhưng tài nguyên sau đây là một điểm khởi đầu tốt.

Như bạn có thể đã hình dung, GitOps tận dụng Cơ sở hạ tầng dưới dạng Mã làm mô hình khai báo để xác định cơ sở hạ tầng. Trên thực tế, IaC là một trong những nền tảng của GitOps! Nhưng nó còn nhiều hơn thế vì IaC không bắt buộc phần còn lại của các nguyên tắc GitOps.

GitOps so với DevOps

Có rất nhiều định nghĩa về thuật ngữ "DevOps". Nó phụ thuộc vào người bạn yêu cầu nhưng nói một cách đơn giản, "DevOps là sự kết hợp của các phương pháp thực hành và công cụ để xây dựng và cung cấp phần mềm giảm thiểu ma sát và đạt tốc độ cao."

Các phương pháp DevOps có thể tận dụng GitOps vì GitOps cung cấp một khuôn khổ phù hợp với thực tiễn DevOps nhưng nó không hoàn toàn cần thiết.

Còn về NoOps?

NoOps được Forrester đặt ra vào năm 2021 và đây là một cách tiếp cận triệt để để xử lý các hoạt động trong đó môi trường CNTT được trừu tượng hóa và tự động hóa đến mức không cần quản lý nó theo cách thủ công.

GitOps giúp giảm thiểu các thay đổi thủ công bằng cách khắc phục những thay đổi có trạng thái mong muốn trong kho lưu trữ Git, nhưng việc áp dụng NoOps thực sự cho toàn bộ môi trường CNTT là một mục tiêu đầy khát vọng chứ không phải là mục tiêu thực như hiện nay .

GitOps có chỉ dành cho Kubernetes không?

Không. Kubernetes, mẫu bộ điều khiển và mô hình khai báo để xác định các đối tượng Kubernetes là kết hợp hoàn hảo cho phương pháp GitOps, nhưng không có nghĩa là không thể áp dụng phương pháp GitOps mà không có Kubernetes. Có một số thách thức nếu sử dụng GitOps bên ngoài Kubernetes, chẳng hạn như xử lý tính không hiệu quả, xóa / tạo tài sản, quản lý bí mật, v.v. Nhưng các nguyên tắc GitOps có thể được áp dụng mà không cần Kubernetes (và áp dụng một chút sáng tạo).

GitOps & Bảo mật

Bây giờ chúng ta hãy nói về các khía cạnh bảo mật. Hầu hết các công cụ bảo mật đều phát hiện các lỗ hổng và sự cố tiềm ẩn trong thời gian chạy (quá muộn). Để khắc phục chúng, cần phải thực hiện quy trình thủ công phản ứng (ví dụ: sửa đổi trực tiếp một tham số trong đối tượng k8s của bạn bằng chỉnh sửa kubectl) hoặc lý tưởng nhất là sửa chữa sẽ xảy ra tại nguồn và sẽ được phổ biến dọc theo chuỗi cung ứng của bạn. Đây là cái được gọi là “ Shift Security Left ”. Từ việc khắc phục sự cố khi quá muộn đến việc sửa chữa nó trước khi nó xảy ra.

Điều này không có nghĩa là mọi vấn đề bảo mật đều có thể được khắc phục tại nguồn, nhưng việc thêm một lớp bảo mật trực tiếp tại nguồn có thể ngăn chặn một số vấn đề.

Trước hết, các khuyến nghị bảo mật chung được áp dụng.

• Giảm bề mặt tấn công
• Mã hóa bí mật (sử dụng Bí mật bên ngoài hoặc Bí mật được niêm phong)
• Phân đoạn mạng
• RBAC
• Luôn cập nhật phần mềm
• Thực thi đặc quyền ít nhất
• Theo dõi và đo lường
• …

Hãy xem một vài tình huống mà phương pháp GitOps có thể cải thiện bảo mật của bạn nói chung:

• Tránh / Từ chối các thay đổi thủ công (tránh Trôi) . Kho lưu trữ Git là nguồn của sự thật. Nếu bạn cố gắng sửa đổi định nghĩa ứng dụng, công cụ GitOps sẽ hoàn nguyên những thay đổi đó bằng cách áp dụng phiên bản được lưu trữ trong kho lưu trữ Git.

• Thay đổi khôi phục . Hãy tưởng tượng bạn đã đưa ra một vấn đề bảo mật tiềm ẩn trong một cam kết cụ thể bằng cách sửa đổi một số tham số trong triển khai ứng dụng của bạn. Tận dụng các khả năng của Git, bạn có thể khôi phục thay đổi nếu cần trực tiếp tại nguồn và công cụ GitOps sẽ triển khai lại ứng dụng của bạn mà không cần sự tương tác của người dùng.

• Phản ứng nhanh. Nếu bạn thấy mình đang sử dụng hình ảnh vùng chứa dễ bị tấn công trong ứng dụng của mình (ví dụ: MariaDB), bạn chỉ cần tạo PR để cập nhật thẻ vào tệp triển khai và công cụ GitOps sẽ sử dụng thẻ mới trong một triển khai mới.

• Truy xuất nguồn gốc. Sử dụng các tính năng của Git, bạn có thể dễ dàng kiểm tra thời điểm một tệp được thay đổi, bản thân các thay đổi và người dùng đã thúc đẩy các thay đổi. Bạn đã có một nhật ký kiểm tra miễn phí .

• Khôi phục thảm họa. Một lần nữa, kho lưu trữ Git là nguồn của sự thật. Nếu bạn cần triển khai lại ứng dụng của mình vì điều gì đó đã xảy ra, thì định nghĩa sẽ có ở đó (tất nhiên bạn cần phải có kế hoạch khôi phục thảm họa cho những thứ khác chẳng hạn như chính dữ liệu).
• Kiểm soát truy cập. Bạn có thể áp dụng các quyền khác nhau cho những người dùng khác nhau trên kho lưu trữ Git của mình và thậm chí cả các chính sách như “chỉ hợp nhất một thay đổi sau hai đánh giá tích cực”.

Những lợi ích đó đủ tốt để biện minh cho việc sử dụng các phương pháp GitOps để cải thiện tình trạng bảo mật của bạn và chúng đã ra đời, nhưng GitOps là sự kết hợp của một số thứ khác. Chúng tôi có thể làm nhiều hơn nữa. GitHub, GitLab và các nhà cung cấp kho lưu trữ Git khác cho phép bạn chạy các hành động hoặc đường ống dựa trên những thay đổi bạn thực hiện trong kho lưu trữ Git của mình, bao gồm cả yêu cầu kéo, vì vậy khả năng là vô tận. Một vài ví dụ:

• Thuốc mỡ. Định nghĩa của ứng dụng là mã , điều gì sẽ xảy ra nếu định nghĩa được kiểm tra vì cú pháp sai, thiếu tham số và hơn thế nữa? Có những công cụ (chẳng hạn như megalinter ) có thể được thực thi dựa trên những thay đổi bạn đã thực hiện để bạn tránh bị bất ngờ sau này.

• Thử nghiệm. Bạn thậm chí có thể tự động tạo một cụm Kubernetes tạm thời để chạy ứng dụng của mình với các thay đổi và chạy một số thử nghiệm đối với nó.

• Quét lỗ hổng bảo mật . Bằng cách kiểm tra các hình ảnh vùng chứa mà bạn đang sử dụng để tìm các lỗ hổng trước khi chúng được triển khai trong môi trường của bạn.

• Chính sách dưới dạng mã. Tận dụng OPA , bạn thậm chí có thể áp dụng các chính sách cho bản kê khai của mình để kiểm tra các vấn đề tiềm ẩn hoặc các chính sách tùy chỉnh

Lời kết

Phương pháp GitOps mang lại một số cải tiến cho mô hình triển khai và các lợi ích bảo mật cho bảng mà không cần phải thêm một công cụ khác .

Nó cải thiện tình trạng bảo mật bằng cách thêm một lớp “shift left” trực tiếp vào mã nguồn và nhờ vào tính linh hoạt của mô hình pull-request, bạn có thể dễ dàng thêm các kiểm tra bảo mật bổ sung mà không ảnh hưởng hoặc sửa đổi thời gian chạy.

Cũng được xuất bản ở đây .