Bảo mật & quyền riêng tư

Tại sao Kubernetes loại bỏ PodSecurityPolicy và công nghệ thay thế là gì

Kubernetes v1.25 đã loại bỏ bộ điều khiển admission PodSecurityPolicy vốn bị ngừng hỗ trợ (deprecated). Bài viết này giải thích lịch sử, những hạn chế của nó và giải pháp thay thế đơn giản hơn: Pod Security Admission.

Hình minh họa các bản vẽ cũ của PSP được thay thế bằng một tấm khiên bảo mật hiện đại
Hình ảnh: Kubernetes Blog, giấy phép CC BY 4.0

Được dịch tự động từ bản gốc tiếng Anh.

Trong một bài đăng trên Kubernetes Blog vào tháng 8 năm 2022, dự án đã cung cấp bối cảnh lịch sử cho việc loại bỏ PodSecurityPolicy (PSP). Bộ điều khiển admission này chính thức bị loại bỏ trong Kubernetes v1.25 sau một chu kỳ ngừng hỗ trợ kéo dài, bắt đầu từ bản phát hành v1.21. Bài viết giải thích lý do PSP không đạt được trạng thái ổn định (stable) và cách phiên bản kế nhiệm, Pod Security Admission, khắc phục những thiếu sót đó.

Chuyện gì đã xảy ra

PodSecurityPolicy có nguồn gốc từ SecurityContextConstraints (SCC) của OpenShift, vốn tồn tại ngay từ bản phát hành đầu tiên của Red Hat OpenShift Container Platform trước cả Kubernetes 1.0. Về cơ bản, PSP là một phiên bản rút gọn của SCC được thiết kế cho upstream Kubernetes. Việc tạo ra PSP diễn ra trước khi quy trình Kubernetes Enhancements Proposal (KEP) chính thức được áp dụng, khiến lịch sử thiết kế ban đầu khó theo dõi. Tuy nhiên, các tài liệu lưu trữ cho thấy đề xuất thiết kế cuối cùng được tạo ra sau khi mã nguồn ban đầu đã bắt đầu được hợp nhất.

Các nền tảng cốt lõi của PSP được thêm vào thông qua một loạt pull request bắt đầu từ năm 2015. Trước khi PSP tồn tại, Kubernetes 1.0, phát hành vào ngày 10 tháng 7 năm 2015, thiếu các cơ chế để hạn chế security context ngoài một plugin chất lượng alpha tên là SecurityContextDeny. Đối tượng PSP đầu tiên, dựa trên SCC của OpenShift, đã được hợp nhất vào upstream Kubernetes vào tháng 2 năm 2016 sau chín tháng thảo luận. Bộ điều khiển admission tiếp theo xuất hiện vào tháng 5 năm 2016, với các cơ chế ủy quyền được bổ sung vào cuối năm đó để cho phép áp dụng các chính sách khác nhau cho những người dùng khác nhau.

Bất chấp ý định ban đầu, PSP chưa bao giờ đạt được trạng thái ổn định. Nó gặp phải nhiều vấn đề như mô hình ủy quyền kém hiệu quả, khó triển khai và API không nhất quán. Kết quả là, cộng đồng Kubernetes đã quyết định loại bỏ hoàn toàn nó trong v1.25. PSP được thay thế bởi Pod Security Admission, một plugin mới tích hợp sẵn trong nhân (in-tree plugin), thực thi các Tiêu chuẩn Bảo mật Pod (Pod Security Standards) ở cấp độ namespace.

Cách hoạt động

PodSecurityPolicy hoạt động như một plugin kiểm soát admission chuyên biệt, cung cấp các quyền hạn chi tiết đối với các trường bảo mật của pod. Mục tiêu của nó là tách biệt các quyết định bảo mật Linux cấp thấp khỏi quy trình triển khai, cho phép quản trị viên cụm đặt các mặc định an toàn mà không yêu cầu mọi người dùng phải hiểu rõ các nguyên thủy bảo mật phức tạp. Hệ thống dựa vào cơ chế biến đổi (mutation) và xác thực (validation) để thực thi các quy tắc như chạy dưới dạng non-root hoặc hạn chế leo thang đặc quyền.

Hình từ bài viết gốc: Why Kubernetes removed PodSecurityPolicy and what replaced it
Hình từ bài viết gốc · Kubernetes Blog · CC BY 4.0

Tuy nhiên, PSP hoạt động theo nguyên tắc fail-closed (mặc định từ chối). Nếu không có chính sách nào tồn tại, tất cả các pod đều bị từ chối. Điều này khiến việc bật tính năng này trở nên khó khăn, vì quản trị viên phải tạo chính sách cho mọi workload trước khi kích hoạt. Không có chế độ kiểm toán (audit mode) để xác định những pod nào sẽ thất bại dưới các chính sách mới, dẫn đến tình trạng hỏng hóc thường xuyên và độ phủ kiểm thử không đầy đủ. Ngoài ra, API trở nên không nhất quán theo thời gian khi phải đáp ứng các trường hợp sử dụng ngách, gây khó khăn cho việc kết hợp với các bộ điều khiển admission khác.

