Di chuyển từ Chính sách bảo mật Pod: Hướng dẫn toàn diện (Phần 1: Chuyển sang PSA)

Giới thiệu Khi Kubernetes tiếp tục phát triển với tư cách là nền tảng điều phối container hàng đầu, bảo mật vẫn là mối quan tâm hàng đầu đối với các tổ chức triển khai các ứng dụng trong container. Trong số các công cụ cơ bản trong kho bảo mật của Kubernetes, từng đóng một vai trò quan trọng. PSP cho phép quản trị viên xác định và thực thi một cách tỉ mỉ các ràng buộc bảo mật trên Pod, đảm bảo rằng chỉ những vùng chứa đáp ứng các tiêu chuẩn bảo mật cụ thể mới có thể hoạt động trong cụm. Tuy nhiên, bối cảnh bảo mật Kubernetes đang phát triển nhanh chóng và điều quan trọng cần lưu ý là PSP hiện không được dùng nữa, bắt đầu với Kubernetes 1.25 (xem liên kết tới Ghi chú phát hành khẩn cấp Kubernetes 1.25). Sự thay đổi này xuất phát từ nhiều yếu tố khác nhau, bao gồm sự phức tạp trong việc quản lý và duy trì các chính sách của PSP, thường dẫn đến những thách thức vận hành cho người dùng. Để đối phó với việc ngừng sử dụng, các tổ chức hiện đang tìm kiếm các giải pháp thay thế hiện đại cho PSP, những giải pháp không chỉ giải quyết các yêu cầu bảo mật mà còn hợp lý hóa quy trình bảo mật khối lượng công việc trong . Trong hướng dẫn toàn diện này, chúng tôi bắt đầu hành trình điều hướng sự thay đổi này trong các biện pháp bảo mật Kubernetes, tập trung vào việc chuyển đổi sang Tiếp nhận bảo mật Pod (PSA). PSA là một trong những lựa chọn thay thế mạnh mẽ nhất hiện có và bài viết này sẽ tìm hiểu sâu về nó. Tuy nhiên, điều đáng nói là hai lựa chọn thay thế khác là Kyverno và OPA Gatekeeper sẽ được đề cập trong các bài viết riêng biệt trong loạt bài này. Trong suốt bài viết này, bạn sẽ tìm thấy hướng dẫn chi tiết để thiết lập và cài đặt PSA, hướng dẫn di chuyển từng bước để chuyển đổi từ PSP sang PSA một cách suôn sẻ và các lệnh chính xác để chuyển các quy tắc PSP hiện có sang PSA. Ngoài ra, bạn sẽ có được kiến thức để đánh giá mức độ sẵn sàng di chuyển của các không gian tên bằng cách sử dụng các lệnh chạy thử phù hợp với PSA. Khi kết thúc hướng dẫn này, bạn sẽ hiểu toàn diện về điểm mạnh và hạn chế của PSA, giúp bạn đưa ra quyết định sáng suốt dựa trên các yêu cầu bảo mật cụ thể của tổ chức và môi trường Kubernetes. Với hướng dẫn này, bạn có thể tự tin hiện đại hóa các biện pháp bảo mật Kubernetes của mình, đảm bảo rằng khối lượng công việc của bạn vẫn được bảo vệ khi bạn tạm biệt kỷ nguyên của Chính sách bảo mật Pod. Chính sách bảo mật Pod (PSP) Kubernetes Nhập học bảo mật Pod (PSA) PSA đảm bảo các container tuân thủ các tiêu chuẩn bảo mật gốc của Kubernetes, được xác định bởi Tiêu chuẩn bảo mật Pod. Các tiêu chuẩn này phân loại chính sách bảo mật thành ba cấu hình riêng biệt, mỗi cấu hình có mức độ hạn chế khác nhau: PSA thực thi các tiêu chuẩn bảo mật Kubernetes: : Chính sách Đặc quyền được mở có chủ ý và hoàn toàn không bị hạn chế. Thông thường, chính sách này nhắm mục tiêu khối lượng công việc ở cấp hệ thống và cơ sở hạ tầng do người dùng đáng tin cậy quản lý. Nó được đặc trưng bởi sự vắng mặt của các hạn chế. Mặc dù các cơ chế cho phép theo mặc định như Gatekeeper vốn có thể là Đặc quyền, nhưng đối với các cơ chế từ chối theo mặc định như Chính sách bảo mật Pod (PSP), chính sách Đặc quyền sẽ hủy kích hoạt tất cả các hạn chế. Đặc quyền : Chính sách cơ sở được thiết kế để dễ dàng áp dụng cho các khối lượng công việc được chứa trong bộ chứa phổ biến, đồng thời ngăn chặn việc leo thang đặc quyền đã biết. Nó phục vụ cho các nhà khai thác ứng dụng và nhà phát triển các ứng dụng không quan trọng. Đường cơ sở : Chính sách bị hạn chế tập trung vào việc thực thi các phương pháp hay nhất nghiêm ngặt về tăng cường độ cứng của Pod, mặc dù có thể phải trả giá bằng một số khả năng tương thích. Nó chủ yếu nhắm vào các nhà khai thác và nhà phát triển các ứng dụng quan trọng về bảo mật cũng như những người dùng có độ tin cậy thấp hơn. Để biết danh sách đầy đủ các biện pháp kiểm soát nên được thực thi hoặc không được phép trong từng hồ sơ, bạn có thể tham khảo tài liệu chính thức. Bị hạn chế Không giống như một số giải pháp khác, PSA không cung cấp phương pháp đơn giản để di chuyển hoặc sửa đổi trực tiếp các quy tắc Chính sách bảo mật Pod (PSP). Trọng tâm chính của PSA là xác thực các nhóm theo đã thiết lập, bao gồm các hồ sơ được đề cập ở trên. Không chuyển giao quy tắc PSP trực tiếp: các tiêu chuẩn bảo mật Kubernetes : Mặc dù PSA có hiệu quả trong việc xác thực nhưng nó không thể sửa đổi hoặc tùy chỉnh các thông số kỹ thuật của nhóm như PSP có thể. Mục đích chính của PSA là thực thi các tiêu chuẩn bảo mật Kubernetes được xác định trước và không bao gồm các tính năng để thay đổi hoặc thay đổi thông số kỹ thuật của nhóm. Nó chủ yếu tập trung vào việc xác nhận các nhóm theo các tiêu chuẩn đã được thiết lập này. Không có đột biến Thiết lập và cài đặt Vì PSA là thành phần Kubernetes Native nên để nó hoạt động, bạn chỉ cần đảm bảo rằng bộ điều khiển Pod Security Entry (PSA) được bật trong cụm Kubernetes của bạn. Bạn có thể làm điều đó bằng cách chạy lệnh sau: kubectl api-versions | grep admission Các bước chuẩn bị cho việc di chuyển Đánh giá quyền của không gian tên Kiểm soát nhập học bảo mật Pod bị ảnh hưởng bởi nhãn không gian tên. Điều này ngụ ý rằng những cá nhân có khả năng cập nhật, vá lỗi hoặc tạo các không gian tên cũng có quyền sửa đổi cài đặt Pod Security cho các không gian tên đó. Việc sửa đổi này có khả năng có thể bỏ qua các chính sách bảo mật chặt chẽ hơn. Trước khi tiếp tục, điều cần thiết là phải xác minh rằng các quyền của vùng tên được chỉ định riêng cho người dùng đáng tin cậy và có đặc quyền. Bạn nên hạn chế cấp các quyền nâng cao này cho những người dùng không yêu cầu quyền truy cập đó. Nếu cần có các ràng buộc bổ sung để định cấu hình nhãn Pod Security trên các đối tượng Không gian tên, hãy cân nhắc sử dụng webhook tuyển sinh để thực thi các hạn chế đó. Hợp lý hóa và chuẩn hóa PodSecurityPolicies Trước khi chuyển sang Tiếp nhận bảo mật Pod (PSA), bạn nên bình thường hóa PodSecurityPolicies (PSP): : Loại bỏ các tùy chọn không nằm trong Tiêu chuẩn bảo mật Pod. Các tùy chọn này bao gồm: Xóa các trường không được hỗ trợ .spec.allowedHostPaths .spec.allowedFlexVolumes .spec.allowedCSIDrivers .spec.forbiddenSysctls .spec.runtimeClass : Bắt đầu quy trình bằng cách xóa các trường chỉ có tác dụng thay đổi và không ảnh hưởng đến chính sách xác thực. Các trường này, như đã đề cập trong tài liệu tham khảo "Ánh xạ PodSecurityPolicies tới Tiêu chuẩn bảo mật Pod", bao gồm: Loại bỏ các trường đột biến hoàn toàn .spec.defaultAllowPrivilegeEscalation .spec.runtimeClass.defaultRuntimeClassName .metadata.annotations['seccomp.security.alpha.kubernetes.io/defaultProfileName'] .metadata.annotations['apparmor.security.beta.kubernetes.io/defaultProfileName'] .spec.defaultAddCapabilities Lưu ý quan trọng: Việc xóa các trường này có thể dẫn đến khối lượng công việc thiếu cấu hình cần thiết, từ đó có thể gây ra sự cố vận hành. Điều quan trọng là đảm bảo rằng khối lượng công việc có thể hoạt động chính xác với các chính sách được đơn giản hóa. Xác định mức độ bảo mật Pod phù hợp Khi xác định mức độ Bảo mật Pod thích hợp cho vùng tên của mình, bạn có một số phương pháp cần xem xét: Theo yêu cầu bảo mật cho không gian tên Nếu đã quen với cấp độ truy cập dự kiến và các yêu cầu bảo mật cho vùng tên, bạn có thể chọn cấp độ Bảo mật Pod thích hợp dựa trên các yêu cầu cụ thể đó. Cách tiếp cận này tương tự như cách bạn tiếp cận các cài đặt bảo mật trong một cụm mới. Theo PodSecurityPolicies hiện có: Sử dụng tham chiếu để ánh xạ từng Chính sách bảo mật Pod (PSP) hiện tại của bạn tới cấp Tiêu chuẩn bảo mật Pod tương ứng. Nếu PSP của bạn ban đầu không dựa trên Tiêu chuẩn bảo mật Pod, bạn có thể cần phải đưa ra quyết định. Chọn cấp độ Bảo mật Pod ít nhất cho phép như PSP của bạn hoặc chọn cấp độ ít nhất là hạn chế. Để xác định PSP nào đang được sử dụng cho các nhóm trong một không gian tên cụ thể, hãy sử dụng lệnh sau: "Ánh xạ PodSecurityPolicies tới Tiêu chuẩn bảo mật Pod" kubectl get pods -n $NAMESPACE -o jsonpath="{.items[*].metadata.annotations.kubernetes\.io\/psp}" | tr " " "\n" | sort -u Theo nhóm hiện có: Tiến hành chạy thử và áp dụng lệnh nhãn từ phần tiếp theo để kiểm tra cả cấp độ Bảo mật cơ sở và nhóm bị hạn chế. Điều này giúp bạn đánh giá xem các mức này có đủ cho phép đối với khối lượng công việc hiện tại của bạn hay không. Chọn mức hợp lệ có ít đặc quyền nhất phù hợp với khối lượng công việc hiện tại của bạn. Điều quan trọng cần lưu ý là các tùy chọn được đề cập đều dựa trên các nhóm hiện có, có thể không tính đến khối lượng công việc hiện không chạy. Điều này bao gồm CronJobs, khối lượng công việc có quy mô từ 0 đến 0 hoặc các khối lượng công việc khác chưa được triển khai. Kiểm tra mức độ bảo mật của Pod Sau khi bạn đã xác định cấp độ Bảo mật nhóm cho vùng tên của mình (ngoại trừ cấp Đặc quyền), điều quan trọng là phải xác thực chính sách đã chọn. Pod Security cung cấp các tùy chọn thử nghiệm để đảm bảo triển khai suôn sẻ và tuân thủ các tiêu chuẩn bảo mật. Thử nghiệm chạy khô: Sử dụng phương pháp này để đánh giá tác động của chính sách đã chọn mà không cần thực thi ngay lập tức. Để thực hiện chạy thử, hãy sử dụng lệnh sau, lệnh này sẽ đánh dấu mọi nhóm hiện có không đáp ứng cấp chính sách đã chỉ định: kubectl label --overwrite ns $NAMESPACE pod-security.kubernetes.io/enforce=$LEVEL Kiểm tra chế độ kiểm toán: Chế độ kiểm tra cho phép bạn ghi lại các vi phạm chính sách mà không cần thực thi chúng. Các nhóm vi phạm được ghi vào hồ sơ kiểm toán để xem xét sau. Kích hoạt chế độ kiểm tra bằng lệnh: kubectl label --overwrite ns $NAMESPACE pod-security.kubernetes.io/audit=$LEVEL Nếu phát sinh các vi phạm chính sách không mong muốn trong quá trình thử nghiệm, bạn có thể: Cập nhật khối lượng công việc không tuân thủ để phù hợp với chính sách. Điều chỉnh mức độ Bảo mật Pod cho không gian tên nếu cần thiết để đáp ứng yêu cầu khối lượng công việc của bạn. Thực thi mức độ bảo mật của Pod Sau khi tin tưởng rằng cấp độ Pod Security đã chọn phù hợp với không gian tên của mình, bạn có thể tiến hành thực thi cấp độ đó. Bước này đảm bảo rằng các tiêu chuẩn bảo mật mong muốn được áp dụng tích cực cho khối lượng công việc của bạn trong không gian tên. Để thực thi mức Bảo mật Pod mong muốn trên không gian tên, hãy sử dụng lệnh sau: kubectl label --overwrite ns $NAMESPACE pod-security.kubernetes.io/enforce=$LEVEL Việc thực thi lệnh này sẽ kích hoạt và thực thi cấp độ Bảo mật Pod được chỉ định, nâng cao tình trạng bảo mật cho không gian tên của bạn. Vượt qua PSP Để vượt qua PodSecurityPolicy một cách hiệu quả ở cấp không gian tên, bạn có thể liên kết Chính sách bảo mật Pod (PSP) có đặc quyền đầy đủ với tất cả các tài khoản dịch vụ trong không gian tên. Quá trình này đảm bảo rằng các nhóm trong không gian tên không còn chịu sự sửa đổi hoặc hạn chế do PodSecurityPolicy áp đặt. Bạn có thể làm điều đó ở cấp cụm hoặc ở cấp không gian tên riêng lẻ. Thiết lập theo phạm vi cụm (Chỉ cần một lần cho toàn bộ cụm): Tạo Chính sách bảo mật Pod (PSP) đặc quyền đầy đủ bằng cách áp dụng tệp cấu hình YAML, chẳng hạn như . PSP này sẽ cấp tất cả các đặc quyền cần thiết cho các nhóm và tạo một vai trò cụm có tên là đặc quyền-psp để cho phép sử dụng Chính sách bảo mật nhóm (PSP) và liên kết nó với PSP đặc quyền: đặc quyền-psp.yaml kubectl apply -f privileged-psp.yaml kubectl create clusterrole privileged-psp --verb use --resource podsecuritypolicies.policy --resource-name privileged Vô hiệu hóa không gian tên: Tạo một ràng buộc vai trò trong không gian tên đích để liên kết vai trò cụm đặc quyền-psp với nhóm . Ràng buộc này cấp cho tất cả các tài khoản dịch vụ trong không gian tên quyền truy cập vào PSP có đặc quyền một cách hiệu quả, bỏ qua PodSecurityPolicy: system:serviceaccounts:$NAMESPACE kubectl create -n $NAMESPACE rolebinding disable-psp --clusterrole privileged-psp --group system:serviceaccounts:$NAMESPACE Với thiết lập này, PSP đặc quyền sẽ không bị biến đổi và bộ điều khiển tiếp nhận PodSecurityPolicy luôn ưu tiên các PSP không đột biến. Do đó, các nhóm trong không gian tên này sẽ không còn bị PodSecurityPolicy sửa đổi hoặc hạn chế nữa. Một ưu điểm của phương pháp này là tính thuận nghịch của nó. Nếu có bất kỳ vấn đề nào phát sinh, bạn có thể dễ dàng khôi phục thay đổi bằng cách xóa RoleBinding liên quan đến việc vô hiệu hóa PodSecurityPolicy. Đảm bảo rằng các Chính sách bảo mật Pod hiện có vẫn được áp dụng trong quá trình này. Hoàn tác vô hiệu hóa PodSecurityPolicy: Để hoàn nguyên việc vô hiệu hóa PodSecurityPolicy cho không gian tên, chỉ cần xóa RoleBinding đã tạo trước đó: kubectl delete -n $NAMESPACE rolebinding disable-psp Xem lại quy trình tạo không gian tên Với các không gian tên hiện có được cập nhật để thực thi Chấp nhận bảo mật Pod, điều cần thiết là phải xem xét và cập nhật các quy trình cũng như chính sách của bạn để tạo các không gian tên mới. Điều này đảm bảo rằng các không gian tên mới được định cấu hình với cấu hình Pod Security thích hợp ngay từ đầu. Hãy xem xét các bước sau để nâng cao quá trình tạo không gian tên: : Cập nhật các chính sách và quy trình của tổ chức bạn để tạo không gian tên mới để bao gồm việc lựa chọn và áp dụng cấp độ Bảo mật Pod mong muốn. Đảm bảo rằng các tiêu chuẩn bảo mật được thiết lập ngay từ giai đoạn tạo. Điều chỉnh chính sách tạo không gian tên Bạn có thể định cấu hình tĩnh bộ điều khiển tiếp nhận Pod Security để xác định các mức thực thi, kiểm tra và/hoặc cảnh báo mặc định cho các vùng tên không được gắn nhãn. Cách tiếp cận này đảm bảo rằng các không gian tên thiếu nhãn Pod Security rõ ràng vẫn tuân thủ các tiêu chuẩn bảo mật đã chỉ định của bạn theo mặc định. Cấu hình tĩnh: Bằng cách xem lại quy trình tạo vùng chứa tên, bạn có thể tích hợp liền mạch các tiêu chuẩn Pod Security vào , đồng thời duy trì cách tiếp cận nhất quán và an toàn trên tất cả các không gian tên, cũ và mới. môi trường Kubernetes của chúng tôi Tắt PodSecurityPolicy Sau khi bạn tin chắc rằng bộ điều khiển tiếp nhận PodSecurityPolicy (PSP) không còn cần thiết nữa và Việc tiếp nhận bảo mật Pod (PSA) đã được triển khai và xác thực thành công, bạn có thể tiến hành vô hiệu hóa bộ điều khiển tiếp nhận PSP. Dưới đây là các bước để tắt bộ điều khiển tiếp nhận PSP: Sửa đổi cấu hình kube-apiserver: Mở tệp cấu hình cho máy chủ kube-apiserver của bạn, thường nằm ở /etc/kubernetes/manifests/kube-apiserver.yaml. Thêm cờ để tắt bộ điều khiển tiếp nhận PSP. Đảm bảo rằng nó bị xóa khỏi danh sách các plugin tuyển sinh đang hoạt động. --disable-admission-plugins kube-apiserver --disable-admission-plugins=PodSecurityPolicy Lưu tập tin cấu hình. Khởi động lại máy chủ kube-api: Khởi động lại kube-apiserver để áp dụng các thay đổi. Bạn thường có thể đạt được điều này bằng cách khởi động lại mặt phẳng điều khiển Kubernetes hoặc chính nhóm kube-apiserver. systemctl restart kubelet Xác minh: Đảm bảo rằng bộ điều khiển tiếp nhận PSP bị tắt bằng cách kiểm tra nhật ký kube-apiserver hoặc trạng thái của nó. Sau khi đủ "thời gian ngâm" để chắc chắn rằng bạn sẽ không cần quay lại PSP, hãy chuyển sang bước tiếp theo. Dọn dẹp tài nguyên PSP: Khi bộ điều khiển tiếp nhận PSP bị vô hiệu hóa và PSA được cài đặt, bạn có thể xóa PodSecurityPolicies hiện tại của mình một cách an toàn cũng như mọi Vai trò, ClusterRoles, RoleBindings và ClusterRoleBindings liên quan. kubectl delete podsecuritypolicies --all kubectl delete roles,clusterroles,rolebindings,clusterrolebindings --selector=rbac.authorization.kubernetes.io/autoupdate=true Bước dọn dẹp này đảm bảo rằng không còn cấu hình PSP nào trong cụm của bạn. Bằng cách vô hiệu hóa bộ điều khiển tiếp nhận PSP và loại bỏ các tài nguyên liên quan đến PSP, bạn đơn giản hóa kiến trúc bảo mật của cụm, hoàn tất quá trình chuyển đổi sang Tiếp nhận bảo mật Pod. Bản tóm tắt Trong hướng dẫn toàn diện này, chúng tôi đã khám phá các bước cần thiết và những điều cần cân nhắc để chuyển đổi từ Chính sách bảo mật Pod (PSP) sang Tiếp nhận bảo mật Pod (PSA). Quá trình di chuyển này đảm bảo khối lượng công việc của bạn tiếp tục chạy an toàn đồng thời phù hợp với các tiêu chuẩn bảo mật ngày càng phát triển của Kubernetes. suôn sẻ khung bảo mật của cụm Kubernetes Ưu và nhược điểm của việc sử dụng Pod Security Access (PSA) Ưu điểm: : PSA là một phần không thể thiếu của Kubernetes, loại bỏ nhu cầu cài đặt công cụ của bên thứ ba. Nó tận dụng các tính năng bảo mật tích hợp của nền tảng. Thành phần Kubernetes gốc : PSA phù hợp với các tiêu chuẩn bảo mật gốc của Kubernetes, đảm bảo tuân thủ các phương pháp hay nhất của nền tảng. Thực thi các tiêu chuẩn Kubernetes Nhược điểm: : PSA có thể không cung cấp mức độ tùy chỉnh giống như PSP, đặc biệt đối với các chính sách bảo mật phức tạp yêu cầu thay đổi thông số kỹ thuật của nhóm. Tùy chỉnh hạn chế : Khối lượng công việc hiện tại phải được cập nhật để bao gồm các cài đặt ngữ cảnh bảo mật, có thể yêu cầu sửa đổi các tệp YAML. Yêu cầu trang bị thêm Hướng dẫn này trang bị cho bạn kiến thức và các bước cần thiết để tự tin di chuyển từ PSP sang PSA, đảm bảo quá trình chuyển đổi an toàn và hiệu quả đồng thời bảo vệ khối lượng công việc Kubernetes của bạn. Hãy theo dõi các bài viết sắp tới, nơi tôi sẽ khám phá các con đường di chuyển thay thế sang Kyverno và OPA Gatekeeper.