Giải pháp thay thế, Pod Security Admission, đơn giản hóa mô hình này bằng cách thực thi ba Tiêu chuẩn Bảo mật Pod được định nghĩa trước: Privileged, Baseline và Restricted. Privileged không có hạn chế, Baseline cho phép các cấu hình mặc định, còn Restricted thực thi các thực hành bảo mật tốt nhất. Cách tiếp cận này loại bỏ nhu cầu về kiến thức bảo mật sâu rộng đối với hầu hết người dùng và cung cấp một cơ chế thực thi ổn định ở cấp độ namespace, dễ dàng áp dụng và duy trì hơn.

Chi tiết quan trọng

  • PodSecurityPolicy bị loại bỏ trong Kubernetes v1.25 sau khi bị ngừng hỗ trợ (deprecated) trong v1.21.
  • PSP có nguồn gốc từ SecurityContextConstraints của OpenShift và được hợp nhất vào Kubernetes vào tháng 2 năm 2016.
  • Tính năng này không đạt được trạng thái ổn định do mô hình ủy quyền kém hiệu quả và sự phức tạp trong triển khai.
  • PSP hoạt động theo nguyên tắc fail-closed, đòi hỏi phải có chính sách cho mọi workload trước khi kích hoạt.
  • Pod Security Admission thay thế PSP bằng ba tiêu chuẩn: Privileged, Baseline và Restricted.
  • Bộ điều khiển admission mới này ổn định trong Kubernetes v1.25 và hoạt động ở cấp độ namespace.

Tại sao điều này quan trọng

Đối với kỹ sư phần mềm và đội ngũ nền tảng, việc hiểu rõ sự chuyển dịch từ PSP sang Pod Security Admission là rất quan trọng để duy trì các cụm an toàn. PSP đòi hỏi chuyên môn đáng kể về các nguyên thủy bảo mật Linux và sự quản lý chính sách cẩn thận để tránh làm hỏng các đợt triển khai. Việc loại bỏ nó đánh dấu xu hướng chuyển sang các mặc định bảo mật đơn giản hơn, mang tính chủ quan cao hơn (opinionated), dễ triển khai và ít prone to configuration errors (dễ mắc lỗi cấu hình).

Các Tiêu chuẩn Bảo mật Pod mới cung cấp một lộ trình rõ ràng để bảo vệ workload mà không cần gánh nặng quản lý các chính sách tùy chỉnh phức tạp. Bằng cách tập trung vào ba mức độ hạn chế riêng biệt, Kubernetes giúp các nhà phát triển dễ dàng áp dụng các thực hành bảo mật tốt nhất mà không cần kiến thức sâu về các cơ chế bảo mật bên dưới. Thay đổi này giảm thiểu rủi ro cấu hình sai và cải thiện tư thế bảo mật tổng thể của các cụm Kubernetes.

Bạn có thể làm gì

  • Nâng cấp các cụm của bạn lên Kubernetes v1.25 hoặc phiên bản mới hơn để sử dụng bộ điều khiển Pod Security Admission ổn định.
  • Xem xét lại các workload hiện có để đảm bảo chúng tuân thủ các Tiêu chuẩn Bảo mật Pod Baseline hoặc Restricted.
  • Thay thế bất kỳ đối tượng PodSecurityPolicy còn lại nào bằng các nhãn ở cấp độ namespace để thực thi tiêu chuẩn bảo mật mong muốn.
  • Sử dụng chế độ kiểm toán (audit mode) có sẵn trong các phiên bản trước để xác định những pod sẽ thất bại dưới các tiêu chuẩn mới trước khi thực thi chúng.
  • Tham khảo tài liệu Kubernetes để tìm các hướng dẫn thực hành về việc triển khai Pod Security Admission.
  • Đối với các trường hợp sử dụng phức tạp không được bao phủ bởi các tiêu chuẩn tích hợp sẵn, hãy đánh giá các bộ điều khiển admission của bên thứ ba có thể bổ sung cho Pod Security Admission.

Công cụ từ cửa hàng Bytechap

Đọc tiếp

Xây dựng với AI

Việc tái tạo mô hình OLMo 3 7B trên TPU tiết lộ các lỗi ẩn trong trình tải dữ liệu

Một nghiên cứu tình huống của Google đã tái tạo thành công mô hình OLMo 3 của AI2 trên các bộ xử lý TPU, khớp với các chỉ số hiệu suất nhưng đồng thời phát hiện ra những lỗi phân mảnh dữ liệu nghiêm trọng khiến việc ghi nhớ dữ liệu bị nhầm lẫn là sự cải thiện.

Tất cả bài viết